On Thu, Jan 15, 2015 at 3:16 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > On Thu, Jan 15, 2015 at 5:13 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >> On Thu, Jan 15, 2015 at 2:55 PM, Elad Alfassa <elad@xxxxxxxxxxxxxxxxx> wrote: >> >>> So yes, secure boot not working should be a release blocker. >> >> Ok so a general purpose "Fedora should boot when UEFI Secure Boot is >> enabled" criterion needs to be created. Any suggestion on what release >> this should block? beta? final? alpha? > > At this point, probably Beta blocker. The sooner it's tested the better though. > >>> Windows failing to boot from grub with secure boot enabled is a different >>> story. If users can pick Windows in their firmware's boot device menu and it >>> boots and grub is simply failing to chainload it, then it's much less >>> critical of an issue, so I'm not sure if it should be a blocker, but it's >>> still a thing we probably want to work too, because it not working does hurt >>> the dual-boot user experience a bit. >> >> Some manufacturers are not enabling USB or the keyboard at firmware >> initialization time in order to get faster boots. So it's not >> guaranteed the user can get to the firmware's built-in boot manager. >> In such a case, the user would need to boot Fedora (since they have no >> choice), and then use efibootmgr to change the BootNext NVRAM variable >> (or they can change BootOrder). So that'd need some better >> documentation probably. > > Or a tool. Ideally, we'd just fix the bugs. Right. But I have no idea if it's a firmware bug, or a bug in the added secure boot code we're putting in GRUB. Typically in such cases I'd build upstream GRUB and see if the problem still happens, but AFAIK they have no Secure Boot support in GRUB. -- Chris Murphy -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
