Description of problem: System upgraded from fc4 to fc5 (via booted Bordeaux DVD) fails to start x11 due to missing modules "bitmap" and "pcidata". How reproducible: Unknown. Steps to Reproduce (guesswork): 1. Install fc4 on x86_64 system with NVIDIA GeForce 6200 2. Upgrade to fc5 using "update" from DVD boot Actual results: Startup of x11 fails with errors: (EE) Failed to load module "bitmap" (module does not exist, 0) (EE) Failed to load module "pcidata" (module does not exist, 0) Expected results: Normal x11 startup.
Created attachment 126520 [details] /var/log/Xorg.0.log after failed startup
After some research and thinking about it, I was able to get X11 running by doing: # cd /usr/X11R6/lib64 # rm -r modules # ln -s ../../lib64/xorg/modules . It seems the installation set has some confusion about where the lib64 module library should be, as the directory /usr/X11R6/lib64/modules I above "rm" is empty except for three empty subdirectories and /usr/lib64/xorg/modules is clearly intended to be here, having the same populated subdirectories. Another alternative might be to have X11 look for the modules in the right place, but this seems to work good enough until an official patch comes up.
The bitmap and pcidata modules are supplied in the X server packaging in the correct location in all architectures that the X server is shipped on. Additionally, the X server looks in the correct location for the modules on all architectures. These modules are mandatory for the X server to start, and if they did not exist, or were installed in the wrong place, then X would not start for any users at all. The only way this problem can happen is if you are overriding the built in default ModulePath with an incorrect hard coded path in xorg.conf, in which case it is a local config error. A quick review of your log file confirms this: (**) ModulePath set to "/usr/X11R6/lib64/modules" Rerun "system-config-display --reconfig" and a new xorg.conf should be generated which is correct for FC5, however any customizations you've made to the X config in the past will be lost.
Except I haven't edited ModulePath in xorg.conf by hand, somehow either the new installation or the upgrade process from fc4->fc5 messed this value up. I believe bug #186710 may also be an instance of this occurring, it would be a pretty good coincidence for him to end up with this same value in ModulePath just due to a flaky DVD drive, eh?
ajax, could you confirm that this has been fixed in FC6?
There was an attempt at fixing this in the FC6 %post for the X server, but it wasn't particularly good. Really the correct solution is to just nuke the ModulePath statement no matter what. Fixed in rawhide, thanks!
I'm not sure if it really is the right solution. In my case, this actually broke my configuration, where I'm using the ModulePath statement in the following way: ModulePath "/usr/lib/xorg/modules/extensions/nvidia" ModulePath "/usr/lib/xorg/modules" This allows me to load nvidia glx stuff without having to delete xorg stuff. The "nuke the ModulePath" approach actually broke my setup. If this has to remain, is there any other way to add a prefered module directory in front of the built-in module path?