Description of Problem:
X server will not start after new installation. Message reported as follows:
INIT: ID "x" respawning too fast. Disabled for 5 minutes.
Version-Release number of selected component (if applicable):
Redhat Linux 7.3. More detailed information is not known.
Fresh installation. System is a Dell OptiPlex Gn 200Mhz Pentium with an
S3Trio64+ video card, Princeton Ultra72 monitor, 6GB IDE hard drive, ATAPI CD-
ROM, 128MB RAM.
Steps to Reproduce:
System boots, but X server does not start.
X login prompt.
A similar thing occurred when an attempt to upgrade this system, previously
running Redhat Linux 7.1, to 7.3 was performed. In that case, no textual login
prompt was seen after booting post-install. The monitor could be heard
constantly switching modes about once every two seconds. No video was displayed
at all. Hard drive repartitioning and fresh installation simply changed the
symptoms of the problem, which I believe was the same in both cases (upgrade
and new installation).
I am basically dead in the water here. Will probably have to reinstall 7.1.
During install, Workstation configuration was chosen and all package groups
were selected (GNOME, KDE, Development, and Entertainment).
Attach your X server log and configuration file(s) using the link below.
In response to your request, I regret to tell you that I had to revert the
system back to RHL 7.1. This particular system is used heavily and cannot be
kept in a hung state to analyze such a problem. Given that, I can at least
share my observations regarding the behavior of the X server as I made futile
attempts to figure out what might be wrong.
After the clean install, the console (text) login prompt was present. So I
logged in as root and tried starting the X server manually via the "startx"
command. This resulted in some error messages that were somewhat confusing. For
instance, the program complained that the "LeftAlt" keyword (and others in that
section of the XF86Config file) were not recognized. In a probing effort, I
commented-out lines with cited keywords and noticed that it was complaining
about things I was sure were valid (at least they were in 7.1). For instance,
another item it cited was the lack of a "Device" specified in the "Driver"
Comparing my mental image of the 7.3 X config file with what is currently in my
7.1 installation, they appear identical to me. All those keywords startx
complained about are there and apparently correct.
Sorry I could not provide the X server log file. If you have something you'd
like for me to try and you feel confident it may resolve this problem, I may be
willing to attempt the 7.3 install again.
One thing I did not mention in my original post is that the message in the
Summary section of this bug description appeared about every 5 minutes (maybe
slightly longer). I guess I figured that would have been pretty obvious.
Correction to last post. The passage
"For instance, another item it cited was the lack of a "Device" specified in
the "Driver" sections."
should have read
"For instance, another item it cited was the lack of a "Driver" specified in
the "Device" sections.
While I appreciate your efforts of reporting this bug, Red Hat does
not have every piece of video hardware and motherboard available with
which to troubleshoot problems that are reported. As such, with most
XFree86 bug reports, we often require the user having the problem to
test various things and provide various log files, config files, and
results of other tests back to us while we try to troubleshoot the
It sounds like this is a production system which you are not able
to provide the time/energy to aide in troubleshooting. This is
unfortunate because without access to such a system, there is nothing
we can do to resolve the issue, unless someone having the problem
is willing and able to troubleshoot it.
If you can at least provide the output of "lspci -v" and also "lspci -vn"
from the system in question, I will see about changing the default
driver options or change drivers.
I agree and I most definitely wish I could do more. Perhaps I can acquire
another hard drive from our IS department and try the install again to get the
information you request. The main problem(s) with that will be A) I work on
contract and there is no funding for me to do this sort of research, B) our IS
department may not have a spare hard drive, C) I simply may not have the time
(the installation takes about 45 minutes on this rather old/slow system). As
it stands, RHL 7.1 is and has been performing fine for me since it was first
installed. My only reason for upgrading in the first place was that I like to
keep my software development systems as current as possible. Again, I will see
what I can do, but no promises.
Please try manually selecting the "vesa" driver instead. Or try our
new release when it comes out, as it should work correctly. Our current
beta release should also work correctly for this card, by choosing the
The 7.3 installation program ERRONEOUSLY symlinked /usr/X11R6/bin/X to /usr/X11R6/bin/XFree86 (the 4.2.0 version of the X server).
It should have instead symlinked /usr/X11R6/bin/X to /usr/X11R6/bin/XF86_S3 (the 3.3.6 version of the X server, which the installation program did
correctly install for the older S3 Trio64 video card).
People with older video cards should be warned of this problem with the 7.3 upgrade.
Thanks to Thomas Dodd, Michael Fratoni, and David Wood for their ID and fix to this bug (in their earlier posts on valhalla-list).
An additional comment that may be of further help:
Upon the relink of the X symlink (to XF86_S3), startx comes up as expected. IF you're logged in as "root".
When non-root, startx (on the XF86_S3 server) fails, due to the file permissions settings on XF86_S3.
One fix (somewhat scary however, as it opens up a security hole with the X server), is to set SUID on the XF86_S3 file, via:
# chmod 4711 XF86_S3
Hope this helps.
btw... does anyone know of a safer way to set the permissions for this? Thanks in advance.