Description of problem: GDM not usable after init 3/init 5 cycle, reboot required. Version-Release number of selected component (if applicable): Fedora 9, updated as of today. How reproducible: Always Steps to Reproduce: 1. #init 3 2. #init 5 Actual results: The GDM window is is just a non-functional white box. No texts, nowhere to enter user + password. Expected results: Working GDM window Additional info: Discovered when trying to install nvidia 3D driver (which does not work, for sure). My system is an upgraded fc8 - rawhide - fc9 system (2 upgrades). It is still possible to use another virtual console to reboot the machine, but I see no other way to restore GDM after a "#init 3". Attaching the gdm logs.
Created attachment 305336 [details] greeter.log, looks the same whether gdm works or not.
Created attachment 305337 [details] The X log
I have a related issue with similar hardware and results (BZ446395). I can trigger the failure by simply launching a second X session after the first one closes, this can be via init3 > init5, running startx twice, or even rhgb launching gdb. I suspect the underlying causes of these issues may be related.
Using gdb, I noticed that the stack trace from gdm-greeter was different in the two cases work /does not work. This *might* be significant, since gdm-greeter seems is definitely stuck somewhere when this problem occurs. Attaching gdb backtrace from gdm-greeter when it works, and when not.
Created attachment 305665 [details] Gdb backtrace (in the end) from failing gdm-greeter
Created attachment 305666 [details] Gdb stacktrace (in the end) from working gdm-greeter
Unfortunately that stack trace is a little sparse. Would you mind running the debuginfo-install command that gdb mentioned in your attachment and getting it again?
Created attachment 305684 [details] Stacktrace with some symbols installed
No, this is most likely *not* a gdm issue, my mistake. Sorry. If I in single-user mode try a 'startx' I get my blue desktop background. In the default panel positions (top/bottom) there is a different, solid blue color. In this state, it stalls. Bottom line: it seems hard to start anything, be it gdm or a session, from single-user mode. I guess this should be reassigned, although I have no idea to whom. It would be nice to know if this is related to my specific sw/hw configuration, or could be reproduced by anyone.
As I put in comment #3 I can reproduce this. There is also a similar bug reported on gdm: https://bugzilla.redhat.com/show_bug.cgi?id=446307 ..so I think it's a more widespread issue. For the record, my setup is also x86_64 with an Nvidia card. I've filed my bug under xorg-server, since I can reproduce it with both the nv and framebuffer drivers. Given the severity of the crash though, I'm not entirely convinced it's not going to be a kernel issue.
Resolving as a duplicate of bug 446395. The difference is that I'm in somewhat better position to assist anyone needing more info since I have a running kernel and virtual terminals after the crash (bug 446395 describes a completely unresponsive system once the bug is triggered). I'm raising the severity based on the fact that this bug actually requires a reboot. *** This bug has been marked as a duplicate of 446395 ***