F21 Workstation dual-boot release requirement OS X

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


Chris Murphy



[1] http://support.apple.com/kb/HT1310

[2] GRUB uses its own xnu bootloader, instead of chainloading Apple's bootloader. This xnu module doesn't support signature verification needed for Secure Boot support, so it's not included in the prebaked grubx64.efi installed on the EFI System partition. And therefore OS X boot entries in grub.cfg always fail to work on Fedora.

There's another bump in the road, even if that were fixed or worked around.

GRUB lacks support for OS X's logical volume management, called Core Storage. It's used to implement full disk encryption, and a SSD+HDD "dmcache-like" arrangement; and the next version OS X due for imminent release is purportedly going to use Core Storage by default.

Since GRUB and os-prober don't recognize this format, the xnu module isn't going to be able to find, load or boot the OS X kernel. Moving toward chainloading Apple's bootloader is being explored, but isn't happening in the F21 time frame.




_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list




[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux