Bug 250225

Summary: GDM "hangs" if there are errors present in Xorg.0.log
Product: [Fedora] Fedora Reporter: Gian Paolo Mureddu <gmureddu>
Component: gdmAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 7CC: triage
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-06-17 02:01:33 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
Xorg.conf file. none

Description Gian Paolo Mureddu 2007-07-31 05:30:43 UTC
Description of problem:

First off a bit of background. This wasn't a problem in earlier Fedora/GDM
versions, and I'm assuming this issue is caused by upstream GDM, and while it
seems to be a bug, it may actually be a "feature" (one which I need to find out
how to disable). At any rate, the problem is as follows:

GDM seems to monitor the sanity of the X server. If there are errors present
during X initialization, GDM will not load. This may not seem like a problem,
however there are several conditions where this behavior may lead to user
confusion and frustration:

1) For example when a certain X module cannot load. Especially true for
configurations that may be using the proprietary nvidia driver and if there's no
correspondence between the X driver and the kernel module (most commonly seen
when the kernel is updated and the corresponding module is missing), then in X
there's going to be a condition which will prevent the GLX module to load, as
there is no way the card could do any acceleration. However X itself still
"works". This is caught by GDM and the result is that users can't "login" (not
even to try and figure out what might have gone wrong). The usual behavior in
this situation was that whenever any GL context was opened, the X server would
crash (guess GDM tries to prevent that "crashing" itself, or rather preventing
itself from running)

2) The problem I'm experiencing. When a given device cannot be initialized. This
goes as much for video as it goes for anything else. My problem is that that I
have configured a Wacom tablet to work with my Fedora 7 workstation. However if
the tablet is not present or attached to the computer when GDM loads, GDM will
find an error in X and will not start. The error, obviously is that Xorg cannot
initialize the wacom device. This is a rather serious problem for me, as I work
at a lab where there are more PCs than tablets and we need to swap the tablets
from one machine to another (rather than anchoring the machines to the tablets
or vice versa).

Currently the Wacom drivers doesn't support proper "hotplugging" so in order to
initialize them, users at the lab are instructed to exit the session and log
back in, or if the machine is at GDM, simply restart the server with
ctrl+alt+backspace (not the most elegant solution, but hey! It works). This has
worked rather well with the farm of FC6 machines we have. I was asked to see if
we could move the lab to F7, after installing it and configuring it on my main
machine and by chance discovering that not only critical errors would trigger
the above mentioned GDM behavior, but also "other" input device errors, which
are not by any means critical, as the CorePointer and CoreKeyboard are still
present, I was rather surprised.

Version-Release number of selected component (if applicable):

gdm-2.18.3-1.fc7

How reproducible:

Always

Steps to Reproduce:
1. (mis)configure anything that might cause "harmless" (EE)s in xorg.conf
2. Switch runlevels (to 3 then 5 or booting straight into 3 then edit, then
change to 5). GDM will display an error message stating that is has hung.
  
Actual results:

GDM doesn't load.

Expected results:

GDM to load when not critical errors are encountered (i.e, anything but the
Section "Device" failing)

Additional info:

Just for completeness sake, X loads and functions just "fine" by getting into
the session from a text console, switching to runlevel 3, killing the X server
and then issuing "startx"

Comment 1 Gian Paolo Mureddu 2007-07-31 05:30:43 UTC
Created attachment 160295 [details]
Xorg.conf file.

Comment 2 Bug Zapper 2008-05-14 13:46:03 UTC
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 3 Bug Zapper 2008-06-17 02:01:32 UTC
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.