Bug 807003 - Booting F17 Beta RC1 installer in basic video with radeon falls back to text mode
Booting F17 Beta RC1 installer in basic video with radeon falls back to text ...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-vesa (Show other bugs)
17
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
RejectedBlocker
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-26 14:13 EDT by Tim Flink
Modified: 2012-05-04 18:52 EDT (History)
4 users (show)

See Also:
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 18:52:35 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)
boot log with dracut and systemd debug enabled (53.91 KB, text/x-log)
2012-03-26 14:13 EDT, Tim Flink
no flags Details
X log from installed F17 Beta RC1 on same system (79.67 KB, text/plain)
2012-03-26 16:03 EDT, Tim Flink
no flags Details
boot log from installed F17 Beta RC1 system - nomodeset, vesa (56.26 KB, text/plain)
2012-03-26 16:06 EDT, Tim Flink
no flags Details

  None (edit)
Description Tim Flink 2012-03-26 14:13:37 EDT
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 14:15:02 EDT
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 15:03:22 EDT
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 16:03:21 EDT
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 16:06:53 EDT
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 16:15:39 EDT
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 16:36:10 EDT
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 18:38:33 EDT
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 18:51:25 EDT
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 03:04:09 EDT
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 16:18:08 EDT
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-28 20:15:43 EDT
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-29 22:58:39 EDT
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 14:03:18 EDT
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 18:52:35 EDT
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.