Bug 186338 - Upgraded fc5 fails to start x11 due to missing modules
Upgraded fc5 fails to start x11 due to missing modules
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
5
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Adam Jackson
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-22 19:06 EST by Otto J. Makela
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-24 17:51:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/Xorg.0.log after failed startup (1.77 KB, text/plain)
2006-03-22 19:06 EST, Otto J. Makela
no flags Details

  None (edit)
Description Otto J. Makela 2006-03-22 19:06:21 EST
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.
Comment 1 Otto J. Makela 2006-03-22 19:06:21 EST
Created attachment 126520 [details]
/var/log/Xorg.0.log after failed startup
Comment 2 Otto J. Makela 2006-03-23 07:06:06 EST
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.
Comment 3 Mike A. Harris 2006-03-24 20:27:13 EST
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.



Comment 4 Otto J. Makela 2006-04-04 18:19:02 EDT
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?
Comment 5 Matěj Cepl 2007-01-11 09:42:32 EST
ajax, could you confirm that this has been fixed in FC6?
Comment 6 Adam Jackson 2007-01-24 17:51:57 EST
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!
Comment 7 Lubomir Bulej 2007-02-03 08:48:54 EST
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?

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