Bug 446307 - X won't start with telinit 5, startx works
X won't start with telinit 5, startx works
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
9
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: jmccann
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-13 20:55 EDT by D. Wagner
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-11-23 20:40:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/gdm/:0.log (29.04 KB, text/plain)
2008-05-13 20:59 EDT, D. Wagner
no flags Details
/etc/X11/xorg.conf (599 bytes, application/octet-stream)
2008-05-13 20:59 EDT, D. Wagner
no flags Details

  None (edit)
Description D. Wagner 2008-05-13 20:55:20 EDT
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-13 20:59:13 EDT
Created attachment 305310 [details]
/var/log/gdm/:0.log
Comment 2 D. Wagner 2008-05-13 20:59:44 EDT
Created attachment 305311 [details]
/etc/X11/xorg.conf
Comment 3 Simon Andrews 2008-05-15 06:34:33 EDT
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 12:16:21 EDT
(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 00:56:52 EDT
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-23 20:40:58 EST
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.

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