Red Hat Bugzilla – Bug 186338
Upgraded fc5 fails to start x11 due to missing modules
Last modified: 2018-04-11 06:26:14 EDT
Description of problem:
System upgraded from fc4 to fc5 (via booted Bordeaux DVD) fails to start x11 due
to missing modules "bitmap" and "pcidata".
Steps to Reproduce (guesswork):
1. Install fc4 on x86_64 system with NVIDIA GeForce 6200
2. Upgrade to fc5 using "update" from DVD boot
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)
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
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
(**) 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:
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?