Bug 893179 - Automatic MacOSX grub entries are broken (and weird)
Summary: Automatic MacOSX grub entries are broken (and weird)
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 26
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
Keywords: CommonBugs
: 903937 904668 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-08 19:57 UTC by Tom "spot" Callaway
Modified: 2018-04-03 09:49 UTC (History)
25 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-04-03 09:49:00 UTC


Attachments (Terms of Use)
os-prober output (11.75 KB, text/plain)
2013-01-20 22:20 UTC, Jason Antman
no flags Details
os-prober stderr (84 bytes, text/plain)
2013-01-20 22:21 UTC, Jason Antman
no flags Details
os-prober syslog (18.26 KB, text/plain)
2013-01-20 22:21 UTC, Jason Antman
no flags Details

Description Tom "spot" Callaway 2013-01-08 19:57:03 UTC
Description of problem:

Installed Fedora 18 (TC4) onto MacBook Pro 8,2, with MacOSX preinstall on a separate partition.

Grub shows four entries:

Mac OS X (32-bit) (on /dev/sda2)
Mac OS X (64-bit) (on /dev/sda2)
Mac OS X (32-bit) (on /dev/sda4)
Mac OS X (64-bit) (on /dev/sda4)

Trying to boot any of these 32bit entries results in:

error: can't find command 'xnu_uuid'
error: can't find command 'xnu_kernel'
error: can't find command 'xnu_kextdir'

Trying to boot any of these 64bit entries results in:

error: can't find command 'xnu_uuid'
error: can't find command 'xnu_kernel64'
error: can't find command 'xnu_kextdir'

The Mac OSX install is a 64bit install, and it is still working fine from the EFI menu.

The disk is partitioned GPT.

Number   Start   End     Size    File system     Name                  Flags
 1       20.5kB  210MB   210MB   fat32           EFI system partition  boot
 2       210MB   51.2GB  51.0GB  hfs+            Customer
 3       51.2GB  51.8GB  650MB   hfs+            Recovery HD
 4       51.8GB  52.0GB  210MB   hfs+
 5       52.0GB  52.6GB  524MB   ext4
 6       52.6GB  60.9GB  8288MB  linux-swap(v1)
 7       60.9GB  115GB   53.7GB  ext4
 8       115GB   251GB   136GB   ext4

Comment 1 Jason Antman 2013-01-20 19:27:05 UTC
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.

Comment 2 Hedayat Vatankhah 2013-01-20 19:30:12 UTC
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.

Comment 3 Jason Antman 2013-01-20 22:20:44 UTC
Created attachment 683937 [details]
os-prober output

Comment 4 Jason Antman 2013-01-20 22:21:06 UTC
Created attachment 683938 [details]
os-prober stderr

Comment 5 Jason Antman 2013-01-20 22:21:31 UTC
Created attachment 683939 [details]
os-prober syslog

Comment 6 Hedayat Vatankhah 2013-01-22 16:54:02 UTC
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.

Comment 7 Hedayat Vatankhah 2013-01-22 17:01:48 UTC
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.

Comment 8 Chris Murphy 2013-07-10 19:02:59 UTC
*** Bug 903937 has been marked as a duplicate of this bug. ***

Comment 9 Chris Murphy 2013-07-10 19:16:18 UTC
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.

Comment 10 David Woodhouse 2013-09-27 21:05:38 UTC
Still broken in Fedora 19...

Comment 11 David Woodhouse 2013-09-27 22:19:26 UTC
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

Comment 12 Chris Murphy 2013-09-27 23:10:08 UTC
(In reply to David Woodhouse from comment #11)
I think you need to use the multiboot command instead of chainloader.

Comment 13 Sean 2014-01-19 22:40:15 UTC
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?

Comment 14 Sean 2014-01-19 23:08:55 UTC
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.

Comment 15 Mads Kiilerich 2014-01-19 23:16:40 UTC
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.

Comment 16 Chris Murphy 2014-01-20 19:10:04 UTC
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

Comment 17 Mads Kiilerich 2014-01-20 19:46:09 UTC
FWIW, BIOS chainload is also frowned upon upstream.

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

Comment 18 Chris Murphy 2014-01-20 21:59:34 UTC
(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.

Comment 19 Eelco Hoekema 2014-12-15 14:30:53 UTC
I am afraid this is still broken in Fedora 21 Workstation. (Macbook 5.1)

Comment 20 Chris Murphy 2014-12-15 18:57:02 UTC
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.

Comment 21 Chris Murphy 2014-12-15 19:02:57 UTC
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.

Comment 22 Bastien Nocera 2015-05-21 07:29:02 UTC
Still relevant in F22. It certainly confused a user I installed Fedora for, as well as me.

Comment 23 spital 2015-06-23 18:50:25 UTC
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.

Comment 24 Brian Lane 2015-06-24 15:51:39 UTC
*** Bug 904668 has been marked as a duplicate of this bug. ***

Comment 25 Jan Kurik 2015-07-15 14:53:41 UTC
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

Comment 26 Bastien Nocera 2016-06-20 09:35:03 UTC
Is this going to be fixed in time for F24?

Comment 27 Christian Kellner 2016-08-27 18:54:14 UTC
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
}

Comment 28 Chris Murphy 2016-08-28 00:15:25 UTC
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.

Comment 29 Chris Murphy 2016-08-28 00:19:59 UTC
Sorry, that URL is not related to this issue. I can't find the upstream bug.

Comment 30 Kevin Fenzi 2017-02-19 19:23:04 UTC
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)?

Comment 31 Chris Murphy 2017-02-19 22:08:26 UTC
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.

Comment 32 Kamil Páral 2017-02-20 15:27:03 UTC
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.

Comment 33 Fedora End Of Life 2017-02-28 09:33:09 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 34 Jan Kurik 2017-03-23 16:15:56 UTC
This bug is tracked as Prioritized Bug: https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues

Comment 35 Jan Kurik 2017-05-04 08:03:05 UTC
Hi Alberto,

may someone from your team look at this bug please ?

Thanks,
Jan

Comment 36 Alberto Ruiz 2017-05-04 14:24:41 UTC
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.

Comment 37 Chris Murphy 2017-05-04 14:58:09 UTC
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).

Comment 38 Alberto Ruiz 2017-05-04 15:18:10 UTC
(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.

Comment 39 Peter Jones 2017-05-24 14:37:26 UTC
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/.

Comment 40 Christian Kellner 2017-05-24 14:40:12 UTC
--- 8< ---
# os-prober
/dev/sda4:Mac OS X:MacOSX:macosx
--- >8 ---

Good enough?

Comment 41 Kevin Fenzi 2017-05-24 14:48:52 UTC
Yeah, I get: 

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

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

Comment 42 Jan Kurik 2017-05-25 08:37:01 UTC
This bug is removed from the list of prioritized bugs as it hits just minority of users.

Comment 43 Kamil Páral 2017-05-31 08:30:11 UTC
> # os-prober
> /dev/sda4:Mac OS X:MacOSX:macosx

The same output here.

Comment 44 Bastien Nocera 2017-05-31 14:58:27 UTC
(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.

Comment 45 Chris Murphy 2017-05-31 16:31:02 UTC
(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.

Comment 46 Lukas Brabec 2018-04-03 09:49:00 UTC
I was able to boot both Fedora and MacOS from grub, tested with F27 and F28 Beta 1.3


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