Bug 177955 - xorg.conf reverts to vesa after kernel upgrade
xorg.conf reverts to vesa after kernel upgrade
Product: Fedora
Classification: Fedora
Component: kudzu (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2006-01-16 14:44 EST by Dan Christian
Modified: 2014-03-16 22:57 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-24 18:47:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dan Christian 2006-01-16 14:44:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
I have a nvidia graphics card with the nvidia drivers installed.  Every time a new kernel comes out (from Redhat), I install it, then reboot single user and rebuild the nvidia driver.  I can then "init 5" and the system goes into it's normal graphical mode.

On the next boot, the system will do it's graphical boot using the nvidia driver.  However, it will revert the configurtion to a vesa driver before bringing up the login screen.  The solution is simple, login as root, mv xorg.conf.backup xorg.conf, and restart X.  There is nothing wrong with the driver or the configuration.

What's frustrating is that there is no message that the system reverted the graphics configuration or why.  One would assume that this is a failsafe for a bad configuration, but there should be some indication that corrective action was taken.

I don't even know if this is really an xorg bug.  I could not find what module was changing the configuration file (kudzu?).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Install nvidia drivers
2.Install new kernel, reboot to single user (or 3) and rebuild nvidia drivers

Actual Results:  On step 3, the system starts booting using the nvidia drivers, but reverts to a vesa driver before bring up the login screen.

Expected Results:  The system should have continued using the nvidia drivers.

Additional info:

This has been happening in FC4 ever since I installed it (many months ago).
Comment 1 Mike A. Harris 2006-01-20 15:10:49 EST
The xorg-x11 packaging does not control what driver gets assigned for a given
card, nor what happens on a kernel update.  I'm not exactly sure what causes
this change to happen, but I believe it is intentional.  I'm reassigning the
bug to the kudzu component as it is generally responsible for hardware detection,
however it might be gdm failsafing, or some other issue.

It is definitely not the X server doing this however.
Comment 2 Alan 2006-02-02 20:54:59 EST
This is definitly kudzu.  I've reproduced it by simply running kudzu from the
command line.  Every time it is run it changes the xorg.conf file and ignores it
when I change it back.  There should be a way to tell kudzu not to overwrite a
configured file, eh?
Comment 3 Mike A. Harris 2006-02-02 22:11:02 EST
kudzu reads the PCI ID from the video hardware, then looks it up in the
pcitable database.  If it doesn't find an entry for the card, it assumes
it is not supported, and the vesa driver is the driver that is used for
unsupported hardware in _all_ cases.

I don't know the kudzu code much, but I believe that it compares the
autodetected driver (in this case vesa) with the driver that the X server
is configured to use.  If it finds a difference, it assumes you have a
new video card plugged in, and offers to change it to use the new driver.

kudzu has no knowledge of Nvidia's driver, and the hardware database does
not ever map to the nvidia proprietary driver (and never will).

When the kernel is updated, if you don't rebuild nvidia's kernel driver
portion, you end up with nonworking video.  As such, to prevent that
problem, having the video driver changed to the one the OS defaults to
is done, to give the highest chance of having working video out of the
box, and after kernel updates.

The only solution to this, is to either disable kudzu because it is doing
this intentionally, or to stop it from detecting video hardware, and thus
leaving your driver assignment alone.

If we were to stop it from doing this, then we would end up getting hundreds
of bug reports from nvidia proprietary driver users, who upgrade their kernel
and end up with X no longer starting.

There is good news however.  Starting with Fedora Core 5, each driver
package contains it's own driver mapping files now, and there is no longer
a central database.  As such, all you have to do to avoid this problem, is
to use the livna.org Nvidia rpm packages with Fedora Core 5, and ensure that
the livna people have updated their nvidia packages to have an nvidia.xinf
file.  That should inform kudzu to use the "nvidia" driver for that hardware,
instead of the vesa driver.

However, that solution is only for FC5.  For FC4, there isn't a solution
other than described above.
Comment 4 Bill Nottingham 2006-02-02 22:16:35 EST
Reopening... the issue here is that it *shouldn't* be triggering if no hardware
has actually changed.
Comment 5 Mike A. Harris 2006-02-02 22:58:52 EST
Ah, I wasn't sure how it detected wether or not the hardware changed.  I
assumed it just compared the currently used driver to the one it currently
Comment 6 Dan Christian 2006-02-03 00:50:43 EST
Right.  The hardware didn't change, the right driver was already installed
(either manually or via a add-on yum repository), and yet kudzu is (silently)
changing the configuration.

The kicker is that the system has gotten half way through the graphical boot
working just fine, and then falls back to low res at the last minute.  It just
looks unprofessional for it to get it right and then second guess itself.  Is it
possible to notice that X is already running correctly (assuming graphical boot)?

If you are running a non-traditional display (say HDTV over component), then
falling back to VESA may mean you have no display at all.  Vesa isn't guarenteed
to be a safe configuration.  Besides, 640x480 display mode is often un-usable.

There is already a fall back method (to text mode) if X won't start.  This is
never any worse than reverting to VESA (for novel display configurations).

If nothing else, I REALLY wish there was a log messages somewhere telling me why
the configuration changed.  Having it "automagically" undo my configuration is
so... Windows :-)
Comment 7 Alan 2006-02-21 23:23:09 EST
what I would like to see is for there to be a way to run kudzu while limiting
the scope of its config changes.  sort of an "don't touch X" option in
/etc/sysconfig/kudzu or the like.  and yes, I wholeheartedly agree kudzu needs
to log when it does make changes to config files instead of just silently
messing up your working system.

btw, this problem seems to get fixed if you run system-config-display after
installing the nvidia drivers (even if you don't actually change any of the
config options).

as for the problems endemic to nvidia with kernel upgrades, that seems to me to
be a result of kernel-module rpm dependencies issues.  I know Axel Thimm is
working with the people from Smart to figure out how to make it so that when you
upgrade kernels you also get all of the modules with it.  breaking kudzu's
hardware-change detection to overcome a problem with rpms (or clueless users)
seems like adding a new problem, not solving the first.
Comment 8 Dan Christian 2006-02-22 21:57:07 EST
An added note on all this.

I recently upgraded the kernel and forgot to boot single user to install the
nvidia drivers.  kudzu failed to update the configuration.  I got the "X server
failed to start" text dialog.

So, not only is it changing the configuration when it shouldn't, it fails to
change it when it should.  Comment #3 was saying the the change was to prevent
this kind of problem, but it isn't actually working. FYI
Comment 9 Bill Nottingham 2006-08-24 18:47:00 EDT
I believe this is fixed in rawhide kudzu-1.2.45-1 or later.

Note You need to log in before you can comment on or make changes to this bug.