Bug 623129 - xdriver=vesa is not honored
xdriver=vesa is not honored
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
13
All Linux
low Severity high
: ---
: ---
Assigned To: Chris Lumens
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F14Alpha/F14AlphaBlocker
  Show dependency treegraph
 
Reported: 2010-08-11 08:12 EDT by Kamil Páral
Modified: 2010-08-12 18:02 EDT (History)
5 users (show)

See Also:
Fixed In Version: anaconda-14.15-2.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-12 18:02:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Kamil Páral 2010-08-11 08:12:40 EDT
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.
Comment 1 Kamil Páral 2010-08-11 08:13:18 EDT
Created attachment 438169 [details]
system logs
Comment 2 Kamil Páral 2010-08-11 08:13:34 EDT
Created attachment 438170 [details]
rpm -qa
Comment 3 Michal Schmidt 2010-08-11 08:56:53 EDT
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 12:08:54 EDT
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
Comment 5 Adam Williamson 2010-08-11 12:13:37 EDT
Kamil, were you testing live install or traditional install?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 Adam Williamson 2010-08-11 16:03:12 EDT
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
Comment 7 Adam Williamson 2010-08-11 16:32:09 EDT
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
Comment 8 Adam Williamson 2010-08-11 16:32:22 EDT
-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 9 Chris Lumens 2010-08-11 17:06:04 EDT
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.
Comment 10 Adam Williamson 2010-08-11 17:20:53 EDT
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
Comment 11 Adam Williamson 2010-08-11 17:21:29 EDT
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
Comment 12 Kamil Páral 2010-08-12 03:19:54 EDT
(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 10:16:50 EDT
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
Comment 14 Fedora Update System 2010-08-12 14:38:23 EDT
anaconda-14.16-1.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/anaconda-14.16-1.fc14
Comment 15 Fedora Update System 2010-08-12 18:02:16 EDT
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.