[gobolinux-users] Having trouble with software upgrades/installations

Andy Feldman nereusren at gmail.com
Sat Dec 23 07:34:59 UTC 2006


I remembered something else from your previous email that I wanted to mention:

> (By the way, during the K3B compiling process, I got an enormous slew of
> messages at various points like "libtool: link: warning: <path to some
> library> seems to be moved".  Is that normal?  The files it was warning
> about were all symlinks.)

This is "normal." (It presumably has to do with the Gobo system of
symlinks.) Some recipes have a TON of those messages when you compile
them, but they work fine.

Alright, now onto this email:

On 12/22/06, Travis Evans <travisgevans at cox.net> wrote:
> I tried upgrading the KDE packages again, and when I logged out, the
> same thing as last time happened as expected, so I rebooted.
> Unfortunately, that made the problem worse:  KDM won't start at all
> now.  I found this at the end of /System/Variable/log/kdm.log:
> [...]
> I was prompted to upgrade Qt as a dependency, but that seems to be the
> problem, maybe.  I seem to have encountered this before, but don't
> remember what I did about it.  I tried the command "SymlinkProgram Qt
> 3.3.6" (is that the command to set the old version back as the "active"
> version?)

Yes, that's exactly what it is. It does the work of updating the
Current symlink and making sure all the files in
/P/[prog]/[version]/bin, /lib, and so forth all get linked into the
system directories in /System/Links. If there's a conflict in those
folders with a link from another version of the same program, it
overwrites it (of course).

> , but that had no apparent effect; the messages were exactly
> the same. [...]

This is sounding very familiar... I think I had similar issues when
using the 3.5.5 packages. I'll get to my solution in a bit...

> I think I remembered to upgrade all the
> KDE packages.  I tried to upgrade KDM in case that was the problem, but
> InstallPackage couldn't find a package for that.

`which kdm` says kdm is part of KDE-Base, so it wouldn't have its own package.

> I did accidentally start "xdm" when I was trying to start "kdm", and
> that started okay, so at least X itself appears to still work.  (I
> didn't try to log back into KDE or anything yet, though.  I'd rather
> keep KDM as the login manager.)  I'm not sure what to do from here.
> KDE 3.5.5 is a must-have for me, though.  The earlier KDE 3.5.x
> releases have too many annoying bugs. :-)

Here's what I think I did to get 3.5.5 working: Compile it instead of
Installing the binary package. When I saw those Qt library errors even
after installing Qt 3.3.7, I figured something was messed up with the
way the binaries were linked. Fortunately, you can always build
yourself a consistent system by simply compiling it yourself. (I hope
you have a decent CPU, since compiling KDE is a reasonably lengthy
process!) I think I only had to recompile KDE-Base, based on the
Recipes I see in my /F/Compile/Recipes directory, but to be safe you
could do KDE-Libs first, then -Base (since that depends on -Libs),
then check to see if it works. By recompiling, it shouldn't matter
which Qt you have active, since it will find it and link against it
correctly.

> I found some bootscripts somewhere (I can't seem to
> find them now) where one was named "Graphic" or something, but it
> didn't appear to be designed to be run directly.

The bootscripts are good to know, since they contain the whole startup
routine for your system. You'll find them in
/Programs/BootScripts/Settings/BootScripts/. (You can also access
this, like any Settings folder, from either /System/Links/Booscripts
or /etc/BootScripts.) As you guessed, you won't be calling them
directly.

BootUp is the major one that has almost everything: starting daemons,
mounting file systems, and all that good stuff. All the messages you
see on startup, like "Starting Udev..." and "Mounting remaining file
systems..." can be found there. If you look in Graphic, you'll see it
just calls BootUp and then runs kdm. If you ever want to add something
like a web server or FTP server that should start up on boot, BootUp
will be the place to add it.

> But now I just found
> Programs/BootScripts/Current/bin and scripts like StartTask, StopTask,
> etc.  Are these what are used to start and stop services?)

StartTask and StopTask are used to manage services, as you suspect. I
don't think there is a Task for kdm, and I've never done anything more
fancy than becoming superuser and typing "killall kdm; kdm".

