Created attachment 438168 [details] anaconda logs Description of problem: Installing F14 Alpha RC3 and following this test case: https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_Basic_Video_Driver Using KVM in virt-manager. When adding 'xdriver=vesa nomodeset' as kernel boot options and then booting anaconda, it seems that VESA driver was not selected, but CIRRUS was selected instead. See anaconda logs. After installation the 'xdriver=vesa' option is not passed to grub.conf, but 'modeset' is (that could be anaconda bug perhaps). The installed system runs again with CIRRUS driver. See system logs. Version-Release number of selected component (if applicable): xorg-x11-drivers-7.4-1.fc14.x86_64 xorg-x11-drv-cirrus-1.3.2-3.fc14.x86_64 xorg-x11-drv-vesa-2.3.0-1.fc14.x86_64 xorg-x11-server-common-1.8.99.905-2.20100716.fc14.x86_64 xorg-x11-server-utils-7.4-19.fc14.x86_64 xorg-x11-server-Xorg-1.8.99.905-2.20100716.fc14.x86_64 How reproducible: always Steps to Reproduce: 1. Follow the test case with F14 Alpha RC3 x86_64 DVD 2. 3.
Created attachment 438169 [details] system logs
Created attachment 438170 [details] rpm -qa
Anaconda should have created /etc/X11/xorg.conf. As your /var/log/Xorg.0.log does not mention the existence of xorg.conf, it probably was not created.
I know why this is the case in the live spins, I think: in the live spins, xdriver= parameter is meant to be handled by /etc/init.d/livesys-late , which is created in %post of the live build. It has this stanza: # configure X, allowing user to override xdriver if [ -n "\$xdriver" ]; then exists system-config-display --noui --reconfig --set-depth=24 \$xdriver fi however, system-config-display is set to Optional in comps and isn't listed in any spin .ks file, so I'm fairly sure it isn't actually present, and so obviously the command fails. There may be something similar going on in the non-live install. Quick fix would be to put s-c-d back in, but there should actually be a cleaner way now that /etc/X11/xorg.conf.d exists; we could just stick a Driver snippet in there. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Kamil, were you testing live install or traditional install? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
So, the test that produced this bug is listed as an Alpha-stage test on the matrix: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test (it's in Install Variations & General Tests). But there isn't actually an Alpha criterion which would apply here, AFAIK. There's an Alpha criterion "All dedicated installer images must boot to the graphical boot menu and allow the user to select install options. If no option is selected, the installer should load after a reasonable timeout", but it doesn't specify that all install options must *work*. This is another thing we ought to pin down in the criteria. For discussion, I believe these are the parameters of the issue: traditional install methods have a 'Basic Graphics Driver' option in the install menu, which should set vesa as the video driver to be used both during install and post-install. AIUI, this does work in RC3. I believe anaconda is also meant to honor the manual passing of xdriver=foo as a kernel parameter parameter when doing a traditional install. During a live boot / install, xdriver=foo should be honored both for the live boot and in the installed system, if an installation is done from that live boot. It's unclear from this report whether Kamil is reporting the live case or the traditional install case of passing xdriver= to be broken. I'll test both and see. We should establish which of these paths we expect to be working at which points, to add to the release criteria. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
okay, investigating this. Testing in a VM, if I pick the Basic Video Driver install option, I get the cirrus driver, which is incorrect. What I figure is that selecting that option just causes the kernel parameters 'xdriver=vesa nomodeset' to be added. xdriver=vesa is failing. However, this will be concealed for many chipsets because 'nomodeset' will force vesa to be used, since the native driver will refuse to work without KMS. cirrus being an old driver with no KMS, it doesn't have this problem, and it does get loaded, proving that xdriver=vesa itself doesn't work. so, it seems like anaconda simply fails to honor xdriver=vesa properly. For NVIDIA and Intel chipsets, this will be concealed by the use of 'nomodeset', and the vesa driver will still be used. For other chipsets, the native driver will still be used. This affects most notably ATI; 'nomodeset' will cause the radeon driver to load but use UMS support, which unlike nouveau and intel it still has. This will have unpredictable results. (This makes a lot more sense of a few ml reports and https://bugzilla.redhat.com/show_bug.cgi?id=596985 , by the by). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Potential fix: https://www.redhat.com/archives/anaconda-devel-list/2010-August/msg00167.html It looks to me like certain arguments are not getting passed from loader to stage2 due to that overzealous "else if" combined with the above "else if (v != NULL)" business from chunk 1. The result is that those arguments in chunk 2 never get added to extraArgs, therefore never passed to anaconda. dcantrell changed this most recently so he might have better insight here.
clumens' best guess as to which other parameters may be affected: vncpassword=, resolution=, vnc=, and syslog= -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
note that the location of this bug - in loader - means we can't ship an updates.img as a workaround. Our only choices are to document and release, or slip. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #5) > Kamil, were you testing live install or traditional install? > Maybe a little late, but I was doing traditional DVD install, as you probably know already :)
Note similar bug: https://bugzilla.redhat.com/show_bug.cgi?id=623561 xdriver= isn't honored in live boot either, but for different reasons. There's a patch for systemd there and I've sent a patch for spin-kickstarts to Kevin Fenzi which together should fix that. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
anaconda-14.16-1.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/anaconda-14.16-1.fc14
anaconda-14.15-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.