Description of problem: Note: I'm filing this bug against kdelibs because that package owns klauncher but if that ends up being wrong, please change it. F9-KDE-LiveCD install, updated numerous packages from updates-testing, installed and removed numerous packages. At some point, without warning, KDE failed to start from login screen. Attempts to start from console yield attached output; fatal error seems to be related to klauncher and unknown application trying to embed in systray; relevant excerpt: [...] klauncher(30843)/kio (KLauncher) KLauncher::processRequestReturn: "/usr/bin/klipper" (pid 30893) up and running. <unknown program name>(30894)/ kdemain: Xlib XKB extension major= 1 minor= 0 plasma(30861) SystemTrayContainer::SystemTrayContainer: attempting to embed 4194307 Backtrace: 0: X(xf86SigHandler+0x79) [0x80d60c9] 1: [0x110400] 2: X(miHandleValidateExposures+0x37) [0x8127b07] 3: X(UnmapWindow+0x1f8) [0x8070368] 4: X(compFreeClientWindow+0x2d3) [0x8143e63] 5: X [0x813f914] 6: X(FreeResource+0x10c) [0x806db6c] 7: X(compUnredirectWindow+0x8b) [0x814322b] 8: X [0x814016c] 9: X [0x8128125] 10: X [0x812803c] 11: X(miChangeSaveUnder+0x6b) [0x81281db] 12: X(MapWindow+0x37b) [0x8070acb] 13: X(ProcMapWindow+0x69) [0x80851b9] 14: X(Dispatch+0x34f) [0x8085a3f] 15: X(main+0x47d) [0x806b3bd] 16: /lib/libc.so.6(__libc_start_main+0xe6) [0x4e05d6] 17: X(FontFileCompleteXLFD+0x22d) [0x806a7a1] Fatal server error: Caught signal 11. Server aborting klauncher(30843)/kio (KLauncher) KLauncher::processRequestReturn: "/usr/bin/ksensors" (pid 30896) up and running. kerneloops-applet: Fatal IO error 104 (Connection reset by peer) on X server :0.0. kdeinit4: Fatal IO error: client killed kdeinit4: sending SIGHUP to children. klauncher: Exiting on signal 1 kdeinit4: sending SIGTERM to children. kdeinit4: Exit. xinit: connection to X server lost. Hangup [...] Attempted to manually back-off updates and remove packages that were installed, but no joy. Google and bugzilla searches find nothing. Version-Release number of selected component (if applicable): F9-KDE-LiveCD install kernel-2.6.25.3-18.fc9.i686 How reproducible: Always. Steps to Reproduce: 1. Install F9-KDE-LiveCD 2. Update to all latest testing packages 3. Logout, attempt login. Actual results: KDE crash on login. Expected results: Successful login. Additional info: On request.
Created attachment 307004 [details] Console output from manual attempt to startx/startkde
1. Does problem exist for all users on this box, or just 1 in particular? Please try: 2. $yum groupinstall kde-desktop does problem still occur? if so, 3. $yum install yum-utils $package-cleanup --problems please report output.
Hello: 1. All users: already tried as root user, same results; tried just now with new user, same results; also tried (re)moving ~/.kde, .dbus, and .config, same results. Also tried with boot parameter 'selinux=off' (was: permissive), no help. 2. OK, with fedora, updates, and updates-testing repos enabled (had to enable updates-testing due to dependency requirements caused by prior updates/ installs), ran 'yum groupinstall "KDE (K Desktop Environment)": 35 packages in transaction - 4 updated, 31 installed (excerpt from yum.log attached). Then: startx, results same for all users including root. Tried 'mv ~/.kde ~/.kde- bku', startx, results: hard system lock-up, no recovery possible, required hard re-set. Re-booted, tried to graphical log in again, results: same (KDE crash near end of desktop start-up sequence). Next, tried from console login: 'yum groupremove "KDE (K Desktop Environment)"; 49 packages were removed; a whole huge pile of updates and add-ons had to be removed also before I could try again: 'yum groupinstall "KDE (K Desktop Environment)" BUT with only a custom-made temporary repo enabled using mirrors.kernel.org as the "base" install (probably should have just re- installed the whole OS, but then how would we find the problem?); results: same (KDE crash). Added another new user, same results. Checked again for --dupes and --problems - none. At this point, I took an inventory of all non-Fedora/Red Hat packages installed, and began to remove them, starting with ones that seemed likely to cause the problems. Gave up, installed E17 from kriehn repo, will continue to try to diagnose later from working graphical interface. Other suggestions welcome. 3. Already tried (repeatedly), also: 'package-cleanup --dupes' - no problems, no dupes, never, not once. Also repeatedly ran 'updatedb' just in case.... Thanx and Regards, VJS
Hello: Update: just to make it clear, E17 DE installed from 3rd-party repo is up and running just fine, so I have to believe that one of the (many) recent updates/ installs caused this problem. Also: when KDE was up and running, ~/.xsession- errors was at one point at 1.6 GB size. !? That's 1.6 GB !!! That's a text file - I didn't attempt to review it.... Currently: ~/.xsession-errors=329 kB after uptime=8.5 hours (E17). Thanx and Regards, VJS
Hello: At this point, I've got the non-Fedora/Livna/FreshRPMS/ATRPMs/KDE-RedHat/kriehn packages trimmed to: aim checkinstall cpuid jre libdrm (custom built from source code) libdrm-devel (ditto) opera Q7Z usermin webmin xorg-x11-drv-nouveau (custom built from source code) xorg-x11-drv-nv (ditto) ymessenger Not all of which were installed at the time problems started. Hope that info helps. Regards, VJS
Please revert to stock fedora versions of libdrm, and your x11-drv in use, else we'll not have much choice to lay blame there (on items not verifiable or confirmable outside of yourself and your box).
Created attachment 307317 [details] /var/log/kdm.log timestamp 2008-06-01 14:49 375K
Alright, then: libdrm-2.4.0-0.11.fc9.i386 (fedora) libdrm-devel-2.4.0-0.11.fc9.i386 (fedora) xorg-x11-drv-nv-2.1.8-1.fc9.i386 (fedora) xorg-x11-drv-nouveau-0.0.10-2.20080408git0991281.fc9.i386 (fedora) Also removed all proprietary nvidia driver packages from ATRPMs (which didn't work anyhow). If I should erase anything else to isolate this issue, I'll be happy to do so if asked. BTW, none of the above were installed prior to 5-29-2008 (the day after problems started, which is why I tried with video drivers compiled by myself). No change - cannot start KDE. 'package-cleanup --dupes[--problems]' continue to return nothing but blanks. 'rpm -Va' shows only the usual/expected outout. I'm attaching /var/log/kdm.log which goes all the way back to install date 5-26-2008. Not sure what to make of it.... Regards, VJS
Could you consider using the f9 kde live iamge? This would determine more conclusively if it's a fundamental problem with f9/kde4 or your box.
I'm a little disappointed that I didn't think to try that.... OK, booted the F9-KDE-LiveCD. Removed pulseaudio suite (doesn't work, fries speakers, floods ~/.xsession-errors), also some extraneous misc. gnomic tools and wireless drivers, etc. (same as before), setup display/xorg.conf, then proceded to update packages in small chunks, logging out of desktop and re- starting X-server in between. Got all the way through the alphabet, unfortunately that's all the farther I got: plenty of RAM and SWAP, but I guess this CPU can't handle any more work without installing - basically, the GUI ground to a halt, due to slow CPU. However, I found this in /var/log/messages: [...] Jun 2 03:16:04 micron-pc-rb kernel: klauncher[7698]: segfault at 8048814 ip 00a69da8 sp bfbb9200 error 7 in libX11.so.6.2.0[a54000+fd000] Jun 2 03:16:04 micron-pc-rb kdm[3732]: X server for display :0 terminated unexpectedly Jun 2 03:16:04 micron-pc-rb acpid: client connected from 7756[0:0] Jun 2 03:25:10 micron-pc-rb hddtemp[3239]: /dev/sda: WDC WD800JB-00JJC0: 102 F Jun 2 03:25:10 micron-pc-rb hddtemp[3239]: /dev/sdb: WDC WD1600AAJB-00PVA0: 109 F Jun 2 03:32:01 micron-pc-rb ntpd[3115]: synchronized to 138.23.180.126, stratum 2 Jun 2 03:55:37 micron-pc-rb ntpd[3115]: synchronized to 217.160.254.116, stratum 2 Jun 2 04:25:10 micron-pc-rb hddtemp[3239]: /dev/sda: WDC WD800JB-00JJC0: 102 F Jun 2 04:25:10 micron-pc-rb hddtemp[3239]: /dev/sdb: WDC WD1600AAJB-00PVA0: 107 F Jun 2 04:34:56 micron-pc-rb kernel: prelink[836]: segfault at a81 ip 0806a61f sp bfae6ec0 error 4 in prelink[8048000+107000] [...] There are many dozens more of the klauncher segfault errors logged since install, all the same except for PID number. libX11.so.6.2.0 (package libX11-1.1.4-1.fc9.i386) has not been altered in any way since install. BTW, I had also re-installed mesa-libGL (which had been replaced with the other Xorg stuff). Also FYI, the re-build Xorg stuff worked fine, it just didn't help with the KDE problem. Hope this helps. Thanx and Regards, VJS
OK, I finally got the second install of F9 to boot (turns out that it was an update to F8 GRUB dealing with "Inode size" that was the problem). Now I have _two_ extra F9 OS installs to test with (total of [3] F9's on that machine). The second F9 OS started a KDE session without any issues that I can see. I did also notice that ~/.xsession-errors is already quite large. Both of these two extra F9 installs are completely new and clean at the moment. I'm going to start updating packages on the first one. Any suggestions as to what else to try ? Anything in particular I should do / not do or look at ? Regards, VJS
Got it ! It's the 'nouveau' video driver (xorg-x11-drv-nouveau). Use 'nouveau', and KDE crashes - the farthest I got was to an active, loaded KDE desktop, but as soon as I tried to select anything with the mouse, bang! Crash, right back to the login screen - which also crashed if I tried to use the menus there: only typing the password and hit <Enter> actually did something besides cause a lock- up and re-start X. Also, could not switch to a VT from the login screen - locked up on all six VTs, but VT7 was still alive and OK (I could press ALT-CTL- F7 and get back a live login screen). Same results for all (3) users. I actually had to boot into the other OS and change xorg.conf there. Switched the driver back to 'nv', and now all is well. Still doesn't explain why the first F9 OS is still screwed up, because I've tried other video drivers on it too. Whatever happened to the first F9 install must have done a good job of messing things up. Nor does it explain why Enlightenment/E17 is immune to the 'nouveau' effect. Must not be many people using 'nouveau' on F9, or I would think there would be more reports of this.... Of course, I can't prove definitively that it is in fact 'nouveau', but the results of these attempts to track this down sure look make it look like that's the culprit. Regards, VJS
And the clue to solving the final piece of the puzzle came from this thread: http://forums.fedoraforum.org/forum/showthread.php?t=195131 The Culprit (in this case): xorg.conf 'Option "BackingStore" "true" ' Using the 'nv' video driver without "BackingStore" on allows KDE4 to succesfully launch a desktop session. All F9-KDE-Live OS installs now start KDE desktop sessions successfully, including the first one that hasn't worked now for almost two months.... "Warp power has been restored, Captain!" Which leaves the questions unanswered: > Why does video driver 'nouveau' cause KDE4 to lock-up/crash? > Why does Xorg option "BackingStore" on cause KDE4 to lock-up/crash? All other DEs/Window Managers are immune to these two phenomenon. Since a root cause and solution have been found (as far as I'm concerned), I'll be removing the extra F9-KDE-Live OS installs very shortly, unless someone needs more info (and gets back to me before I nuke them). Thanx and Regards, VJS
Glad to hear it. The BackingStore issue is likely an X server problem. *** This bug has been marked as a duplicate of 457377 ***