Bugzilla – Bug 140916
System update to 10.1 Alpha 3 or 4 renders xorg.conf unusable
Last modified: 2008-06-25 09:53:12 UTC
This is a problem that I had when I upgraded my Dell Dimension (with Dell monitor and Matrox 450) from Suse 10.0 to Suse 10.1 Alpha 3. At the time I did not have enough info to enter a bug, anyway I fixed xorg.conf (with the help of a Knoppix CD, sorry) and I got the screen working again, making sure to have a backup copy of xorg.conf. Last night I set my installation sources to the 5 cd iso images of alpha4 (by mounting them with -loop and -iso9660), then did a system update When I rebooted I was in text mode, and attempting startx resulted in an error message "no screen available" I'm going to attach the working xorg.conf, the one I had after the update to alpha4, and the xorg.log that details the error. I will be away for about a week, so apologies in advance if you require more info and I'll be slow getting back to you. Congratulations for a great alpha4, btw
Created attachment 61743 [details] Log file when trying to starx with the xorg.conf I got from system update to alpha4
Created attachment 61744 [details] xorg.conf I got after system update to alpha4
Created attachment 61745 [details] xorg.conf that works properly for Dell Dimension with Matrox 450
Marcus, could you look at this bug? I'm not sure whether it's for you...
This is not a bug: 1) You made an upgrade to Alpha3 which has a broken X workflow in YaST2 leading to no X configuration except the standard fbdev config used for the installation process 2) you made an update from Alpha3 to Alpha4. While updating no X configuration is done because it's an update. The file /etc/X11/xorg.conf won't be touched in an update case I don't know why you need a knoppix CD to fix your X configuration there is a tool for SuSE to do the job very easy. Simply call sax2 :) The problem you are running into is doing an update from one alpha to another Never do that ! alpha dists are always broken, if you update from something broken to something broken what do you expect ?? I'm sorry but if you don't mind to a fresh install to the current version not an update and have a look at the created X configuration. Thanks
Apologies if my steps were not clear 1) I used knoppix only to fix the problem in 10.0 -> 10.1 Alpha3 migration. The reason was that using sax2 from the command line did not work for me If you want to see some reports of people having troubles with sax2, try to do a search for "sax2" on http://forums.suselinuxsupport.de 2) My experience is that /etc/X11/xorg.conf is definitely touched in an update case. I had a problem with a system update from 9.3 to 10.0, I had problems in system update from 10.0 to 10.1 Alpha3, and eventually in the system update from 10.1 Alpha3 to Alpha4. I agree with you that I should not have done an Alpha3 -> Alpha4 system update, however I logged the bug because I wanted to prevent the general problem of the system update modifying xorg.conf. Try with a recent build, and I bet you'll see that the file is modified. Btw, thanks for a great 10.1 alpha. Other that this problem, I love it.
I can understand your point but the problem you have results in an xorg.conf file which wasn't created by sax2 because of the update workflow. If you have a look at the file you attached in comment #2 the first line contains: # generic XFree86 4.x configuration file ... and the rest of the file is exactly the same thing the installer uses for a standard fbdev based graphical installation procedure. This is a static file only for the purpose of installing the system in graphics mode. Now at the end of the installation this file is copied to the installed system and renamed to /etc/X11/xorg.conf.install your existing xorg.conf is not touched. If you want to verify that have a look at: /usr/share/YaST2/clients/x11_finish.ycp // create backup copy from from inst-sys config to be available in installed // or updated system copy /etc/X11/XF86Config from inst-sys to // [/mnt]/etc/X11/xorg.conf.install // --- y2milestone ("Include X11 config [instsys] to installed system: xorg.conf.install"); string filename = "/etc/X11/xorg.conf"; WFM::Execute (.local.bash, "/bin/cp " + filename + " " + Installation::destdir + "/etc/X11/xorg.conf" + ".install" ); } If you are absolutely sure that your existing xorg.conf has been touched after the update is finished we can say that there is a bug in the update workflow but I cannot imagine how this could happen All in all at that point sax2 even wasn't called :-) I reopen the bug for now, if you don't mind do an installation of 10.0 and update to 10.1 Alpha4 ... let's see what happened
set status to remind
Sorry it took me ages to get back to you on this, I only have 2 systems home and I can't reinstall very often. This is what I found out on the other PC a) upgrade from 10.0 to 10.1 Beta 3 As per your explanation, xorg.conf was left untouched At this stage, I was using the "radeon" driver Then, to use the scart output better, I installed the "fglrx" proprietary driver and modified xorg.conf accordingly Then b) upgrade from 10.1 Beta3 to 10.1 Beta 6 xorg.conf was modified, no idea why but for some reason the installation program decided to put driver="radeon" back in xorg.conf I had a backup copy of the file, so I was ok If you want, I can attach the files
mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)
Closing old LATER+REMIND bugs as WONTFIX - if you still plan to work on it, feel free to reopen and set to ASSIGNED. In case the report saw repeated reopen comments, it's due to bugzilla timing out on the huge request ;(