KDM not starting after upgrade

Fri May 20 09:17:14 BST 2011

Bogus Zaba posted on Thu, 19 May 2011 00:19:55 +0100 as excerpted:

> I have upgraded my Slackware Installation from 13.1 to 13.37. This means
> that my KDE has gone from 4.4.3 to 4.5.5. The same process worked fine
> on two other PCs, but on this (my main Desktop machine) I cannot get KDE
> up and running for a regular user. KDE starts OK for root, but for
> myself and for a newly created user, I see the splash screen and then
> four of the five splash icons come into focus. The last one never gets
> there and disk activity eventually ceases (I have left it for more than
> 30 mins).
> 
> I have tried renaming the .kde folder and the .kderc file, but this has
> not helped.
> 
> I can only stop the failed KDE session with ctrl-alt-BS which returns me
> to the terminal from which I tried to launch KDE with the startx
> command.
> 
> On that terminal I see various error messages from akonadi. If this is
> the cause of the trouble, what is the solution ? I notice that when KDE
> does launch successfully (for root) there is a progress bar displayed
> also connected with the akonadi server starting up - presumably
> successfully in that case.

I was waiting for someone who hopefully had a clue about slackware to 
respond, as I don't, /and/ I have little idea what's wrong with kde 
either.  However, as nobody else is taking a shot, I guess I'll post what 
vaguely possibly helpful ideas I have that might help...

First, the akonadi errors shouldn't be the problem -- akonadi's only the 
pim/contacts/organizer type service.  If you were having kontact/kmail/
korganizer type issues, that might be related, but it's not the problem 
here, since kde would still start in that case, tho it's possible the 
errors you see are /due/ to the same root problem.

That it was a kde 4.4 to 4.5 upgrade indicates that it's not a hal to u* 
(udev/upower/udisks, and friends) conversion issue, my next thought for 
permissions issues, since the hal to u* transition only happened with the 
kde 4.5 to 4.6 upgrade.

That it works as root but not as a normal user indicates it's a privileges/
permissions issue of /some/ kind.

That it fails equally with your normal and a new user indicates that it's 
not your user config.

That it worked fine on two other PCs indicates that it's not a generic 
distro issue.  Question:  Were the two that it worked fine on, on the same 
slack 13.1 (not some other version) before, to 13.37 now, all three 
running kde equally well, on the old version?  If so, then we know it's 
not an issue specific to that specific upgrade.

Beyond that, we don't have much to go on.  But, we DO know that it's a 
system (not user config) problem, that it works on two other machines, and 
that its almost certainly a permissions/privileges problem.  That's a 
start.

OK. From the is it kde itself or X, side of things...

Do you have any other X environments on the machine?  Can you install one 
if not?  We're not looking for anything fancy, so icewm or *box (for 
instance) as a wm and an xterm will do, as long as you know how to get it 
running from a text login using startx or the like.  The first thing to do 
is see if the user can start an X session with anything else BUT kde.  
Keep in mind that you can install the same environment to one of the 
working machines and try it there, so you know what should work on the bad 
machine...

Assuming that works, the next thing to do is see if you can run a kde app 
under that other environment.  Try running konsole or dolphin, or 
something simple like kpat.  Alternatively, if you regularly use other 
environments and run kde apps (like say k3b or amarok) from them so you 
know it worked before, test with them.  If you try launching the app from 
xterm, the debug info it spits out as it dies might be useful.  HOWEVER, 
kde apps OFTEN spit out a huge amount of alarming looking but apparently 
harmless information, so assuming the kde app won't run, again, it could 
be quite useful to compare against doing the same thing on a working 
system, so you have some idea what lines in the output are simply noise 
and not useful for troubleshooting.

If normal kde apps do work, you can borrow a trick I used back when I was 
upgrading from kde3 to kde4.  Run a bit more and a bit more of kde4, until 
there's little left that's NOT running.  plasma-desktop is the kde4 
desktop shell.  You can try running that.  And you can run kwin, replacing 
whatever window manager you were using in the non-kde environment, using 
kwin --replace.  If both kwin and plasma-desktop run without issue... it's 
something pretty core to kde, indeed!

And if kde apps do NOT work, what about qt4 but NOT kde apps?  To test 
that, you'll need a non-kde but qt4 app.  I only use a couple here, one 
rather specialized (qmpdclient, a qt-based mpd front-end), the other 
rather... large and possibly lots of dependencies if you don't have mplayer 
installed (smplayer, a power-user qt-based mplayer front-end similar to 
what kaffeine was for xine in kde3... the kde4 kaffeine wasn't even close, 
last time I checked, tho that was kde 4.3 era I believe so a couple years 
ago), so you may have to search for one, but if you already have mplayer 
installed, smplayer shouldn't be /too/ bad, dependency-wise.

Meanwhile, thinking about permissions, there's other bits of permissions 
related infrastructure to consider... dbus, polkit, consolekit, hal, udev, 
could even be that your OpenGL/3D is broken in X (the drm devices have 
permissions that root could override but not users), but 2D is fine.

To test the OpenGL thing, from your non-kde X, run glxgears and see if it 
runs, or test OpenGL rendering mode in smplayer if you have it installed.  
glxinfo run from xterm can be useful as well.  Try grepping for "OpenGL 
renderer string" and "OpenGL vendor string".  (Do note that if you don't 
know how to read glxinfo, however, some of the info it outputs can be 
deceiving.  The server glx vendor string will probably say SGI, regardless 
of whether opengl's working or not, and the version string will probably 
say 2.1 Mesa 7.10.2 or the like (that was mine), again, regardless of 
whether it's working or not.

And verify that you have the system hal, consolekit and dbus daemons 
running as appropriate.  (This is somewhat distro specific, but comparing 
what you have set to start on the working and non-working systems should 
be useful.)

The results of all those tests should give us considerably more 
information to work with. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.