KDM not starting after upgrade
1i5t5.duncan at cox.net
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
> 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
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
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
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.
More info: http://www.kde.org/faq.html.
More information about the kde