On Jun 29, 2014, at 1:55 PM, Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
>
Adam, I see in that bug your comment: "Discussed at 2013-11-13 blocker
review meeting -
http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-13/f20-fin...
. We agreed to amend the criterion to specify it covers the BIOS case only, and
consequently this bug is rejected as a blocker."
I think this should be reconsidered. I can't figure out how to get to
setup or a boot menu on my father's new laptop; if I were foolish enough
to install Fedora on it, we'd never get back to Windows again.
Since that bug and blocker review, I've become aware via Bootloaderspec and GRUB devel
list that UEFI firmware is floating around in the wild that doesn't respond to
keyboard input at boot time. This is for faster boots. So you can't get access to the
boot manager pre-boot. You have to boot an OS, run a user space application to tickle the
firmware into being activated on the next boot, reboot, and then you get the boot manager.
So if you don't have a bootable OS with such a user space application you can't
get to the firmware boot manager. Which means, installing Fedora on such a system makes
Windows unbootable if the GRUB menu doesn't have a working Windows boot entry.
It sounds like your father's laptop may have such firmware.
So yes I think it's fairly self-evident that this need to work on UEFI computers now
too, and should be a release blocking bug if it doesn't work. My vague understanding
is the broken Windows boot entries is fixed in upstream, but I don't know if Fedora
Rawhide's GRUB 2.02 has that fix and can't test it.
Chris Murphy