GRUB booting Mac OS X (xnu)

GRUB booting Mac OS X (xnu)

[Chris Murphy]

We need to re-evaluate how GRUB will boot OS X for the following reasons:

1. Apple OS X 10.10 (just released) now by default converts for existing, and new installs, the partition to use their "LVM-like" technology, called Core Storage. Neither GRUB nor Linux can read this format. So the xnu module can't locate xnu to directly boot it, nor do grub-mkconfig+os-prober even find that there's an OS X installation available, to know to create boot entries for it. This is probably the biggest show stopper problem; as a majority of OS X users are expected to be using 10.10 by the end of the year, if historical upgrade behavior applies.

2. Increasingly, users are using OS X's full disk encryption (FileVault 2), which likewise uses Core Storage. GRUB xnu modules can't boot this either, even if the user hasn't upgraded to OS X 10.10 (applies to 10.7 released 4 years ago, and newer OS versions).

3. The existing GRUB xnu modules don't support signature verification, so it's a problem for distributions that create a prebaked grubx64.efi that's signed, because potentially arbitrary code can be executed by including the xnu module in the prebaked binary. So distributions aren't doing this, meaning it's not available, and thus xnu based boot entries for OS X fail (and have been failing for a couple years).

4. Since OS X 10.8 there's no longer a 32-bit kernel, so the 32-bit kernel boot option is obsolete.

My suggestion is that GRUB chainload the Apple bootloader, which is found on an unencrypted HFS+ formatted volume, with a unique partition type GUID: 426F6F74-0000-11AA-AA11-00306543ECAC (Apple Boot partition), colloquially called "Recovery HD". This used to work with GRUB2 of some version (?) but isn't anymore and I'm not sure why.
https://savannah.gnu.org/bugs/?42954
https://bugzilla.redhat.com/show_bug.cgi?id=1128374

Once the Apple bootloader is chainloaded, it can of course read Core Storage volumes, encrypted or not, and properly ask for user authentication if the volume is encrypted. So it seems like the simplest solution.


Chris Murphy

Re: GRUB booting Mac OS X (xnu)

[SevenBits]

[-- Attachment #1: Type: text/plain, Size: 2953 bytes --]

On Friday, October 24, 2014, Chris Murphy <lists@colorremedies.com> wrote:

> We need to re-evaluate how GRUB will boot OS X for the following reasons:
>
> 1. Apple OS X 10.10 (just released) now by default converts for existing,
> and new installs, the partition to use their "LVM-like" technology, called
> Core Storage. Neither GRUB nor Linux can read this format.


I believe there wasn't more published on this. Why would Apple do this? It
makes resizing disks 10x harder...


>  So the xnu module can't locate xnu to directly boot it, nor do
> grub-mkconfig+os-prober even find that there's an OS X installation
> available, to know to create boot entries for it. This is probably the
> biggest show stopper problem; as a majority of OS X users are expected to
> be using 10.10 by the end of the year, if historical upgrade behavior
> applies.
>
> 2. Increasingly, users are using OS X's full disk encryption (FileVault
> 2), which likewise uses Core Storage. GRUB xnu modules can't boot this
> either, even if the user hasn't upgraded to OS X 10.10 (applies to 10.7
> released 4 years ago, and newer OS versions).
>
> 3. The existing GRUB xnu modules don't support signature verification, so
> it's a problem for distributions that create a prebaked grubx64.efi that's
> signed, because potentially arbitrary code can be executed by including the
> xnu module in the prebaked binary. So distributions aren't doing this,
> meaning it's not available, and thus xnu based boot entries for OS X fail
> (and have been failing for a couple years).
>
> 4. Since OS X 10.8 there's no longer a 32-bit kernel, so the 32-bit kernel
> boot option is obsolete.
>
> My suggestion is that GRUB chainload the Apple bootloader, which is found
> on an unencrypted HFS+ formatted volume, with a unique partition type GUID:
> 426F6F74-0000-11AA-AA11-00306543ECAC (Apple Boot partition), colloquially
> called "Recovery HD". This used to work with GRUB2 of some version (?) but
> isn't anymore and I'm not sure why.
> https://savannah.gnu.org/bugs/?42954
> https://bugzilla.redhat.com/show_bug.cgi?id=1128374
>
> Once the Apple bootloader is chainloaded, it can of course read Core
> Storage volumes, encrypted or not, and properly ask for user authentication
> if the volume is encrypted. So it seems like the simplest solution.


