Bug 807003 - Booting F17 Beta RC1 installer in basic video with radeon falls back to text mode
Summary: Booting F17 Beta RC1 installer in basic video with radeon falls back to text ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-vesa
Version: 17
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-26 18:13 UTC by Tim Flink
Modified: 2012-05-04 22:52 UTC (History)
4 users (show)

Fixed In Version: xorg-x11-drv-ati-6.14.4-5.20120417git0bda305f7.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-04 22:52:35 UTC
Type: ---


Attachments (Terms of Use)
boot log with dracut and systemd debug enabled (53.91 KB, text/x-log)
2012-03-26 18:13 UTC, Tim Flink
no flags Details
X log from installed F17 Beta RC1 on same system (79.67 KB, text/plain)
2012-03-26 20:03 UTC, Tim Flink
no flags Details
boot log from installed F17 Beta RC1 system - nomodeset, vesa (56.26 KB, text/plain)
2012-03-26 20:06 UTC, Tim Flink
no flags Details

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.


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