Bug 977816
Summary: | Safe graphics mode missing for Live UEFI | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> |
Component: | LiveCD | Assignee: | Matthias Clasen <mclasen> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 19 | CC: | awilliam, bugzilla, collura, drago01, joe, jreznik, kevin, mjg59, robatino |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | RejectedBlocker | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-01-09 21:36:33 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Kamil Páral
2013-06-25 11:50:32 UTC
Seems to be a blocker: The boot menu for all supported installer and live 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 or desktop and attempting to use the generic driver. https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria#Expected_image_boot_behavior Note: A memtest option is also missing, because there is not Troubleshooting menu at all. It's not regression as this is not supported for many releases - bcl points to ceb81892 (Jeremy Katz 2008-06-05 21:04:40 -0400) in livemedia-creator. I tried it with F18, F17 and I can confirm that, -1 blocker. Yeah, -1 blocker, that criterion was written with reference to the BIOS images. I've been meaning to look into making the UEFI boot menus better for *years* now. Is there actually a way to boot in basic video in efi mode then? -1 blocker, but it would be nice to clarify this in docs. -1 this has always been like that afaik. Kevin: Probably not, but then, we probably couldn't actually do it just by adding a boot menu option either. So on BIOS mode, 'basic video mode' just adds two kernel parameters: 'nomodeset xdriver=vesa'. The second is a complete no-op and has been for several releases: https://bugzilla.redhat.com/show_bug.cgi?id=858270 fortuitously, though, since the modern X drivers for the major cards - nouveau, radeon, intel - all require KMS, simply passing 'nomodeset' has the effect we want: you wind up getting vesa as the fallback driver, because the main driver refuses to load without KMS. You can trivially reproduce the bit that actually works - passing 'nomodeset' for UEFI, of course. Just edit the kernel parameters and add 'nomodeset'. I have no idea if this actually results in anything like what you actually want to happen, though. Probably not. Ajax explains what we probably ought to do here in https://bugzilla.redhat.com/show_bug.cgi?id=858270#c2 : we need to add a feature to X which is basically 'please explicitly load the appropriate failsafe fallback configuration for my video hardware'. We really ought to get that done. But it's not an F19 blocker. -3 votes here, setting RejectedBlocker. Please note that I have tested safe graphics mode on DVD/netinst in UEFI mode and it worked as expected - it ran in low-res and looked very ugly, just as with BIOS mode :) Kamil: I'm not at all sure we can rely on that for all hardware, though; I don't know _all_ the details but I think it may well be the case that some UEFI firmwares just won't handle 'nomodeset' well at all. -1 AFAIK memtest doesnt work in UEFI mode At least with 19 final FC1 on a Mac booted EFI which has GOP (per the UEFI spec), nomodeset causes X to not start. It seems GOP support is needed rather than VESA, for a fallback basic video mode, I'm not seeing anything in the UEFI spec about VESA. [ 11.914] (II) [KMS] drm report modesetting isn't supported. [ 11.914] (WW) Falling back to old probe method for modesetting [ 11.914] (EE) open /dev/dri/card0: No such file or directory [ 11.914] (WW) Falling back to old probe method for fbdev [ 11.931] (EE) Screen 0 deleted because of no matching config section. [ 11.936] (EE) VESA(0): V_BIOS address 0x0 out of range [ 11.937] (EE) Screen(s) found, but none have a usable configuration. With F18 kernel 3.6.10, nomodeset works on the same EFI GOP hardware. Sorta. I get graphics but they're totally garbled. F19 fails with this message: [ 11.936] (EE) VESA(0): V_BIOS address 0x0 out of range Whereas the VESA driver on F18 finds what it's looking for vbios wise, but it just gets the resolution and refresh wrong so things don't display correctly. This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. So in F21 the 'basic graphics mode' option does *exist* for UEFI live, but it does the same as for BIOS, it just adds 'nomodeset'. I can never remember - mjg59, is this correct, or should it do something else? nomodeset is all we can do from the kernel side. As long as X then falls back to a generic driver, we're good. ok, well it's certainly resolved as reported then. thanks matthew! |