Multibooting UX, how well it ought to work

[Chris Murphy]

On Aug 16, 2014, at 6:36 AM, Michael Catanzaro <mcatanzaro at gnome.org> wrote:

> On Sun, 2014-06-29 at 11:15 -0600, Chris Murphy wrote:
>> [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).
> 
> Hi,
> 
> Am I alone in thinking we should block final on all of these? We're
> delayed so much already that it seems like it might be best to take care
> of these once and for all. Especially if we are going to pretend that
> Fedora is a good alternative to Mac; we should not pretend that if we
> cannot boot on Macs.

Fedora post-install behavior on Macs:
- GRUB menu appears by default
- Fedora boot entries work
- OS X boot entries don't work   ## The two bugs above relate to this.

I don't know the % of Mac users who know about the option-key @ boot chime trick to get the firmware's boot manager to appear, but that's the work around to boot OS X. If the user doesn't know this, it's a problem, but the fix is literally "push this button". Whereas the other bugs above require esoteric knowledge to fix. And actually, there are bigger Mac problems than this: wireless, bluetooth, trackpad, and overheating/MCE problems are much worse, maybe deal killers. (At least I can't use Fedora, or any linux, full time right now. It's just way too frustrating, and may even be cooking themselves. [1])


> A nonfunctional installer is a really big problem. At the worst, the
> installer should be able to detect these situations in advance and warn
> the user.

I think the other bugs in the list need priority, resources being limited and all. We should commonbugs the Mac bugs, which have the same push this button solution.


Chris Murphy



[1]
https://bugzilla.redhat.com/show_bug.cgi?id=924570