Bug 903937 - Mac OS X GRUB entries don't work
Summary: Mac OS X GRUB entries don't work
Status: CLOSED DUPLICATE of bug 893179
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-01-25 05:17 UTC by Chris Murphy
Modified: 2015-06-23 18:49 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-07-10 19:02:59 UTC
Type: Bug

Attachments (Terms of Use)

Description Chris Murphy 2013-01-25 05:17:47 UTC
Description of problem:
On a computer with OS X installed, after Fedora is installed, the GRUB2 menu entries for OS X do not boot OS X.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install from DVD or Live, 
2. Reboot upon successful install.
3. Choose any OS X option, e.g. "Mac OS X (64-bit) (on /dev/sda2)"
Actual results:
error: can't find command 'xnu_uuid' 
error: can't find command 'xnu_kernel64' 
error: can't find command 'xnu_kextdir'

Press any key to continue…

Expected results:

For OS X to boot.

Additional info:
The problem is the result of three things:
a. grubx64.efi doesn't have the three xnu_ modules built into it.
b. anaconda doesn't run grub2-install on (U)EFI computers, to create a /boot/grub2/x86_64-efi folder containing these modules
c. grub2-efi package doesn't contain or install the modules to /boot/grub2/x86_64

So this could be an anaconda bug if it should be running grub2-install on EFI computers.

Comment 1 Chris Murphy 2013-01-25 06:02:57 UTC

After running grub2-install, the necessary kernel modules are put into /boot/grub2/x86_64-efi. The problem still occurs. The grubx64.efi is looking on the ESP in /EFI/fedora/x86_64-efi folder for these modules, not in /boot/grub2 which is by default where grub2-install places them.

Comment 2 Mads Kiilerich 2013-02-24 17:03:36 UTC
The main problem must be that Fedora on efi by design doesn't load modules dynamically - especially not from /boot. The easy solution would be to make sure that the necessary modules are included in the signed efi.

Which modules are needed - and how big are they?

Do it work correctly if the right modules are available?

Comment 3 Chris Murphy 2013-03-01 17:38:26 UTC
1. xnu.mod and xnu_uuid.mod, combined are 32KB.

2. grubx64.efi's prefix is set to its location, e.g. ESP//EFI/fedora. It's not set to ESP//EFI/fedora/grub2. grub2-install only installs modules to $prefix/grub2 so I can't use grub2-install to make the modules available. I have to manually copy them to ESP//EFI/fedora/x86_64-efi. If I do that, this bug isn't triggered. However the bug 904668 is triggered.

Comment 4 Fedora End Of Life 2013-04-03 17:04:47 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:

Comment 5 Chris Murphy 2013-07-10 19:02:59 UTC

*** This bug has been marked as a duplicate of bug 893179 ***

Comment 6 spital 2015-06-23 18:49:55 UTC

Well at the moment GRUB upstream doesn't care about this problem enough to fix it. You could edit /etc/default/grub and add GRUB_DISABLE_OS_PROBER=true, then edit /etc/grub.d/40_custom to add an entry for OS X that includes:

set root=(hd1,gpt3) 
chainloader (hd1,gpt3)/System/Library/CoreServices/boot.efi 

And then run grub2-mkconfig to update the grub.cfg with these changes.

Note You need to log in before you can comment on or make changes to this bug.