Bug 186338
| Summary: | Upgraded fc5 fails to start x11 due to missing modules | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Otto J. Makela <om> | ||||
| Component: | xorg-x11 | Assignee: | Adam Jackson <ajax> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 5 | CC: | mcepl | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2007-01-24 22:51:57 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Otto J. Makela
2006-03-23 00:06:21 UTC
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?
|