[Top][All Lists]

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

Re: GRUB booting Mac OS X (xnu)

From: Chris Murphy
Subject: Re: GRUB booting Mac OS X (xnu)
Date: Mon, 27 Oct 2014 13:05:19 -0600

On Oct 27, 2014, at 12:01 PM, Andrei Borzenkov <address@hidden> wrote:

> В Mon, 27 Oct 2014 10:30:31 -0600
> Chris Murphy <address@hidden> пишет:
>> On Oct 27, 2014, at 1:39 AM, Andrei Borzenkov <address@hidden> 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 

   148          chainloader +1


   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 

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 

Chris Murphy

reply via email to

[Prev in Thread] Current Thread [Next in Thread]