Description of problem: Update to xorg-x11-server and common rpm 1.5 breaks graphical boot. xorg.conf unchanged. Version-Release number of selected component (if applicable): xorg-x11-server-common-1.4.99.905-2.20080702.fc9.i386 works as expected- How reproducible: Always... Steps to Reproduce: 1. 'yum update' updates two packages: xorg-x11-server-Xorg i386 1.5.0-1.fc9 updates-newkey 1.5 M xorg-x11-server-common i386 1.5.0-1.fc9 updates-newkey 70 k 2. updating... 3. ..done. Actual results: xorg does start now without any errors - at runlevel 5 (gdm) but rhgb is lost. There is no graphical boot anymore. Restoring to latest xorg of fc9 (xorg-x11-server-Xorg-1.4.99.905-2.20080702.fc9.i386)... ...rhgb comes up to live. Expected results: graphical boot again with updated xorg server binaries. Additional info: It's a IBM Thinkpas T40 with radeon mobile 7500, using the included 'radeon' driver of xorg...
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Required files attached (after the already described two updates again)... I'm a little bit confused currently about changes on this page... Have to check where I can upload the required files...
Created attachment 317115 [details] xorg log from xorg 1.5 ...found...
xorg config file attached... Nothing important there I think...
Created attachment 317116 [details] the required xorg.conf xorg.conf for IBM Thinkpad T40 (ATI Radeon mobility 7500 32mb RAM) on Fedora 9 with all updates.
Reboot without any xorg.conf (renamed to xorg.conf_) does not re-animate the missed rhgb (as rghb is cosmetics), but I can't login now to gdm (it's codepage related now). Switching back to my xorg.conf ;-)
This report looks like my problem too. Update of x11 packages break rhgb. Sep 17 07:24:15 Updated: xorg-x11-server-common-1.5.0-1.fc9.i386 Sep 17 07:24:36 Updated: xorg-x11-server-Xorg-1.5.0-1.fc9.i386 Sep 17 07:24:37 Updated: xorg-x11-drv-evdev-2.0.4-1.fc9.i386 After updates noted above I the Red Hat Graphical Boot failed to run at boot-up. I determined the avaliable previous versions and downloaded: xorg-x11-server-common-1.4.99.901-29.20080415.fc9.i386.rpm xorg-x11-server-Xorg-1.4.99.901-29.20080415.fc9.i386.rpm xorg-x11-drv-evdev-1.99.1-0.5.fc9.i386.rpm I installed. rpm -i --force *.rpm When I rebooted rhgb started and ran OK. I reinstalled the current versions of the packages and rhgb is broken. I have two systems here that fail exactly the same way. Both are home builds. One with a biostar motherboard the other has a gigabyte motherboard. Both have nvidia gpu's and use nvidia proprietary driver.
Created attachment 317119 [details] Xorg.0.log with broken rhgb Attached Xorg.0.log.
Created attachment 317121 [details] No /etc/X11/xorg.conf Xorg.0.log
Created attachment 317123 [details] DMESG broken rhgb
I confirm the problem. Also I tweaked /etc/rc.sysinit file so that rhgb is run with -d parameter and more debug info is printed, including X.org error logs. That info shows the source of problem. Apparently, X server tries to compile keyboard description and write it to /var/lib/xkb/, but fails since / is mounted read-only when rhgb starts. So server shuts down and rhgb quits.
After reading Vadim Zborovskii's Comment 11, I examined /etc/rc.d/rc.sysinit. The logic appears flawed in rc.sysinit. rhgb is started in a sub-shell and no test is made to determine if rhgb started and continued to run. The file HOW_IT_WORKS in /usr/share/doc/rhgb-9.0.0 describes the reason why there are two attempts to start rhgb in rc.sysinit. I determined that RHGB_STARTED=1 is always executed on the first attempt to run rhgb. When the X server failed due root being read only, rhgb quits as Vadim described, but because RHGB_STARTED=1, no second attempt to run rhgb is executed. I patched my rc.sysinit as follows: 310c310,312 < RHGB_STARTED=1 --- > if [ -x /usr/bin/rhgb-client ] && /usr/bin/rhgb-client --ping ; then > RHGB_STARTED=1 > fi 685c687,689 < RHGB_STARTED=1 --- > if [ -x /usr/bin/rhgb-client ] && /usr/bin/rhgb-client --ping ; then > RHGB_STARTED=1 > fi The patched rc.sysinit starts rhgb on the second attempt. I suspect there is still a problem in the new X server or rhgb that needs to be addressed, but rc.sysinit definitely needs to be fixed.
(In reply to comment #12) > > The logic appears flawed in rc.sysinit. Shifting blame to initscripts then...
Fixed in git, although there may not be an update. I'm concerned about what could cause X to fail when it didn't before - the xkb error should not be fatal. Bouncing back to X for now.
initscripts-8.76.4-1 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/initscripts-8.76.4-1
initscripts-8.76.4-1 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.