Apologies for my ignorance, but isn't how OS X has traditionally been
booted with GRUB to begin with?

I don't see how this will work. My understanding is that the Recovery HD
contains an install of OS X that is specifically designed to recovery the
OS X copy on the main user partition. Wouldn't chain loading the boot
loader in this partition just boot the Recovery software, and not the
actual OS X system that the user actually intends to use?


>
>
> Chris Murphy
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org <javascript:;>
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 3978 bytes --]

Re: GRUB booting Mac OS X (xnu)

[Chris Murphy]

[-- Attachment #1: Type: text/plain, Size: 4786 bytes --]


On Oct 24, 2014, at 12:50 PM, SevenBits <sevenbitstech@gmail.com> wrote:

> On Friday, October 24, 2014, Chris Murphy <lists@colorremedies.com> wrote:
> We need to re-evaluate how GRUB will boot OS X for the following reasons:
> 
> 1. Apple OS X 10.10 (just released) now by default converts for existing, and new installs, the partition to use their "LVM-like" technology, called Core Storage. Neither GRUB nor Linux can read this format.
> 
> I believe there wasn't more published on this. Why would Apple do this? It makes resizing disks 10x harder…

Apple doesn't explain much of anything except in glittering generalities. It's possible they have some future plan as yet unrealized. But the resizing shouldn't be much different, the disktuil command has always done fs resize and partition resize in one step. They can do fs resize and LV resize in one step also. But I don't have 10.10 installed yet so I don't know if it shrinks the PV as well, and leaves some free space or like before if it just adds a FAT32 volume where there would have been free space.


>  
>  So the xnu module can't locate xnu to directly boot it, nor do grub-mkconfig+os-prober even find that there's an OS X installation available, to know to create boot entries for it. This is probably the biggest show stopper problem; as a majority of OS X users are expected to be using 10.10 by the end of the year, if historical upgrade behavior applies.
> 
> 2. Increasingly, users are using OS X's full disk encryption (FileVault 2), which likewise uses Core Storage. GRUB xnu modules can't boot this either, even if the user hasn't upgraded to OS X 10.10 (applies to 10.7 released 4 years ago, and newer OS versions).
> 
> 3. The existing GRUB xnu modules don't support signature verification, so it's a problem for distributions that create a prebaked grubx64.efi that's signed, because potentially arbitrary code can be executed by including the xnu module in the prebaked binary. So distributions aren't doing this, meaning it's not available, and thus xnu based boot entries for OS X fail (and have been failing for a couple years).
> 
> 4. Since OS X 10.8 there's no longer a 32-bit kernel, so the 32-bit kernel boot option is obsolete.
> 
> My suggestion is that GRUB chainload the Apple bootloader, which is found on an unencrypted HFS+ formatted volume, with a unique partition type GUID: 426F6F74-0000-11AA-AA11-00306543ECAC (Apple Boot partition), colloquially called "Recovery HD". This used to work with GRUB2 of some version (?) but isn't anymore and I'm not sure why.
> https://savannah.gnu.org/bugs/?42954
> https://bugzilla.redhat.com/show_bug.cgi?id=1128374
> 
> Once the Apple bootloader is chainloaded, it can of course read Core Storage volumes, encrypted or not, and properly ask for user authentication if the volume is encrypted. So it seems like the simplest solution.
> 
> Apologies for my ignorance, but isn't how OS X has traditionally been booted with GRUB to begin with?

Maybe I don't understand the question. For years now, GRUB uses two or three xnu modules to directly bootload xnu, not chainload the Apple bootloader. The grub.cfg also contains a lot of script text doing things like checking for a hibernation/sleep image, and maybe some other things. It's a lot more complicated than a linux menu entry.

> 
> I don't see how this will work. My understanding is that the Recovery HD contains an install of OS X that is specifically designed to recovery the OS X copy on the main user partition. Wouldn't chain loading the boot loader in this partition just boot the Recovery software, and not the actual OS X system that the user actually intends to use?


Apple's firmware can read HFS+ directly, it cannot read Core Storage volumes. So in the case of encrypted installations, the firmware loads /System/Library/CoreServices/boot.efi from the Recovery HD partition and presumably the unencrypted kernel and kextcache (initramfs). Any unencrypted implementation of the main volume as a Core Storage volume would still work this way. Once the kernel+kextcache are running, it of course understands Core Storage and the rest of boot completes normally.

To boot recovery mode requires an additional flag. Typically this is done by the user with command-r or explicitly choosing Recovery HD icon from  the firmware boot manager UI.

Like I said, I used to be able to use GRUB to chainload boot.efi on Recovery HD, and I'd immediately get a screen to enter the password to unlock the encrypted volume. But now I get errors with GRUB 2.02, I haven't done much regression testing to see when this broke; it's also possible something on Apple's end changed which broke things. Afterall they do annual releases these days.


Chris Murphy

[-- Attachment #2: Type: text/html, Size: 6023 bytes --]

Re: GRUB booting Mac OS X (xnu)

[Andrei Borzenkov]

В Fri, 24 Oct 2014 13:29:01 -0600
Chris Murphy <lists@colorremedies.com> пишет:

> 
> On Oct 24, 2014, at 12:50 PM, SevenBits <sevenbitstech@gmail.com> wrote:
> 
> > On Friday, October 24, 2014, Chris Murphy <lists@colorremedies.com> wrote:
> > We need to re-evaluate how GRUB will boot OS X for the following reasons:
> > 
> > 1. Apple OS X 10.10 (just released) now by default converts for existing, and new installs, the partition to use their "LVM-like" technology, called Core Storage. Neither GRUB nor Linux can read this format.
> > 
> > I believe there wasn't more published on this. Why would Apple do this? It makes resizing disks 10x harder…
> 
> Apple doesn't explain much of anything except in glittering generalities. It's possible they have some future plan as yet unrealized. But the resizing shouldn't be much different, the disktuil command has always done fs resize and partition resize in one step. They can do fs resize and LV resize in one step also. But I don't have 10.10 installed yet so I don't know if it shrinks the PV as well, and leaves some free space or like before if it just adds a FAT32 volume where there would have been free space.
> 
> 
> >  
> >  So the xnu module can't locate xnu to directly boot it, nor do grub-mkconfig+os-prober even find that there's an OS X installation available, to know to create boot entries for it. This is probably the biggest show stopper problem; as a majority of OS X users are expected to be using 10.10 by the end of the year, if historical upgrade behavior applies.
> > 
> > 2. Increasingly, users are using OS X's full disk encryption (FileVault 2), which likewise uses Core Storage. GRUB xnu modules can't boot this either, even if the user hasn't upgraded to OS X 10.10 (applies to 10.7 released 4 years ago, and newer OS versions).
> > 
> > 3. The existing GRUB xnu modules don't support signature verification, so it's a problem for distributions that create a prebaked grubx64.efi that's signed, because potentially arbitrary code can be executed by including the xnu module in the prebaked binary. So distributions aren't doing this, meaning it's not available, and thus xnu based boot entries for OS X fail (and have been failing for a couple years).
> > 
> > 4. Since OS X 10.8 there's no longer a 32-bit kernel, so the 32-bit kernel boot option is obsolete.
> > 
> > My suggestion is that GRUB chainload the Apple bootloader, which is found on an unencrypted HFS+ formatted volume, with a unique partition type GUID: 426F6F74-0000-11AA-AA11-00306543ECAC (Apple Boot partition), colloquially called "Recovery HD". This used to work with GRUB2 of some version (?) but isn't anymore and I'm not sure why.
> > https://savannah.gnu.org/bugs/?42954
> > https://bugzilla.redhat.com/show_bug.cgi?id=1128374
> > 
> > Once the Apple bootloader is chainloaded, it can of course read Core Storage volumes, encrypted or not, and properly ask for user authentication if the volume is encrypted. So it seems like the simplest solution.
> > 
> > Apologies for my ignorance, but isn't how OS X has traditionally been booted with GRUB to begin with?
> 
> Maybe I don't understand the question. For years now, GRUB uses two or three xnu modules to directly bootload xnu, not chainload the Apple bootloader. The grub.cfg also contains a lot of script text doing things like checking for a hibernation/sleep image, and maybe some other things. It's a lot more complicated than a linux menu entry.
> 
> > 
> > I don't see how this will work. My understanding is that the Recovery HD contains an install of OS X that is specifically designed to recovery the OS X copy on the main user partition. Wouldn't chain loading the boot loader in this partition just boot the Recovery software, and not the actual OS X system that the user actually intends to use?
> 
> 
> Apple's firmware can read HFS+ directly, it cannot read Core Storage volumes. So in the case of encrypted installations, the firmware loads /System/Library/CoreServices/boot.efi from the Recovery HD partition and presumably the unencrypted kernel and kextcache (initramfs). Any unencrypted implementation of the main volume as a Core Storage volume would still work this way. Once the kernel+kextcache are running, it of course understands Core Storage and the rest of boot completes normally.
> 
> To boot recovery mode requires an additional flag. Typically this is done by the user with command-r or explicitly choosing Recovery HD icon from  the firmware boot manager UI.
> 
> Like I said, I used to be able to use GRUB to chainload boot.efi on Recovery HD, and I'd immediately get a screen to enter the password to unlock the encrypted volume. But now I get errors with GRUB 2.02, I haven't done much regression testing to see when this broke; it's also possible something on Apple's end changed which broke things. Afterall they do annual releases these days.
> 


The error message on your screenshot does not look like coming from
grub2. Also magic it displays is rather amusing

bor@opensuse:~/src/grub> echo -e '\x73\x69\x68\x54' 
sihT

Could you test with earlier versions? I usually made recovery CD to
boot, it is fast and can be done from build directory directly, which
makes bisecting easier.

Re: GRUB booting Mac OS X (xnu)

[Chris Murphy]

On Oct 26, 2014, at 12:53 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> 
> The error message on your screenshot does not look like coming from
> grub2. Also magic it displays is rather amusing
> 
> bor@opensuse:~/src/grub> echo -e '\x73\x69\x68\x54' 
> sihT

It looks like it's coming from the Apple bootloader, not GRUB, and you can also see screen artifacts in that photo. So some memory or graphics state doesn't seem right.

However, if I use grub command exit, OS X boots! And it does this using the identical boot.efi I'm using with chainloader.

> 
> Could you test with earlier versions?

I tested with a GRUB2 2.00 versions from Fedora 19 and 20 and posted those, and it still fails but differently. I uploaded two new photos for each showing their different failure messages.

Also weirdly, the GRUB ls command doesn't list files and tab won't autocomplete; whereas chainloader does tab autocomplete and I'm able to navigate to the boot.efi file.

And I also note that Recovery HD (Apple Boot partition type GUID) contains two bootloaders:

/System/Library/CoreServices/boot.efi
/com.apple.recovery.boot/boot.efi

Their sha256sums are identical though.


Chris Murphy

Re: GRUB booting Mac OS X (xnu)

[Chris Murphy]

OK I've got this working. The problem was user error. Explicitly setting root is necessary, and I've updated the bug.
https://savannah.gnu.org/bugs/index.php?42954

So the approach of chainloading Apple's boot.efi is valid. What's needed is to consider Recovery HD (Apple Boot partitiontype GUID) to be the partition searched by os-prober, figure out its UUID so that set root can be done by UUID.

The Apple Boot [1] is used by OS X 10.7 through 10.10, so it's a good start point to search for OS X since it won't be anywhere else.

Going forward, any conventional HFS+ partition [2] isn't going to be OS X, but instead will be any distribution using mactel boot, since putting grubx64.efi on the FAT32 ESP is *not* picked up by Apple's firmware as a legit bootloader. Only if there is an NVRAM entry for it, and bootcurrent has it listed first, can it be used. By putting grubx64.efi on hfsplus, and tricking the firmware into thinking it's an OS X bootloader, we get a prettier user friendly linux boot experience on Macs.


[1] partitiontype GUID 426F6F74-0000-11AA-AA11-00306543ECAC
[2] partitiontype GUID 48465300-0000-11AA-AA11-00306543ECAC


Chris Murphy

Re: GRUB booting Mac OS X (xnu)

[Chris Murphy]

On Oct 26, 2014, at 10:06 PM, Chris Murphy <lists@colorremedies.com> wrote:

> OK I've got this working. The problem was user error. Explicitly setting root is necessary, and I've updated the bug.
> https://savannah.gnu.org/bugs/index.php?42954
> 
> So the approach of chainloading Apple's boot.efi is valid. What's needed is to consider Recovery HD (Apple Boot partitiontype GUID) to be the partition searched by os-prober, figure out its UUID so that set root can be done by UUID.
> 
> The Apple Boot [1] is used by OS X 10.7 through 10.10, so it's a good start point to search for OS X since it won't be anywhere else.
> 
> Going forward, any conventional HFS+ partition [2] isn't going to be OS X, but instead will be any distribution using mactel boot, since putting grubx64.efi on the FAT32 ESP is *not* picked up by Apple's firmware as a legit bootloader. Only if there is an NVRAM entry for it, and bootcurrent has it listed first, can it be used. By putting grubx64.efi on hfsplus, and tricking the firmware into thinking it's an OS X bootloader, we get a prettier user friendly linux boot experience on Macs.
> 
> 
> [1] partitiontype GUID 426F6F74-0000-11AA-AA11-00306543ECAC
> [2] partitiontype GUID 48465300-0000-11AA-AA11-00306543ECAC


mactel-boot
http://www.codon.org.uk/~mjg59/mactel-boot/


Chris Murphy

Re: GRUB booting Mac OS X (xnu)

[Andrei Borzenkov]

On Mon, Oct 27, 2014 at 7:06 AM, Chris Murphy <lists@colorremedies.com> wrote:
> OK I've got this working. The problem was user error. Explicitly setting root is necessary, and I've updated the bug.
> https://savannah.gnu.org/bugs/index.php?42954
>
> So the approach of chainloading Apple's boot.efi is valid. What's needed is to consider Recovery HD (Apple Boot partitiontype GUID) to be the partition searched by os-prober, figure out its UUID so that set root can be done by UUID.
>

Given that xnu loader apparently never worked on native EFI grub, I
think that would be good idea. It does not look like anything needs to
be changed in grub2 though. You will need to modify os-prober to
return efi loader type in this case; grub2 already supports
chainloading EFI binary in 30_os-prober.

You still need to keep current xnu loader (and macosx os-prober type)
for the case of CSM boot though. The simplest way is to emit either
efi or macosx similar to what windows script does. It is not fool
proof, but in practice seems to work - users rarely jump between CSM
to EFI so it is reasonable to expect that they want to boot in the
same mode as is currently used.

> The Apple Boot [1] is used by OS X 10.7 through 10.10, so it's a good start point to search for OS X since it won't be anywhere else.
>

give grub device name; it is file system and has UUID right? So it is
going to find it during boot just fine.

> Going forward, any conventional HFS+ partition [2] isn't going to be OS X, but instead will be any distribution using mactel boot, since putting grubx64.efi on the FAT32 ESP is *not* picked up by Apple's firmware as a legit bootloader. Only if there is an NVRAM entry for it, and bootcurrent has it listed first, can it be used. By putting grubx64.efi on hfsplus, and tricking the firmware into thinking it's an OS X bootloader, we get a prettier user friendly linux boot experience on Macs.
>
>
> [1] partitiontype GUID 426F6F74-0000-11AA-AA11-00306543ECAC
> [2] partitiontype GUID 48465300-0000-11AA-AA11-00306543ECAC
>
>
> Chris Murphy
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB booting Mac OS X (xnu)

[Chris Murphy]

On Oct 27, 2014, at 1:39 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:



> It does not look like anything needs to
> be changed in grub2 though. You will need to modify os-prober to
> return efi loader type in this case; grub2 already supports
> chainloading EFI binary in 30_os-prober.

30_os-prober creates this entry for EFI systems:
 284		  chainloader /EFI/${DEVICE}

This won't work on Macs, because the OS X bootloader isn't a.) on the ESP and b.) isn't in an \EFI directory.

