Red Hat Bugzilla – Bug 484859
xorg.conf is modified during each system upgrade
Last modified: 2009-05-08 14:41:36 EDT
Description of problem: I've noticed that each upgrade of Fedora xorg-x11-server-Xorg modifies my xorg.conf file - not making any backups... This is dangerous as the file might be damaged during some poweroff sequence. Also I'd like to be able to specify, that I do not wish to make any unconfirmed changes to this file. (i.e. some commented keyword that would exit this script before doing any modifications) rpm -q --scripts xorg-x11-server-Xorg-1.5.99.902-5.fc11.x86_64 preinstall scriptlet (using /bin/sh): { pushd /etc/X11 [ -e xorg.conf ] || return 0 sed -i 's/^.*Load.*"(pex5|xie|xtt).*\n$"//gi' xorg.conf sed -i 's/^\s*Driver(.*)"keyboard"/Driver\1"kbd"/gi' xorg.conf sed -i 's/^.*Option.*"XkbRules".*"(xfree86|xorg)".*\n$//gi' xorg.conf sed -i 's#^\s*RgbPath.*$##gi' xorg.conf # lame, the nvidia driver needs to override this if ! grep -q 'ModulePath.*nvidia' xorg.conf ; then sed -i 's#^\s*ModulePath.*$##gi' xorg.conf fi popd } &> /dev/null || : Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.5.99.902-5.fc11.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Keeping my ModulePath settings across xorg upgrades. Additional info:
If you lose power during a package upgrade you're already boned. I mean, we're replacing the _binary_. The config file is the least of your worries. What are you modifying ModulePath for?
I've started to use ModulePath for my git-compiled libdrm libs and intel driver to be able to use UXA acceleration - as the current packages in Fedora are crashing my box mainly in suspend/resume or console switching. IMHO touching such configure file without giving the user some option to avoid it and without providing backup file is not a good idea.
I have the exact same problem. I'm not trying to use any advanced features of the driver, but the current Intel driver supplied by Fedora 10 causes X to lockup right after the X server starts. I had to compile a newer version from git and put that into /usr/local/lib/xorg/modules. Then I had to add an entry to my ModulePath in xorg.conf. When I upgrade xorg-x11-server-Xorg, the ModulePath line is completely removed, apparently as a hack for the nvidia driver. That means that when I reboot after an update, my X server is going to lock (this is my only notification that something went wrong), I have to use magic sysrq hotkeys to reboot. Then I have to modify the grub boot to add a "3" to the end of the kernel command line so I can repair xorg.conf before starting the X server. Now that I understand what's happening and why, I can do this pretty quickly, but there has to be a better test for nvidia use than the one currently in there: # lame, the nvidia driver needs to override this if ! grep -q 'ModulePath.*nvidia' xorg.conf ; then sed -i 's#^\s*ModulePath.*$##gi' xorg.conf fi For reference, my line looks like: ModulePath "/usr/local/lib/xorg/modules,/usr/lib/xorg/modules" So, the RPM wipes out the ModulePath line if the text "nvidia" does not appear in it. It doesn't appear in mine, but I also don't need any hacks for nvidia, so the logic is clearly wrong. I assume this is for the proprietary nvidia driver, so we're doing this because one cannot tell in advance if a user wants to install that driver, and installation will fail if a ModulePath already exists? I hate to see a workaround for proprietary drivers break things for users that are sticking to free software. I would be willing to deal with creating a file named /etc/X11/i-hate-nvidia so that the preinstall scriptlet could do this: # lame, the nvidia driver needs to override this if ! -e /etc/X11/i-hate-nvidia ; then if ! grep -q 'ModulePath.*nvidia' xorg.conf ; then sed -i 's#^\s*ModulePath.*$##gi' xorg.conf fi fi
Fixed in 1.6.0-16 and later