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.
Created attachment 305310 [details] /var/log/gdm/:0.log
Created attachment 305311 [details] /etc/X11/xorg.conf
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.
(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
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.
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.