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

Travis Evans travisgevans at cox.net
Sun Dec 24 21:28:51 UTC 2006


On Saturday 23 December 2006 01:34, Andy Feldman wrote:
> Here's what I think I did to get 3.5.5 working: Compile it instead of
> Installing the binary package.
> [...]

I used the Compile script.  I had some permission problems which I would 
have to fix by making all the directories within /Files/Compile 
world-writable in addition to /Files/Compile itself.  That felt rather 
scary to me, so I created a group called "compile", set the permissions 
of everything in /Files/Compile to root:compile 775, and added my user 
account to the "compile" group instead.  I wonder if maybe those 
directories should have the "sticky" attribute set when they're 
world-writable (like /tmp typically does).

Compiling KDE-Libs and KDE-Base, though, didn't solve the problem with 
KDM.  I don't think the Qt library messages I saw are relevant now, 
because I just realized that KDM doesn't write anything to the kdm.log 
file at all whatsoever when it fails to start (the Qt library messages 
were written at some earlier time).

In fact, what KDM does is it continues running (it can be seen in top) 
but it's completely idle (no CPU usage) and won't start an X display.  
I have no idea why.  Google was no help at all.  KDM won't write 
anything to the log.  I even tried strace and couldn't find anything 
obvious there, either.

If I symlink just KDE-Base 3.5.3 back into place, KDM works.  Just for 
the heck of it, I symlinked KDE-Base 3.5.5 back and temporarily 
replaced the KDE 3.5.5 kdm executable with the one from 3.5.3, but that 
didn't help, either--same behavior with KDM not starting.  There must be 
something with KDE-Base 3.5.5, but I don't know what it is.  The 
compiled version as well as the precompiled package from InstallProgram 
behaves the same.  But I have RPM packages of KDE 3.5.5 running on SUSE 
10.1, and KDM works fine there.

> 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".

Oh, I see.  So "conflict" just means that a package tried to install 
files that already existed from another package?

> > 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 think so.  On SUSE it's /var/log/messages.  I don't know if that's a 
standard name, but I think it has messages like from dmesg, with time 
stamps before every line.  By default, SUSE also prints the messages to 
a virtual terminal accessed with Ctrl+Alt+F10.

> 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?

The fstab file had lines for mounting all my SUSE partitions to /Mount.  
The lines were automatically added to it during GoboLinux installation.  
I set them all to noauto (since I didn't want them mounted 
automatically anyway), and then I never saw the mount error on bootup.

When I took a closer look, I found that there was a line that attempted 
to mount /dev/hda4.  If I remember correctly, I have hda1 and hda3 set 
up as primary partitions, and hda2 as an extended partition containing 
hda5 through hda9.  There is no hda4 (I guess it's reserved for a
fourth primary or extended partition), so I think that's where the 
error came from.  A bug in the GoboLinux installer, perhaps?

(I currently have GoboLinux installed a single partition of a second, 
older hard drive on hdb.)

For some reason, it seems that when I use Compile to compile and install 
a program, the Compile script keeps saying at the end that the 
installation (and compilation) failed, even though it apparently ran to 
completion, including installation, without problems.  Does this happen 
to you?

There seem to be permission issues that I run into with these Scripts.  
I had trouble compiling KDE at first because of a weird "No target to 
make kbookmarknotifier.h" error.  Google was only full of people asking 
the same questions and no answers.  I finally found that in the recipe 
for KDE-Libs, there was a command for 
symlinking /Programs/KDE-Libs/3.5.5/include/kbookmarknotifier.h 
to /Programs/KDE-Base/3.5.5/include/kbookmarknotifier.h before the 
build.  I don't really understand the purpose of that, but it turns out 
that that command was failing during the preparation process due to 
permissions.  Manually creating that symlink as root seemed to allow 
make to finish with errors.

It seems that permission problems are a bit of a difficulty when running 
these Scripts under my user account.  But attempting to compile things 
with the Scripts as root gives even stranger types of errors.

I wonder if these issues might be responsible for KDM not working right, 
but it's hard to tell since I have to compile from a text console since 
KDE isn't working, and I don't know of a way to save the output to a 
log yet.  I once read about a command called "tee" or something but 
never learned how to use it.

-- 
Travis Evans


More information about the gobolinux-users mailing list