So it looks like os-prober needs to look for the Apple Boot partitiontypeGUID, pass that device to 30_os-prober which can then do:
		chainloader /System/Library/CoreServices/boot.efi

Currently 30_os-prober lines 44 to 103 appear obsolete and should be removed. That's what creates the OS X entries right now using the various xnu modules.


> 
> You still need to keep current xnu loader (and macosx os-prober type)
> for the case of CSM boot though.

What's the use case for this? Something like linux BIOS installation with i386 version of GRUB, and it uses the xnu modules to EFI boot OS X? OK, but that's still broken today and going forward because neither GRUB nor linux can read Core Storage, which is where the xnu kernel and its initramfs are found. And anyone using any version of OS X for the past three years with full disk encryption likewise can't use GRUB xnu modules to EFI boot OS X from CSM mode either. This seems like a very legacy use case.

If it's possible to have an i386 30_os-prober that keeps the current osx xnu module boot entries intact; but on x86_64 the 30_os-prober makes the grub.cfg with chainloader, then I'm fine with that.

> 
>> The Apple Boot [1] is used by OS X 10.7 through 10.10, so it's a good start point to search for OS X since it won't be anywhere else.
>> 
> 
> give grub device name; it is file system and has UUID right? So it is
> going to find it during boot just fine.

