Bug 893179

I can confirm this on a mid-2010 MacBook Pro 6,2 with OS X 10.8 "Mountain Lion" and Fedora 18 Final, KDE version, and grub2 2.00.13.fc18.

Sorry for the late answer. Would you please give the output of 'os-prober' command? It might be also helpful to attach its syslog output too.

Created attachment 683937 [details]
os-prober output

Created attachment 683938 [details]
os-prober stderr

Created attachment 683939 [details]
os-prober syslog

I wanted 'os-prober' command output, not grub2-mkconfig. Would you please just run os-prober on command prompt and get the output? Also please indicate where MacOSX is actually installed.

Anyway, after looking through logs, it seems that os-prober has found 3 MacOSX installs for you on sdb2, 4 and 5. You might not have 3 MacOSX installations, but I guess that you have at least one installation in one of these partitions. right?
But, the error message related to xnu_* commands seems to be related to grub2 itself and not os-prober. This is probably a grub2 bug.

*** Bug 903937 has been marked as a duplicate of this bug. ***

Yes there are two bugs. os-prober bug is identifying the mactel-boot created hfs+ EFI System partition as a genuine OS X bootable system, which it isn't, so that needs a separate bug filed.

The grub2 bug is that the signed grubx64.efi in grub2-efi package doesn't contain the xnu modules; nor are they installed because anaconda didn't run grub2-install, so they can't be found by core.img and hence the error messages "can't find command". Even if this is fixed, I then run into bug 904668 (filed upstream savannah as 39460). So before the lack of the xnu module in the signed grub.efi is fixed, I think we need to figure out whether the grub xnu module is long term maintainable, or if it makes more sense to simplify the code and just have grub chainload the Apple bootloader as suggested by mjg59 in bug 982847.

Bug is still present in grub2-efi-2.00-23.fc19.x86_64, changing to rawhide.

Still broken in Fedora 19...

Hm, how am I supposed to chainload OSX? 

I can't even seem to make it find the *partition*...

I've copied the complex weirdness from the (working) Linux menu entries, when the simple version without the video or the search bits didn't work. And still it fails...

menuentry "OSX chainloader" {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod hfsplus
        set root="hd0,gpt2"
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  cdc1342c-49fb-3c68-8512-b9bd90c0e12c
        else
          search --no-floppy --fs-uuid --set=root cdc1342c-49fb-3c68-8512-b9bd90c0e12c
        fi
	chainloader /System/Library/CoreServices/boot.efi
}

error: failure reading sector 0x0 from 'hd0'.
error: failure reading sector 0x0 from 'cd0'.
error: failure reading sector 0x0 from 'hd0'.
error: failure reading sector 0x0 from 'cd0'.
error: no such device: cdc1342c-49fb-3c68-8512-b9bd90c0e12c.
error: disk 'hd0,gpt2' not found.

Press any key to continue...


[root@shinybook ~]# mount /dev/disk/by-uuid/cdc1342c-49fb-3c68-8512-b9bd90c0e12c /mnt/macos
[root@shinybook ~]# ls -l /mnt/macos/System/Library/CoreServices/boot.efi
-rw-r--r--. 1 root root 332464 Jul 27  2012 /mnt/macos/System/Library/CoreServices/boot.efi

