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