Multibooting UX, how well it ought to work

[Chris Murphy]

On Jun 27, 2014, at 10:52 AM, Michael Catanzaro <mcatanzaro at gnome.org> wrote:

> My personal opinions:
> 
> On Thu, 2014-06-26 at 18:51 -0600, Chris Murphy wrote:
>> 1a. Does preserve preexisting include providing a working menu entry
>> in the boot manager (e.g. in the GRUB menu)? 
> 
> Yes.
> 
>> 1b. Or is it sufficient to just preserve the installation data —
>> meaning it's permissible for its bootability to be either non-obvious
>> or broken?
> 
> No. Users will not be able to recover from this scenario.
> 
>> 2. If the answer to 1a. is yes, and 1b. is no, does this dual-boot
>> requirement apply to both BIOS and UEFI?
> 
> Yes.
> 
>> 3. If resources cannot meet the dual-boot requirement by ship time,
>> should the installer inform the user that their previous installation
>> will be preserved but may not be bootable?
> 
> I think that would be OK, if the warning is clear and you have to click
> a red button to bypass it.
> 
> Can you link to the discussion on why the above requirements are
> problematic?

This is it. I'm uncertain how they can be requirements without a mandate from the Workstation WG or FESCo. The bugs aren't new [1], they vary from 1-3 years old, and none made it to either freeze exception or release blocker status expressly because there's no applicable release criteria. Hence request to clarify the scope of the tech spec "preserve existing" language.


>> 4. Why is the preservation of an existing Linux OS, including a
>> previous Fedora, not explicit in the spec? Should it be?
> 
> This would be nice to have. When I tried dual-booting a year or so ago,
> the status quo was that os-prober usually worked, but not really
> reliably.

I don't have a short explanation for this, but a lot of the problems here are bugs I summarize below.  But in addition, right now grub-mkconfig creates generic boot entries from scratch for other Linux OS's that get found. Therefore two problems arise with those boot entries: the distro/user specified boot parameters aren't used, and any kernel updates in those other Linux OS's aren't reflected in the GRUB menu. GRUB has tools to do better, it's just that they aren't being used by upstream's own 30_os-prober script. If instead it used configfile to point to the distro specific grub.cfg/conf, neither problem described would happen. So someone build a ship yard, but no one's building ships. It's kinda weird.


> If we adopt the bootloader spec, then it we should add a guarantee that
> we preserve the ability to boot other Linux systems that adhere to that
> spec (which is admittedly none). But there was significant debate over
> whether Fedora should adopt that spec.

Well we sorta have with respect to the implied configuration file format. Fedora Atomic/OSTree, and the blscfg.mod patch for GRUB (since GRUB upstream rejects bootloaderspec as written) both use the bls conf file format. The problem is the way we're implementing it departs from the spec in some fundamental ways, in part because the spec is so limiting (e.g. $BOOT is required to be FAT16/32) so it's instantly lost interoperability.

Chris Murphy




[1] Summary of Fedora bootloading bugs:

BIOS, preexisting Windows: reliably has a working boot entry created. For other combinations all bets are off:

BIOS or UEFI, preexisting Linux using LVM: boot entries not created because preexisting OS's LV's aren't activated by the installer, so os-prober/grub2-mkconfig don't find the preexisting OS.  Two year old bug, finger pointing, no agreement on who should fix it.
https://bugzilla.redhat.com/show_bug.cgi?id=825236

UEFI, preexisting Windows:, boot entry either not created for Windows or it doesn't work. 
https://bugzilla.redhat.com/show_bug.cgi?id=986731  ## Year old bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1010704  ## This bug was rejected as an F20 blocker on the basis that the release criteria for Windows only applies to BIOS.

UEFI, preexisting Linux no-LVM: boot entry does not work. This is a Fedora GRUB specific bug, over a year old, was rejected for freeze exception so it stands to reason it would have been rejected as a blocker as well.
https://bugzilla.redhat.com/show_bug.cgi?id=964828

UEFI, preexisting OS X: boot entries don't work, have never worked for me in 3+ years. Two 18 month old bugs.
https://bugzilla.redhat.com/show_bug.cgi?id=904668  ## Kernel panic might now be fixed by upstream, but upstream's solution is flaky and prone to breakage every time Apple makes a kernel change. Upstream insists on using their own bootloader rather than Apple's for unknown reasons.
https://bugzilla.redhat.com/show_bug.cgi?id=893179 ## Described fix by adding GRUB xnu modules to grubx64.efi has not been implemented. Secondary problem is that there are two superfluous entries that don't work due to confusion resulting from Fedora's mactel-boot support (os-prober thinks the Fedora boot entries are an OS X installation).