Windows Dual Boot, with Secure Boot, release criteria
lists at colorremedies.com
Fri Jan 16 00:04:35 UTC 2015
On Thu, Jan 15, 2015 at 3:16 PM, Josh Boyer <jwboyer at fedoraproject.org> wrote:
> On Thu, Jan 15, 2015 at 5:13 PM, Chris Murphy <lists at colorremedies.com> wrote:
>> On Thu, Jan 15, 2015 at 2:55 PM, Elad Alfassa <elad at fedoraproject.org> 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.
More information about the desktop