KDE won't start in init 4
 

Since I'm the only user of this machine, I have it set to automatically login and no password, going straight to KDE. /etc/inittab default is init 4. That no longer happens.

I rebooted tonight to that other OS to update, and when I rebooted to Slackware64, I was presented with the KDM window. Huh? So I put in my username and password and just hit enter. Now it gets weird.

I had a black screen with a terminal box in the upper left corner and a user prompt. I typed startx, and it said display was already running and to take a hike. Obviously, I didn't get all of what it said - I just switched to root and issued init 3.

Logged in with username and password, typed startx, and all is well with the world. Except, I have no clue as to what is wrong with init 4.

Where do I look? There seems to be no problem in init 3.

Runlevel 4 is rarely ever used besides some special uses. Try switching to runlevel 5 instead next time. Most operating systems use runlevel 5 as the default.

First, have you upgraded or installed _anything_ at all today? Any packages? If you did, revert them back to whatever they were before, like by using "slackpkg upgrade new%old" to upgrade backwards to the older package. Try init 4 now.

If no go, then next let's verify (prove) that init-4 is not actually the problem. The only (main) difference between 3 and 4 is that in 4 the script(s) are executed to start X (specifically in your case, to start X and start KDE).

So, boot up as you did, either to init 4 or to init 3. Presumably you'll boot up to init 4 as usual, and get the KDM dialog. Now, switch over to another VT, log in as root, and issue the command "killall X" to kill X (hopefully X won't respawn; if it does, you'll need to use the KDM selector and choose "Console Login", and THEN proceed to the other VT).

You're still in init 4 at this point, so right now, `su` to your regular user or get yourself yet another VT and log in as regular user, and type "startx".

In theory, your KDE session should start just like it does in init-3. If so, now we know that init-4 is not itself the problem.

What next? Look at the X startup scripts, such as /etc/rc.d/rc.4 and the files in /usr/X11R6/lib64/X11/init and make sure that xinitrc points to xinitrc.kde and that xinitrc.kde exists and is not corrupted or whatever.

Check the permissions of such folders as /home/<your-user-account> as well as other system folders where regular users need to have read+/execute access to run stuff, such as /etc /usr /usr/bin /usr/lib and so on, to make sure that by some weird means, your user account hasn't been locked out of places it needs to read in order to function properly.

That's where I'd start. I've had similar troubles in the past, after having installed a package that had incorrect folder permissions inside it. The result of this is that every folder into which a piece of the newly installed package goes, gets its permissions changed to the "wrong" ones (too restrictive, usually :rolleyes: ) that are in the package. From there on, only root can seem to get around normally, until the problem's fixed.

Best of luck; let us know how you make out :)
Sasha

Although that may be true for many distributions, it's not for Slackware.
Runlevel 4 is the correct choice to have xdm/kdm/gdm started for you on slackware. Runlevel 5 on slackware is 'unused'.

This problem is now resolved. I had upgraded all of KDE from stock Slackware to these packages, including one new package:

http://cardinal.lizella.net/~vbatts/...ackages/4.3.1/

Something in there about Dolphin does not play nice. Now why it works in init 3, I don't know, but there is still the problem with Dolphin not playing nice. I installed the new KDE packages through slackpkg (4.2.4). I really did like the way KDE 4.3 looked, but those packages are not quite ready for Slackware.