On 09/09/2014 11:51 AM, Chris Murphy wrote:
QA wants a release criterion for dual boot OS X + Fedora installations. I floated this one on test@, and it's passed initial acceptance by Adam Williamson and Michael Catanzaro.
{
The installer must be able to install into free space alongside an existing OS X installation, install and configure a bootloader that will boot Fedora; if the boot menu presents an OS X entry, it should boot OS X.
}
The gist is that if there are OS X boot entries they should work. This email proposes two ways to make them go away, and relies mainly on the firmware's built-in boot manager [1] instead to switch between OS's. I suspect a minority aren't familiar with this interface, and many others drop GRUB2 post-install in favor of rEFInd or gummiboot. The explanation for why the underlying problem with the broken entries won't be fixed anytime soon is at the end, because it's too long and you probably don't want to read it. [2]
Option A, patch Anaconda:
If platform.MacEFI, anaconda writes out /etc/default/grub to include:
GRUB_DISABLE_OS_PROBER=true
Consequence: Non-Fedora boot entries won't be created. This includes OS X, pre-existing Linux distros, and Windows. Due to other bugs and limitations it's virtually certain those entries wouldn't work anyway. The alternatives to the broken entries are already primarily in use due to necessity.
Option B, patch GRUB:
Modify util/grub.d/30_os-prober.in to remove (or comment out) lines 44-106. This means grub2-mkconfig simply won't create OS X entries, but will still create other OS entries.
Is there a preference for one of these options, or is there an option c. ? My opinion is to go with option A. It's the simplest patch, it's upstream and downstream tested and supported, it's more discoverable than option B, and it's the only one users can revert post-install.
Let me go a step further and suggest that GRUB_DISABLE_OS_PROBER=true
should be the default for all installs!
1. After installation, a user can turn it back on if they want it but,
by default, the "strange" /etc/grub.d/30_os-prober menuentrys would not
be generated. Sometimes they work but sometimes they do not.
2. There is the additional problem in Fedora 21 due to grub2-2.02 now
using linux16/initrd16 for all linux menuentrys
[see https://bugzilla.redhat.com/show_bug.cgi?id=1108296 and
https://bugzilla.redhat.com/show_bug.cgi?id=1108344]
3. Rather than supporting multi-boot with 30_os-prober, a user can use
40_custom or 41_custom to add menuentrys which can "chain load" using
configfile rather than trying to (poorly) create a valid menuentry which
will actually boot the other system(s).
4. The "nombr" anaconda patch I submitted results in grub2 being
correctly installed and configured but haing the mbr *not* actually
updated. Thus another installed system, which does have the mbr
pointing to it, can act as a "boot director" to chainload using
configfile grub.cfg or chainload +1 a boot partition.
Suggestion: If GRUB_DISABLE_OS_PROBER=true is the new default, I suggest
that there be some additional documentation explaining how to create
40_custom and/or 41_custom files which will boot the other installed
systems ... or not in the case of OS X where there is a better
alternative of using the firmware.
Gene
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