(In reply to David Woodhouse from comment #11)
I think you need to use the multiboot command instead of chainloader.

This problem still persists in Fedora 20. I have a Mac Mini with Lion Server and Fedora, and the Mac partitions are detected (although I get 4 entries in grub2-efi for one Mac install), but none of them will boot. They all complain about the missing xnu_* grub2 modules.

Any chance we can get some fresh eyes on this problem and bring it to resolution? Or at least provide a workaround?

So, the first part of a workaround seems to be this:

sudo cp -a /boot/grub2/x86_64-efi /boot/efi/EFI/fedora/

to get the modules in the right place, and get grub to attempt to boot OS X, but this doesn't get me much further unfortunately.

The best workaround is probably to use the apple boot menu for selecting OS instead of the grub menu.

I doubt that putting the modules on the ESP will help. The EFI bootloader is signed for "secure boot" and do as far as I know have module loading disabled.

The way forward is probably to figure out what works and is recommended upstream ... and then figure out how the Fedora fork broke it.

Upstream wants to use xnu modules to boot OS X and this strategy hasn't ever been stable or reliable because Apple's boot.efi and kernel change so frequently. It hasn't worked for years, resulting in xnu kernel panicking. I don't understand why it's acceptable to chainload Windows for reliable booting, and yet it's not acceptable to do the same for OS X. Supposedly there's a fix in upstream's GRUB 2.02beta but I haven't been able to trouble myself to build and test it.

Next, Fedora would have to agree to built grubx64.efi in the grub2-efi package with these modules built. So it's going to take two things to fix it

FWIW, BIOS chainload is also frowned upon upstream.

Rawhide has been rebased to 2.02beta ... but no koji builds yet.

(In reply to Mads Kiilerich from comment #17)
> FWIW, BIOS chainload is also frowned upon upstream.

I don't understand this at all, seeing as it's exactly how GRUB has always booted Windows since forever.

How is grubx64.efi multibooting Apple's boot.efi considered either BIOS or chainloading related? Using Apple's boot loader would at least work. I really don't understand the value in reinventing this wheel and making it behave like a Rube Goldberg contraption. It's been broken for 4.5 years at least.

I am afraid this is still broken in Fedora 21 Workstation. (Macbook 5.1)

Yes it's an upstream GRUB2 bug. These entries should not be created by grub-mkconfig when on Linux booted in EFI mode; the GRUB xnu modules were apparently intended only to function in CSM-BIOS mode as a way to (re)boot OS X in EFI mode. (Talk about a totally weird edge case for someone to go to this effort.)

Going forward, GRUB entries for OS X should chainload the Apple bootloader instead. Open question whether GRUB upstream will fix this, or if Fedora's GRUB should just inhibit creation of OS X entries in the meantime.

Start of thread:
http://lists.gnu.org/archive/html/grub-devel/2014-10/msg00044.html
Acknowledgement that chainloading is a better way forward, given Apple's changed default on disk format. But it looks like some of the fix needs to happen in os-prober, to return efi loader type; the remaining problem is that OS X doesn't have a standard efi loader location (neither file system nor path to the loader). So the fix may involve both os-prober and grub2.

Still relevant in F22. It certainly confused a user I installed Fedora for, as well as me.

http://forums.fedoraforum.org/archive/index.php/t-288002.html
bottom 
worked


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.

*** Bug 904668 has been marked as a duplicate of this bug. ***

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

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

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Is this going to be fixed in time for F24?

Still happening with a fresh installation of F24.

The following entry did work:
menuentry "MacOS X ChainLoader" {
	insmod part_gpt
	insmod hfsplus
	set root=(hd1,gpt3)
	chainloader (hd1,gpt3)/System/Library/CoreServices/boot.efi
	boot
}

Yep, it's an ancient bug that no one upstream cares to properly support or even just plain remove, so the broken thing remains. Upstream bug is https://savannah.gnu.org/bugs/?42954

The easiest thing to do would be delete lines 44-109 in /etc/grub.d/30_os-prober so the wrong entries aren't created, at least. Yes, ideally it'd just chainload the macOS boot.efi binary.

Sorry, that URL is not related to this issue. I can't find the upstream bug.

Still happening with F25. Additionally, chainloading doesn't work here (likely because of File Vault encryption). Is there some way we could add an entry that simply reboots to the apple efi loader (that does work here at least)?

The 3rd partition on a Mac is a normal HFS Plus volume that contains a bootloader. From GRUB commandline:

chainloader (hd0,gpt3)/System/Library/CoreServices/boot/efi
boot

This works for me now for some time, including with the latest macOS version. I'm not sure what needs to be changed, maybe something in os-prober as well as /etc/grub.d/30_os-prober; because os-prober is searching for the wrong thing therefore it finds and reports back the wrong partition, and the script is generating the wrong commands. So to me it sounds like an upstream solution, but so far upstream has resisted this. I can help with most of the bird's eye logistics, as well as testing patches, but I'm useless in producing the actual patches.

Nominating as PrioritizedBug. If you dual-boot Fedora with MacOS, you then can't boot MacOS from grub. You have to use a one-time boot menu (holding down the Option key during power up) to get into MacOS. That's quite obscure.

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

This bug is tracked as Prioritized Bug: https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues

Hi Alberto,

may someone from your team look at this bug please ?

Thanks,
Jan

Peter Jones is not available atm, I'll bring it up to him next week once he is back to get an idea of what needs to be done. We happen to have a Macbook unit to test this stuff in the Munich lab.

The latest from upstream is from 2.5 years ago:
http://lists.gnu.org/archive/html/grub-devel/2014-10/msg00056.html

What grok from that is upstream wanted to preserve CSM boot capability. I didn't grok that then, and it makes even less sense now. Direct xnu bootloading is a dead end because it'll be located on a file system we can't read: core storage (Apple's LVM, which is undocumented), or APFS (Apple's replacement for HFS+, also currently undocumented). So handing things off to Apple's bootloader as soon as possible seems the most practical and maintainable.

Baring that, at least disable the creation of the two bogus Mac OS X boot entries, and just expect users to boot macOS via the firmware's boot manager (option key at boot chime).

(In reply to Chris Murphy from comment #37)
> The latest from upstream is from 2.5 years ago:
> http://lists.gnu.org/archive/html/grub-devel/2014-10/msg00056.html
> 
> What grok from that is upstream wanted to preserve CSM boot capability. I
> didn't grok that then, and it makes even less sense now. Direct xnu
> bootloading is a dead end because it'll be located on a file system we can't
> read: core storage (Apple's LVM, which is undocumented), or APFS (Apple's
> replacement for HFS+, also currently undocumented). So handing things off to
> Apple's bootloader as soon as possible seems the most practical and
> maintainable.
> 
> Baring that, at least disable the creation of the two bogus Mac OS X boot
> entries, and just expect users to boot macOS via the firmware's boot manager
> (option key at boot chime).

I'm leaning towards this option as well, will wait for peter's comments once he is back.

Can somebody show me the actual os-prober output?  The attachment that claims to be that above is actually the 30_os-prober output instead, and I need its /input/.

--- 8< ---
# os-prober
/dev/sda4:Mac OS X:MacOSX:macosx
--- >8 ---

Good enough?

Yeah, I get: 

# os-prober 
/dev/sda2:Mac OS X:MacOSX:macosx

here, so at least it seems to be somewhat consistent. :)

This bug is removed from the list of prioritized bugs as it hits just minority of users.

> # os-prober
> /dev/sda4:Mac OS X:MacOSX:macosx

The same output here.

(In reply to Jan Kurik from comment #42)
> This bug is removed from the list of prioritized bugs as it hits just
> minority of users.

It hits a minority of users because people who can't even get the software installed aren't likely to be reporting it one by one, unless they have a special attachment to Fedora, they'll just use something else instead.

(In reply to Bastien Nocera from comment #44)
> (In reply to Jan Kurik from comment #42)
> > This bug is removed from the list of prioritized bugs as it hits just
> > minority of users.
> 
> It hits a minority of users because people who can't even get the software
> installed aren't likely to be reporting it one by one, unless they have a
> special attachment to Fedora, they'll just use something else instead.

It doesn't prevent Fedora from being installed or booted; it's just that the two MacOS X menu entries do not work.

This bug affects all Mac users, ergo comment 42 is saying a Mac related bug can never become prioritized. However, Workstation WG has said Macs are a priority target market. So now there's an incongruity where Macs are a priority target audience marketing wise, but not for priority bug fixes.

The rationale to make it no longer a priority is "it's a cosmetic bug" is still flawed, but better than the reasoning in 42.

Anyway, the least effort fix would be to inhibit the creation of the Mac OS X entries entirely. But last I checked upstream years ago, they didn't like that idea, for unknown reasons they want to keep supporting BIOS GRUB directly booting xnu, which isn't possible with recent macOS versions. What everyone with actual Apple hardware needs these days is EFI GRUB chainloading Apple's bootloader, because there's no other way to boot macOS for the foreseeable future.

Hence, the easist path is just don't create any entries, and expect the user to use the Apple firmware's built-in boot manager to pick an OS.

I was able to boot both Fedora and MacOS from grub, tested with F27 and F28 Beta 1.3