Yes, I mean for grub-mkconfig to create the entry via os-prober it's going to need to know to only look for OS X's bootloader that has the Apple Boot partitiontype GUID because it's not going to find it anywhere else. And if it does, it's not really an OS X bootloader, it's likely a renamed grubx64.efi masquerading as an OS X bootloader, so that the built-in firmware boot manager displays it as a boot option at start up time (which it doesn't do if the EFI binary is on the EFI System partition).


Chris Murphy

Re: GRUB booting Mac OS X (xnu)

[Andrei Borzenkov]

В Mon, 27 Oct 2014 10:30:31 -0600
Chris Murphy <lists@colorremedies.com> пишет:

> 
> On Oct 27, 2014, at 1:39 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> 
> 
> 
> > It does not look like anything needs to
> > be changed in grub2 though. You will need to modify os-prober to
> > return efi loader type in this case; grub2 already supports
> > chainloading EFI binary in 30_os-prober.
> 
> 30_os-prober creates this entry for EFI systems:
>  284		  chainloader /EFI/${DEVICE}
> 

No, it does not. It creates

      prepare_grub_to_access_device ${DEVICE} | sed -e "s/^/\t/"

      cat <<EOF
        chainloader ${EFIPATH}


where DEVICE and EFIPATH are whatever is returned by os-prober.

