Bug 446346 - gdm fails after init 3/init 5
gdm fails after init 3/init 5
Status: CLOSED DUPLICATE of bug 446395
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
9
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: jmccann
Fedora Extras Quality Assurance
n/a
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-14 03:54 EDT by Alec Leamas
Modified: 2015-01-14 18:21 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-19 10:52:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
greeter.log, looks the same whether gdm works or not. (348 bytes, text/plain)
2008-05-14 03:54 EDT, Alec Leamas
no flags Details
The X log (35.20 KB, text/plain)
2008-05-14 03:56 EDT, Alec Leamas
no flags Details
Gdb backtrace (in the end) from failing gdm-greeter (12.01 KB, text/plain)
2008-05-16 05:23 EDT, Alec Leamas
no flags Details
Gdb stacktrace (in the end) from working gdm-greeter (11.70 KB, text/plain)
2008-05-16 05:26 EDT, Alec Leamas
no flags Details
Stacktrace with some symbols installed (14.92 KB, text/plain)
2008-05-16 09:51 EDT, Alec Leamas
no flags Details

  None (edit)
Description Alec Leamas 2008-05-14 03:54:08 EDT
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 03:54:08 EDT
Created attachment 305336 [details]
greeter.log, looks the same whether gdm works or not.
Comment 2 Alec Leamas 2008-05-14 03:56:13 EDT
Created attachment 305337 [details]
The X log
Comment 3 Simon Andrews 2008-05-15 06:38:54 EDT
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 05:22:43 EDT
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 05:23:38 EDT
Created attachment 305665 [details]
Gdb backtrace (in the end) from failing gdm-greeter
Comment 6 Alec Leamas 2008-05-16 05:26:09 EDT
Created attachment 305666 [details]
Gdb stacktrace (in the end) from working gdm-greeter
Comment 7 Ray Strode [halfline] 2008-05-16 09:48:51 EDT
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 09:51:00 EDT
Created attachment 305684 [details]
Stacktrace with some symbols installed
Comment 9 Alec Leamas 2008-05-16 10:29:43 EDT
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 04:06:34 EDT
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 10:52:20 EDT
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 ***

Note You need to log in before you can comment on or make changes to this bug.