Multibooting UX, how well it ought to work

[Chris Murphy]

On Jun 29, 2014, at 1:55 PM, Michael Catanzaro <mcatanzaro at 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-final-blocker-review-1.2013-11-13-17.01.log.txt . 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