Windows Dual Boot, with Secure Boot, release criteria

[Chris Murphy]

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