The gist is that on some systems, when Secure Boot is enabled, the Window entry in the GRUB menu fails to boot Windows. If Secure Boot is disabled, this GRUB entry works. This was proposed for Fedora 21 as a blocker but was rejected because we don't have an explicit criterion for it. The final release criterion reads "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora." It doesn't grant an exception for Secure Boot, but it also doesn't say it needs to work if Secure Boot is enabled. In fact, we don't have a Secure Boot criterion at all anywhere, even in a non-dual-boot context, so it stands to reason if we wouldn't block on Secure Boot not working for Fedora, we can't really block on it not working when booting Windows via GRUB. Right now there are three bugs, three different kinds of hardware: Samsung, Lenovo, Dell, all laptops. These bugs will be consolidated into one (in-progress) https://bugzilla.redhat.com/show_bug.cgi?id=1144657 https://bugzilla.redhat.com/show_bug.cgi?id=1170245 https://bugzilla.redhat.com/show_bug.cgi?id=1180787 I don't know if the problem is a GRUB, shim, or UEFI firmware bug. If it's a firmware bug, something of an autopsy report that firmware OEMs could be made aware of might be useful, I just don't see how else they'd even learn about this if bugs are filed with them that clearly explain the problem. And if it's not a firmware bug, should we be blocking on this until it's fixed? And should there be an explicit Secure Boot criterion? That second question might be of interest to the Server product also. -- Chris Murphy -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