> This won't work on Macs, because the OS X bootloader isn't a.) on the ESP and b.) isn't in an \EFI directory.
> 

Fine. So write or extend os-prober script that returns correct path.

> So it looks like os-prober needs to look for the Apple Boot partitiontypeGUID, pass that device to 30_os-prober which can then do:
> 		chainloader /System/Library/CoreServices/boot.efi
> 
> Currently 30_os-prober lines 44 to 103 appear obsolete and should be removed. That's what creates the OS X entries right now using the various xnu modules.
> 
> 
> > 
> > You still need to keep current xnu loader (and macosx os-prober type)
> > for the case of CSM boot though.
> 
> What's the use case for this?

If you do not use it does not mean nobody is using it. It still works
just fine if you want it.

> Something like linux BIOS installation with i386 version of GRUB, and
 it uses the xnu modules to EFI boot OS X? OK, but that's still broken
 today 

No, it is not. Please test it.

> and going forward because neither GRUB nor linux can read Core
 Storage, which is where the xnu kernel and its initramfs are found.
 And anyone using any version of OS X for the past three years with
 full disk encryption likewise can't use GRUB xnu modules to EFI boot
 OS X from CSM mode either. This seems like a very legacy use case.
> 
> If it's possible to have an i386 30_os-prober that keeps the current osx xnu module boot entries intact; but on x86_64 the 30_os-prober makes the grub.cfg with chainloader, then I'm fine with that.
> 
> > 
> >> The Apple Boot [1] is used by OS X 10.7 through 10.10, so it's a good start point to search for OS X since it won't be anywhere else.
> >> 
> > 
> > give grub device name; it is file system and has UUID right? So it is
> > going to find it during boot just fine.
> 
> Yes, I mean for grub-mkconfig to create the entry via os-prober it's going to need to know to only look for OS X's bootloader that has the Apple Boot partitiontype GUID because it's not going to find it anywhere else. And if it does, it's not really an OS X bootloader, it's likely a renamed grubx64.efi masquerading as an OS X bootloader, so that the built-in firmware boot manager displays it as a boot option at start up time (which it doesn't do if the EFI binary is on the EFI System partition).

