Bug 446307

Summary: X won't start with telinit 5, startx works
Product: [Fedora] Fedora Reporter: D. Wagner <daw-redhatbugzilla>
Component: gdmAssignee: jmccann
Status: CLOSED WORKSFORME 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   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-11-24 01:40:58 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
/var/log/gdm/:0.log
none
/etc/X11/xorg.conf none

Description D. Wagner 2008-05-14 00:55:20 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.14) Gecko/20080416 Fedora/2.0.0.14-1.fc8 Firefox/2.0.0.14 pango-text

Description of problem:
I initially installed Redhat 9 Beta, and had X working at one point.  After some number of upgrades, it no longer boots into X; instead, it boots into initlevel 3 (that's all that's in /etc/inittab).  I cannot figure out how to get it to boot into X.

If I run "telinit 5", I get a blank screen and the machine freezes, with no way to bring it back except to do a hard power reset.

If I run system-config-display --reconfig, it exhibits the same behavior: blank screen, machine freezes, and no way to bring it back short of a hard power-off.  Once it is in the frozen state, Ctrl-Alt-Del, Ctrl-Alt-Backspace, Ctrl-Alt-F1 don't do anything, and I can't log in via ssh any more (but I was able to log in via ssh before the freeze).

However if I log in as a non-root user and run "startx", then I do get a working X and working desktop.

I don't really know what component is responsible: I've filed it under gdm, but that's just a blind guess.

Version-Release number of selected component (if applicable):
gdm-2.22.0-1.fc9.x86_64

How reproducible:
Always


Steps to Reproduce:
1. Boot
2. Log in
3. telinit 5

Actual Results:
Blank screen; machine freezes.

Expected Results:
Working X; get a GDM greeter.

Additional info:
This is on a x86_64 2-CPU machine, running the latest Fedora 9 (yum upgrade run fully).  Some additional information, which may or may not be relevant:

# ls -l /etc/X11/X
lrwxrwxrwx 1 root root 18 2008-05-13 10:30 /etc/X11/X -> ../../usr/bin/Xorg
# cat /etc/sysconfig/hw-uuid 
c2e6d017-9514-4dec-932f-a5ae57e30f8e
# cat /var/log/gdm/:0-greeter.log 
** (process:2152): DEBUG: Greeter session pid=2152 display=:0 xauthority=/var/run/gdm/auth-cookie-XXP9UQAU-for-gdm
gdm-simple-greeter[2152]: WARNING: StartWithSettingsPrefix org.freedesktop.DBus.Error.NoReply raised: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

gdm-simple-greeter[2152]: WARNING: Couldn't start settings daemon
# rpm -q gdm gdm-debuginfo xorg-x11-server-Xorg xorg-x11-drv-nv 
gdm-2.22.0-1.fc9.x86_64
gdm-debuginfo-2.22.0-1.fc9.x86_64
xorg-x11-server-Xorg-1.4.99.901-29.20080415.fc9.x86_64
xorg-x11-drv-nv-2.1.8-1.fc9.x86_64


Here is a snippet from /var/log/messages that seems like it may be relevant:

May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Adding handler 1: signum=15 0x406000
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Registering for 15 signals
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Adding handler 2: signum=2 0x406000
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Registering for 2 signals
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Adding handler 3: signum=4 0x406000
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Registering for 4 signals
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Adding handler 4: signum=7 0x406000
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Registering for 7 signals
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Adding handler 5: signum=8 0x406000
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Registering for 8 signals
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Adding handler 6: signum=1 0x406000
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Registering for 1 signals
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Adding handler 7: signum=11 0x406000
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Registering for 11 signals
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Adding handler 8: signum=6 0x406000
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Registering for 6 signals
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Adding handler 9: signum=10 0x406000
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Registering for 10 signals
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSlave: Registering /org/gnome/DisplayManager/Slave1
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSlave: starting slave
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSlave: Starting slave
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSlave: Creating proxy for /org/gnome/DisplayManager/Display1
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSlave: Got display id: /org/gnome/DisplayManager/Display1
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSignalHandler: Adding handler 10: signum=10 0x40c040
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmServer: Starting X server process: /usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-cookie-XXYHYVAU-for-gdm -nolisten tcp
May 13 10:33:11 senfl gdm-simple-slave[2590]: DEBUG: GdmServer: Opening logfile for server /var/log/gdm/:0.log
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmServer: Started X server process 2590 - waiting for READY
May 13 10:33:11 senfl gdm-simple-slave[2589]: DEBUG: GdmSimpleSlave: Started X server
May 13 10:33:11 senfl acpid: client connected from 2590[0:0]
May 13 10:33:12 senfl kernel: mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining


I'll attach /etc/X11/xorg.conf, /var/log/gdm/:0.log.
Comment 1 D. Wagner 2008-05-14 00:59:13 UTC 
Created attachment 305310 [details]
/var/log/gdm/:0.log
Comment 2 D. Wagner 2008-05-14 00:59:44 UTC 
Created attachment 305311 [details]
/etc/X11/xorg.conf
Comment 3 Simon Andrews 2008-05-15 10:34:33 UTC 
I have a similar issue, but it seems the problem is more generic, and can be
tiggered by simply restarting X for a second time.  See BZ446307 for details,
but I suspect these bugs are going to have the same underlying cause - I also
get and mtrr error, albeit a different one to yours.
Comment 4 D. Wagner 2008-05-15 16:16:21 UTC 
(In reply to comment #3)
> I have a similar issue, but it seems the problem is more generic, and can be
> tiggered by simply restarting X for a second time.  See BZ446307 for details,
> but I suspect these bugs are going to have the same underlying cause - I also
> get and mtrr error, albeit a different one to yours.

I'm guessing you're referring to bug #446395 (and possibly bug #446346), right?
 Yes, I also had a similar-looking mtrr error.

In case it is helpful, here is the contents of my /proc/mtrr:
# cat /proc/mtrr 
reg00: base=0x00000000 (   0MB), size=65536MB: write-back, count=1
reg01: base=0xcff00000 (3327MB), size=   1MB: uncachable, count=1
reg02: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg03: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
Comment 5 D. Wagner 2008-05-16 04:56:52 UTC 
I did some more testing, and I verified that

(a) if I boot without rhgb, then I can run telinit 5 and the crash doesn't happen.

(b) if I boot with rhgb, then when I try to run telinit 5, the crash still happens.

Strangely, whether or not I use rhgb, the machine automatically boots into
initlevel 3.  I can't figure out why.  I've changed my /etc/inittab to have

id:5:initdefault:

I can't figure out why it won't boot into X mode (initlevel 5) and why it seems
to ignore my /etc/inittab and always boot into initlevel 3.  Any idea?  (Is this
some new upstart thing?)  Anyway, I thought I'd provide the additional
information in case it helps troubleshoot this bug.
Comment 6 D. Wagner 2008-11-24 01:40:58 UTC 
It's working now.  I'm not sure what the original cause was (perhaps it was pilot error), but I'm closing this bug report.