Bug 623129 - xdriver=vesa is not honored
Summary: xdriver=vesa is not honored
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Chris Lumens
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F14Alpha, F14AlphaBlocker
TreeView+ depends on / blocked
Reported: 2010-08-11 12:12 UTC by Kamil Páral
Modified: 2010-08-12 22:02 UTC (History)
5 users (show)

Fixed In Version: anaconda-14.15-2.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-08-12 22:02:29 UTC

Attachments (Terms of Use)
anaconda logs (400.00 KB, application/x-tar)
2010-08-11 12:12 UTC, Kamil Páral
no flags Details
system logs (830.00 KB, application/x-tar)
2010-08-11 12:13 UTC, Kamil Páral
no flags Details
rpm -qa (39.72 KB, text/plain)
2010-08-11 12:13 UTC, Kamil Páral
no flags Details

Description Kamil Páral 2010-08-11 12:12:40 UTC
Created attachment 438168 [details]
anaconda logs

Description of problem:
Installing F14 Alpha RC3 and following this test case:

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):

How reproducible:

Steps to Reproduce:
1. Follow the test case with F14 Alpha RC3 x86_64 DVD

Comment 1 Kamil Páral 2010-08-11 12:13:18 UTC
Created attachment 438169 [details]
system logs

Comment 2 Kamil Páral 2010-08-11 12:13:34 UTC
Created attachment 438170 [details]
rpm -qa

Comment 3 Michal Schmidt 2010-08-11 12:56:53 UTC
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.

Comment 4 Adam Williamson 2010-08-11 16:08:54 UTC
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

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

Comment 5 Adam Williamson 2010-08-11 16:13:37 UTC
Kamil, were you testing live install or traditional install?

Fedora Bugzappers volunteer triage team

Comment 6 Adam Williamson 2010-08-11 20:03:12 UTC
So, the test that produced this bug is listed as an Alpha-stage test on the matrix:


(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

Comment 7 Adam Williamson 2010-08-11 20:32:09 UTC
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

Comment 8 Adam Williamson 2010-08-11 20:32:22 UTC
Fedora Bugzappers volunteer triage team

Fedora Bugzappers volunteer triage team

Comment 9 Chris Lumens 2010-08-11 21:06:04 UTC
Potential fix:


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.

Comment 10 Adam Williamson 2010-08-11 21:20:53 UTC
clumens' best guess as to which other parameters may be affected:

vncpassword=, resolution=, vnc=, and syslog=

Fedora Bugzappers volunteer triage team

Comment 11 Adam Williamson 2010-08-11 21:21:29 UTC
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

Comment 12 Kamil Páral 2010-08-12 07:19:54 UTC
(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 :)

Comment 13 Adam Williamson 2010-08-12 14:16:50 UTC
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

Comment 14 Fedora Update System 2010-08-12 18:38:23 UTC
anaconda-14.16-1.fc14 has been submitted as an update for Fedora 14.

Comment 15 Fedora Update System 2010-08-12 22:02:16 UTC
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.

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