Bug 807003

Summary: Booting F17 Beta RC1 installer in basic video with radeon falls back to text mode
Product: [Fedora] Fedora Reporter: Tim Flink <tflink>
Component: xorg-x11-drv-vesaAssignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 17CC: awilliam, robatino, satellitgo, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: RejectedBlocker
Fixed In Version: xorg-x11-drv-ati-6.14.4-5.20120417git0bda305f7.fc17 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-04 22:52:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
boot log with dracut and systemd debug enabled
none
X log from installed F17 Beta RC1 on same system
none
boot log from installed F17 Beta RC1 system - nomodeset, vesa none

Description Tim Flink 2012-03-26 18:13:37 UTC
Created attachment 572828 [details]
boot log with dracut and systemd debug enabled

Booting the F17 Beta RC1 x86_64 DVD (dd'd iso to USB) and select "Install in basic graphics mode", the installer does boot up but I end up in text mode instead of graphical mode.

kernel command line:
initrd=initrd.img root=live:CDLABEL=Fedora\x2017-Beta\x20x86_64 xdriver=vesa nomodeset rd.luks=0 rd.md=0 rd.dm=0 console=tty0 console=ttyS0,38400n8 rd.debug systemd.log_level=debug systemd.log_target=kmsg BOOT_IMAGE=vmlinuz

Comment 1 Tim Flink 2012-03-26 18:15:02 UTC
Proposing as a blocker for F17 beta due to violation of the following F17 alpha release criterion [1]:

The boot menu for all installation images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer and attempting to use the generic driver.

[1] http://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria

Comment 2 Adam Williamson 2012-03-26 19:03:22 UTC
The mechanism is not entirely broken, as it works in a KVM. Can you try running X with the vesa driver on an installed F17 on the system in question, and see if that actually works? And attach X logs?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 3 Tim Flink 2012-03-26 20:03:21 UTC
Created attachment 572864 [details]
X log from installed F17 Beta RC1 on same system

(In reply to comment #2)
> The mechanism is not entirely broken, as it works in a KVM. Can you try running
> X with the vesa driver on an installed F17 on the system in question, and see
> if that actually works? And attach X logs?

Define works. It does boot into graphical mode, yes. However, the radeon driver is loaded - not vesa

Comment 4 Tim Flink 2012-03-26 20:06:53 UTC
Created attachment 572866 [details]
boot log from installed F17 Beta RC1 system - nomodeset, vesa

Attached boot log from the same installed system - used nomodeset and xdriver=vesa as boot parameters; the same ones used for basic graphics boot on the install DVD.

Comment 5 Tim Flink 2012-03-26 20:15:39 UTC
This is going to be at least somewhat HW specific - I am unable to reproduce the issue with the i386 DVD on an old P4 with nvidia graphics (geforce 7200).

I have another radeon card that I can try - will attempt to reproduce with that.

Comment 6 Tim Flink 2012-03-26 20:36:10 UTC
I tried again with a newer radeon and was unable to reproduce. If this only happens with older radeons or this specific card (x1800), I'm -1 blocker on this.

Comment 7 Adam Williamson 2012-03-26 22:38:33 UTC
tim: well, I asked you to specifically force loading of X with VESA driver on the same hardware outside an anaconda context. I'm trying to probe if this is just a problem with using the vesa driver on this particular card.

Given your other tests, it does smell pretty non-blocker.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 8 Tim Flink 2012-03-26 22:51:25 UTC
adamw: and I did that - logs are in c#3 and c#4(In reply to comment #7)
> tim: well, I asked you to specifically force loading of X with VESA driver on
> the same hardware outside an anaconda context. I'm trying to probe if this is
> just a problem with using the vesa driver on this particular card.

I already did that. logs are in c#3 and c#4.

I used the boot params 'nomodeset xdriver=vesa' but the radeon driver was still loaded. If I'm missing something here, let me know though.

Comment 9 Adam Williamson 2012-03-27 07:04:09 UTC
xdriver= only takes any effect for anaconda. you have to use an xorg.conf file or snippet in /etc/X11/xorg.conf.d to force the use of the vesa driver in the case where the native driver still has UMS code (you seem to have the one generation of Radeon which still has UMS support...)



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 10 Fedora Update System 2012-03-28 20:18:08 UTC
xorg-x11-drv-ati-6.14.3-12.20120206git36c190671.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/xorg-x11-drv-ati-6.14.3-12.20120206git36c190671.fc17

Comment 11 Adam Williamson 2012-03-29 00:15:43 UTC
Discussed at 2012-03-28 go/no-go meeting, acting as a blocker review meeting. Agreed this does not constitute a blocker: the criterion is more about ensuring the 'basic graphics' mechanism exists and works as intended (triggers boot with the vesa driver enabled). Cases where all this happens, but the vesa driver fails to work properly on some specific piece of hardware, aren't really violating the criterion, especially when that hardware doesn't actually need vesa (works fine with the native driver).



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 12 Fedora Update System 2012-03-30 02:58:39 UTC
Package xorg-x11-drv-ati-6.14.3-12.20120206git36c190671.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-ati-6.14.3-12.20120206git36c190671.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-4873/xorg-x11-drv-ati-6.14.3-12.20120206git36c190671.fc17
then log in and leave karma (feedback).

Comment 13 Fedora Update System 2012-04-17 18:03:18 UTC
xorg-x11-drv-ati-6.14.4-5.20120417git0bda305f7.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/xorg-x11-drv-ati-6.14.4-5.20120417git0bda305f7.fc17

Comment 14 Fedora Update System 2012-05-04 22:52:35 UTC
xorg-x11-drv-ati-6.14.4-5.20120417git0bda305f7.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.