Programs can install Tasks just by having them in this folder:
/Programs/[ProgName]/Current/Resources/Tasks. So, if you're curious
about all the tasks on your system, you can just use this command:
ls /Programs/*/Current/Resources/Tasks/

Incidentally, the only one I've ever called manually is Network. A
number of them get called in BootUp. (Udev Start, GoboHide Start,
LoadModules, etc.)

> I have a few questions about some things that occurred earlier during
> the package installation process.  First, after installing Shadow
> (dependency of some KDE package at some point, I think), I
> got "conflict" messages [...]  Is this serious?  How
> would this be resolved?

This is not serious. I believe Shadow is a package that offers "more
secure" replacements to the standard authentication... as such, I make
sure the Shadow version of those files are linked in place. (It might
not make a difference, but since I don't care to look into it any
further and fix my ignorance of the situation, I just take the "safe"
route of using the Shadow versions of the duplicate files).

The way to force one program to link its conflicting files into place
over the other one is to run "SymlinkProgram --conflict overwrite
Shadow".

> Sometimes when updating dependencies I get "mod" prompts or something.
> I think it's asking me what I want to do about the configuration
> settings of the old version, and there are choices like "Auto
> merge", "skip", "view", etc.  What would be the best course of action
> here?  I've just been choosing "Auto merge".  Is that likely to cause
> problems?

"mod" means the Settings file that comes with the new version of the
program is different from the one that's currently on your system.

When I see "mod," if I haven't changed the config file in question, I
usually tell it to use the new version. If I've made my own
modifications, I always compare them to see if there's been any
changes, and if so, update the file manually. I'm paranoid about
letting scripts edit my config files :-). However, I think Auto Merge
is a good choice in general and I doubt it's been causing problems for
you. It's a relatively recent addition, so I'm hoping someone else can
reply and shed more light on it for you.

> At some point (maybe just before rebooting; I can't remember for sure),
> the first text console (Ctrl+Alt+F1) had messages like "MTRR 5 Not
> Used", "MTRR 6 Not Used", etc., or something like that printed on it.
> What's that mean, and why is it being printed on this console instead
> of in a log file?

No idea about that specific message. Because of some asynchronous
processes that still "live" in tty1 during boot, there are
occasionally messages that spill over into tty1 after the boot process
has "finished." I sometimes get a message about my ethernet card, and
the usbstorage module tells me my USB drive is ready. I'm guessing
your message is harmless, although google should be able to tell you
better.

> Where are the kernel logs (like "messages")?  I didn't see very many
> logs in /System/Variable/log.  Is this something that has to be enabled
> manually?

Do you mean the messages that you get as an output from "dmesg"? If
it's not that, then I have no idea.

> I noticed that during bootup at the bottom of the screen, I
> get "Failed: Mounting remaining file systems" but I can't figure out
> why it's failing.  /System/Variable/log/boot.log has this line, but I
> can't make much sense out of it:
> > Mounting remaining file systems... [96] mount -a -t
> > nonfs,nosmbfs,noproc,noswap

That particular line comes from BootUp. However, all it's doing is
trying to mount every file system in fstab that doesn't have "noauto"
and isn't one of those special types. Are there any items in fstab
that wouldn't be able to mount automatically at boot? If you want to
get rid of the message, check immediately after boot which file system
are actually mounted in /etc/mtab. The one that's in fstab but not
mtab is the one that failed! Then you'll just have to figure out
whether you want to fix it so it can mount at boot, or add noauto in
the fstab options so it doesn't try.

If that doesn't work and you still can't figure out why it's failing,
you can always edit that line in BootUp to try to capture some of its
error output to a file instead of just writing it to stdout during
boot.

> One odd thing happened when I upgraded Python.
> [...] I thought I was toast because the InstallPackage script
> wouldn't work anymore; [...] I guessed to maybe try a "sudo ldconfig".
> That fixed that, luckily.  Does the installation system normally run
> ldconfig automatically, or do I need to do that manually?  Or did this
> just happen because I was trying to update a package that the
> installation scripts apparently depend on?

That's the one. Normally ldconfig is called as one of the later steps
in the install process, but not if Python is out of place, since the
Scripts need Python.

One thing you could do in that situation is use the
RescueInstallPackage and ResuceSymlinkProgram scripts. Here's the
description of RescueInstallPackage from inside the file:

Does not relly on python, sed, awk, grep, find or on any script from
Scripts package despite 'RescueSymlinkProgram'
Depends only on Bash, CoreUtils tools (dirname, basename, ln, cp,
mkdir, cut, ...), wget (if url) and tar (if .tar.bz2)

Python is one of the few packages that can be dangerous that way. It
wasn't too long ago that blindly trying a Compile glibc or
InstallPackage glibc would leave the system unbootable. (This is now
fixed; I believe the Scripts now recognize glibc specifically and
treat it as a special case to avoid this problem. It is still a little
tricky, but at least now you can boot and SymlinkProgram the old
version of glibc back to undo it.)

-Andy


More information about the gobolinux-users mailing list