From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20040803 Description of problem: Note: we have run into this problem on over a dozen systems; I'll just give details for one or two here. Starting with a new installation of RHEL 3.0 (original CDs, not update 1 or 2), I can boot into runlevel 5 and have X-windows/gdm start normally, either with the Xfree VESA driver or the latest nVidia driver (AGP video card has GeForce MX4000 chipset.) After running up2date and installing all available packages, when I subsequently reboot, X does not start but gives the message 'Id "x" respawning too fast: disabled for 5 minutes'. When I log in now, without X running, and type "startx" my desktop starts normally. Similarly if I log in as root and run ". /usr/bin/gdm" the GDM login screen appears. The same behavior happens with both the VESA driver and 3rd-party nVidia driver. So I don't think there's a problem with X in general here ... just a problem starting it via init in runlevel 5 with the latest set of RHEL updates. On another system in our dept, we installed from the RHEL update 2 CD and X worked fine. After putting on kernel-2.4.21-15.0.4.EL and restarting, the problem described above started. Surprisingly, if we then booted to the original kernel-2.4.21-15.0.2.EL, the problem still occurred. I'm not sure what config files or log files would be useful here. Please let me know if you'd like to see any of them. Also I can provide more detailed HW info if warranted. Version-Release number of selected component (if applicable): XFree86-4.3.0-62.EL How reproducible: Always Steps to Reproduce: 1. Boot system in runlevel 5 2. 3. Actual Results: X does not start, message 'Id "x" respawning too fast: disabled for 5 minutes" appears on console (and in /var/log/messages every 5 minutes thereafter or until system is taken to runlevel 3). Expected Results: GDM login screen should appear. Additional info:
First you'll need to uninstall the proprietary Nvidia driver, and restore the Red Hat supplied xorg-x11 packages, as Nvidia's driver overwrites several Red Hat supplied X server modules/libraries, resulting in an unsupported OS installation. Once you've removed the proprietary driver, and reproduced the problem with the 'nv' or 'vesa' drivers, please attach the X server log file and config file, as well as /var/log/messages from the problematic setup. Since the X server is running normally for you with startx, it is difficult to determine what the problem is without additional information. Please indicate any error messages you see on screen at the console, etc. that might be related. Thanks in advance.
I am attaching /etc/X11/XF86Config, /var/log/XFree86.0.log, and the relevant part of /var/log/messages for a RHEL AS 3.0 system that I just installed from scratch and which has never had any third-party video drivers on it at all. Unfortunately it does show the problem I've described originally. In the case of the logs that I'm attaching, I booted directly into runlevel 5, gdm didn't start, I logged in from another system and ran ". /usr/bin/gdm", X started and the gdm login screen appeared, and then I logged in directly via the gdm login.
Created attachment 108050 [details] /etc/X11/XF86Config
Created attachment 108052 [details] /var/log/XFree86.0.log
Created attachment 108053 [details] /var/log/messages (for boot into runlevel 5 as described in Comment #2)
Some additional info: if in /etc/X11/prefdm I force the preferred desktop to be xdm rather than the default (which in my case is gdm) then X and the desktop login screen start normally when booting into runlevel 5. Could the problem be that you have to start gdm as ". /usr/bin/gdm" but the prefdm script tries to "exec" it?
I figured out what the problem is. One of our configuration scripts in /etc/profile.d echoes output to stdout. When the echo output is not produced (eg when that part of the script is commented) gdm starts normally at boot time in runlevel 5. I am not sure why the echo output causes the problem, but it's easy to work around so this issue can be closed.
Closing "WORKSFORME", as per comment #8.