Description of problem: gdm/Xorg weirdness: X won't work at boot; killing first (of two) Xorg processes and toggling runlevels 3/5 enables vt7. Other vt's are not available (get a gray-dotted screen). Version-Release number of selected component (if applicable): gdm-2.18.2-1.fc7 How reproducible: always Steps to Reproduce: 1.boot 2. Actual results: gdm errors at boot ... two Xorg processes ... killing the first and toggling runlevels 3/5 starts a working Xorg on vt7; other vt's aren't available. Expected results: gdm starts working xorg process; all vt's available Additional info: From boot log: ... gdm[2401]: gdm_config_parse: Standard X server not found; trying alternatives ... gdm[2401]: no suitable security token driver could be found ... gconfd (root-2389): GConf server is not in use, shutting down. Two Xorg's after boot: # ps aux | grep Xorg root 2353 87.6 0.2 11740 4872 ? Rs 10:22 0:58 /usr/bin/Xorg -logfile /dev/null :9 vt6 -config /tmp/XConfig.test -extension Composite -s 1440 -dpms -v -ac -nolisten tcp -screen Firstboot root 2453 0.0 0.0 5744 1864 tty7 Ss+ 10:23 0:00 /usr/bin/Xorg :0 -auth /var/gdm/:0.Xauth -nolisten tcp vt Single working Xorg after toggling runlevels: # ps aux | grep Xorg root 2783 80.5 0.1 10620 3808 tty7 Rs+ 14:53 0:01 /usr/bin/Xorg :0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7 This has been observed on Dell Optiplex GX620's and GX280's with Intel 82915G/GV/910GL and 82945G/GZ Integrated Graphics Controllers. i810, i915 and vesa drivers exhibit the same behavior.
solution: firstboot was enabled at boot by default at rc5; disabled at chkconfig and everything is fine.(In reply to comment #0) > Description of problem: > gdm/Xorg weirdness: X won't work at boot; killing first (of two) Xorg processes > and toggling runlevels 3/5 enables vt7. Other vt's are not available (get a > gray-dotted screen). > > Version-Release number of selected component (if applicable): > gdm-2.18.2-1.fc7 > > How reproducible: always > > > Steps to Reproduce: > 1.boot > 2. > > Actual results: > gdm errors at boot ... two Xorg processes ... killing the first and toggling > runlevels 3/5 starts a working Xorg on vt7; other vt's aren't available. > > Expected results: > gdm starts working xorg process; all vt's available > > Additional info: > From boot log: > > ... gdm[2401]: gdm_config_parse: Standard X server not found; trying alternatives > ... gdm[2401]: no suitable security token driver could be found > ... gconfd (root-2389): GConf server is not in use, shutting down. > > Two Xorg's after boot: > > # ps aux | grep Xorg > root 2353 87.6 0.2 11740 4872 ? Rs 10:22 0:58 /usr/bin/Xorg > -logfile /dev/null :9 vt6 -config /tmp/XConfig.test -extension Composite -s 1440 > -dpms -v -ac -nolisten tcp -screen Firstboot > root 2453 0.0 0.0 5744 1864 tty7 Ss+ 10:23 0:00 /usr/bin/Xorg > :0 -auth /var/gdm/:0.Xauth -nolisten tcp vt > > Single working Xorg after toggling runlevels: > # ps aux | grep Xorg > root 2783 80.5 0.1 10620 3808 tty7 Rs+ 14:53 0:01 /usr/bin/Xorg > :0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7 > > This has been observed on Dell Optiplex GX620's and GX280's > with Intel 82915G/GV/910GL and 82945G/GZ Integrated Graphics Controllers. i810, > i915 and vesa drivers exhibit the same behavior.
Do you know if rhgb was enabled (in grub on the kernel commandline) when you encountered this issue?
(In reply to comment #2) > Do you know if rhgb was enabled (in grub on the kernel commandline) when you > encountered this issue? I'm almost positive it wasn't.
Okay, this is probably a combination of three things 1) a bug in firstboot where it doesn't wait for its X server to die before exiting 2) a bug in your X driver since it can't handle one X server exiting while the other is coming up 3) unlucky timing with your hardware configuration that makes the new X server coming up start before the other comes down
This should be fixed in the next build of firstboot. Thanks to Ray for figuring this out on the RHEL side, which was easy enough to adapt to Fedora.