Re: GRUB booting Mac OS X (xnu)

[Chris Murphy]

On Oct 27, 2014, at 12:01 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:

> В Mon, 27 Oct 2014 10:30:31 -0600
> Chris Murphy <lists@colorremedies.com> пишет:
> 
>> 
>> On Oct 27, 2014, at 1:39 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>> 
>> 
>> 
>>> It does not look like anything needs to
>>> be changed in grub2 though. You will need to modify os-prober to
>>> return efi loader type in this case; grub2 already supports
>>> chainloading EFI binary in 30_os-prober.
>> 
>> 30_os-prober creates this entry for EFI systems:
>> 284		  chainloader /EFI/${DEVICE}
>> 
> 
> No, it does not. It creates
> 
>      prepare_grub_to_access_device ${DEVICE} | sed -e "s/^/\t/"
> 
>      cat <<EOF
>        chainloader ${EFIPATH}
> 
> 
> where DEVICE and EFIPATH are whatever is returned by os-prober.

"EFIPATH" doesn't appear in the copy of 30_os-prober I have, from git. There's only

   148		chainloader +1

and

   284		  chainloader /EFI/${DEVICE}





> 
>> This won't work on Macs, because the OS X bootloader isn't a.) on the ESP and b.) isn't in an \EFI directory.
>> 
> 
> Fine. So write or extend os-prober script that returns correct path.

