Whenever someone selects the KDE environment (either via gdm or kdm), ksplash gets to 83% and then hangs. The environment seems actually functional. As soon as the user runs a different program, the percentage jumps to 100% and the splash screen goes away.
This defect is considered MUST-FIX for Winston Release-Candidate #1
For me, this does not occur on just the "first" login. It happens every time. I get to "83%" and hang. I then use "ctl-alt-backspace" to get out. When I try again, it does the same thing. Also, it does the same thing when done from startx. Also, the "User Configuration" "green light" never goes on when it starts on the Session. Gene
If I leave the splash screen at 83% and kill X with ctrl-alt-backspace, the same problem happens the next time I log in. However, if I ignore the splash screen and start another app (making the splash go away) and then log out normally, when I log in again, there isn't a problem.
OK, I give up -- how do you start another app?? When I get hung in the startup screen, the only thing I have is the startup screen and a grey background -- no panels, no icons, no mouse-click menus, no nothing. Gene
Interesting. I get the full KDE environment -- panels, menus, everything.
I wonder if this is some sort of time problem (race condition). I get the same results on two systems tested: (1) a dual processor PII 400MHz with ATI Rage Pro video and (2) a dual processor PIII 600MHz with TNT2 video ... both woith 256MB ram.
OK, did some additional testing -- 1. Running pinstripe (workstation gnome & kde install) under vmware, I got results similar to those of mattdm ... everything came up but splash screen hung at 83% and disappears when I started a terminal. 2. Running on real hardware (dual PII 400MHz) but with the up kernel, I got slightly different results ... screen when grey and the splash panel started BUT completed to 100% and then disappeared. HOWEVER, no panel, no anything but a clear grey screen. (ctl-alt-backspace to get out). Note that the Desktop and User Configuration "lights" did NOT go on. This is very confusing.
And on yet another vmware system running as a guest on a rhl 6.2 PIII 600MHz dual processor, kde fails the same way it does on real hardware.
*** Bug 14954 has been marked as a duplicate of this bug. ***
Fixed in rawhide by going back to kde 1 for now (kde 2 will be back). The problem is an odd bug in the session management code; currently looking at it (and fixing in CVS).