Description of problem:
I have an FX 5200 video card. I downloaded the drivers from
www.nvidia.com (NVIDIA-Linux-x86-1.0-6629-pkg1.run) and used their gui
to compile and install. Everything worked great. However each time I
reboot the machine, the drivers become corrupt, lost, ?, etc. and I
have to run the gui again and recompile the driver. After
recompiling, startx works fine.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Reboot machine
Have to reinstall the nvidia drivers
should be able to startx without having to recompile drivers each time
Let me know what other info may be relevant
Thanks for the report. This is a bug in Nvidia's software, which
I am informed does not properly handle udev.
For users who are experiencing problems installing, configuring,
or using the unsupported 3rd party proprietary "nvidia"
video driver, Nvidia provides indirect customer support via
an online web based support forum. Nvidia monitors these
web forums for commonly reported problems and passes them
on to Nvidia engineers for investigation. Once they've
isolated a particular problem, it is often fixed in a future
video driver update.
The NVNews Nvidia Linux driver forum is located at:
Once you have reported this issue in the Nvidia web forums,
others who may have experienced the particular problem may
be able to assist. If there is a real bug occuring, Nvidia
will be able to determine this, and will likely resolve the
issue in a future driver update for the operating system
releases that they officially support.
While Red Hat does not support the proprietary nvidia driver,
users requiring technical support may also find the various
X.Org, XFree86, and Red Hat mailing lists helpful in finding
X.Org mailing lists:
XFree86 mailing lists:
Red Hat mailing lists:
Setting status to "NOTABUG" (unsupported).
Here's a quick fix until NVidia fixes this...
1. Install the driver as usual
2. sudo cp -a /dev/nvidia* /etc/udev/devices
Assuming you've modified your xorg.conf file, you should be good to go.
I worked around the issue by adding "modprobe nvidia" to the end of
/etc/rc.d/rc.local X now starts without issue.
I also had another issue, "rhgb" fails to work after installing the
nvidia driver, (same 1.0-6629 version). OS boot soft-hangs where Red
Hat Graphical Boot should start. I had to remove "rhgb" from the
kernel command-line in menu.lst.
rhgb hangs because (as mentioned by the nvidia installer) the
framebuffer driver (which is used for graphical boot) conflicts with
the nvidia driver. This will likely continue until either nvidia
work around it (unlikely, having two drivers trying to do similar
things on the same piece of hardware is ugly) or redhat stops
defaulting rhgb (again, unlikely, as they're trying to appeal to new
users with this).
Haven't checked nvidia docs in awhile but, if they haven't, they
should add this to the list of post-install todo's for RH and FC users
(and probably others too).
Thanks for the /etc/udev/devices help, I was getting really annoyed
with reboots (crosses fingers until he tries again)
Comment #4 has some inaccuracies. rhgb has the capability to use
a different X server configuration including a different video
driver than the normal X configuration used by the system when
you're logged in, however by default it uses the same driver used
by the system, not the framebuffer.
The problem described in this report is due to Nvidia's driver
not cleanly handling or supporting "udev" properly, which is
unrelated to rhgb.
> things on the same piece of hardware is ugly) or redhat stops
> defaulting rhgb (again, unlikely, as they're trying to appeal to new
> users with this).
Actually, we are considering the possibility of replacing rhgb
with an alternative solution. The current idea (this is just an
idea, not something officially decided yet), is to remove rhgb
and just start gdm right away, which in theory will cut down
boot time significantly and prevent the need of starting 2 X
servers. This has the potential to be a better solution for
getting the desktop up and running as soon as possible after
the kernel boots, but with slightly less eye candy.
The potential removal of rhgb is likely to improve startup time,
and resolve a number of potential issues for users which may be
caused by rhgb, but the Nvidia/udev is really unrelated. There
are workarounds for the Nvidia issue mentioned in many bug reports
in bugzilla, as well as FAQ's etc. which can be used until Nvidia
enhances their driver to be more compatible with udev.
Hope this helps.