That's out of scope for my expertise. I'm reporting the present grub-mkconfig method of creating OS X entries isn't working, describing why, and a possible work around to make it work in the future. I can test a modification of the script, should it appear.


> 
>> So it looks like os-prober needs to look for the Apple Boot partitiontypeGUID, pass that device to 30_os-prober which can then do:
>> 		chainloader /System/Library/CoreServices/boot.efi
>> 
>> Currently 30_os-prober lines 44 to 103 appear obsolete and should be removed. That's what creates the OS X entries right now using the various xnu modules.
>> 
>> 
>>> 
>>> You still need to keep current xnu loader (and macosx os-prober type)
>>> for the case of CSM boot though.
>> 
>> What's the use case for this?
> 
> If you do not use it does not mean nobody is using it. It still works
> just fine if you want it.

I'll only work on unencrypted OS X volumes with OS X versions 10.9 and older. 


> 
>> Something like linux BIOS installation with i386 version of GRUB, and
> it uses the xnu modules to EFI boot OS X? OK, but that's still broken
> today 
> 
> No, it is not. Please test it.

Either with encryption (available for 3+ years) or OS X 10.10 it doesn't work, because in both cases Core Storage support is mandatory. The user isn't given a choice.

Does it even make sense for GRUB to have OS X menu entries? For over a decade Apple's firmware contains a graphical boot manager that dynamically locates and displays any available OS X installation - activated at the boot chime with option key. I'm not sure it's even necessary to go to the effort to change anything in GRUB EFI except to inhibit the creation of (non-working) OS X entries.


Chris Murphy