Bug 446346

Summary: gdm fails after init 3/init 5
Product: [Fedora] Fedora Reporter: Alec Leamas <leamas.alec>
Component: gdmAssignee: jmccann
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 9CC: cschalle, rstrode, simon.andrews
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
URL: n/a
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-19 14:52:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
greeter.log, looks the same whether gdm works or not.
none
The X log
none
Gdb backtrace (in the end) from failing gdm-greeter
none
Gdb stacktrace (in the end) from working gdm-greeter
none
Stacktrace with some symbols installed none

Description Alec Leamas 2008-05-14 07:54:08 UTC
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.

Comment 1 Alec Leamas 2008-05-14 07:54:08 UTC
Created attachment 305336 [details]
greeter.log, looks the same whether gdm works or not.

Comment 2 Alec Leamas 2008-05-14 07:56:13 UTC
Created attachment 305337 [details]
The X log

Comment 3 Simon Andrews 2008-05-15 10:38:54 UTC
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.

Comment 4 Alec Leamas 2008-05-16 09:22:43 UTC
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.

Comment 5 Alec Leamas 2008-05-16 09:23:38 UTC
Created attachment 305665 [details]
Gdb backtrace (in the end) from failing gdm-greeter

Comment 6 Alec Leamas 2008-05-16 09:26:09 UTC
Created attachment 305666 [details]
Gdb stacktrace (in the end) from working gdm-greeter

Comment 7 Ray Strode [halfline] 2008-05-16 13:48:51 UTC
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?

Comment 8 Alec Leamas 2008-05-16 13:51:00 UTC
Created attachment 305684 [details]
Stacktrace with some symbols installed

Comment 9 Alec Leamas 2008-05-16 14:29:43 UTC
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.

Comment 10 Simon Andrews 2008-05-19 08:06:34 UTC
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.

Comment 11 Alec Leamas 2008-05-19 14:52:20 UTC
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 ***