Bug 982847
| Summary: | os-prober should indicate that grub should chainload the OS X bootloader | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Chris Murphy <bugzilla> |
| Component: | os-prober | Assignee: | Hedayat Vatankhah <hedayatv> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | dwmw2, hedayatv, mjg59 |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-11-23 09:08:21 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Chris Murphy
2013-07-10 02:52:23 UTC
I wonder if this is something that should be fixed in os-prober. os-prober is just an OS Prober. It doesn't tell grub how to boot the OS. I think grub2 should know how to boot OS X (in the scripts which parse os-prober's output). Is there any information about the OS which is not provided by os-prober? To fox rather than suppress: os-prober needs to recognize the mactel-boot created ESP isn't a genuine OS X installation, so prevent bogus entries from being added to grub.cfg. grub-mkconfig needs to be modified to chainload Apple's boot.efi instead of using grub's (non-working) boot loader module for xnu. Aside: Apple appears to change how xnu loads in every release, and I think the last time the grub2 xnu module could boot OS X was 10.5 or at best 10.6. That's 4+ years ago. The two current releases 10.7 and 10.8 (release 2 years and 1 year ago respectively) kp with grub's xnu bootloader. So maybe this is better taken up with grub2 upstream again, and propose either fixing and maintaining the xnu module, or chainloading the Apple one? Can either of you think of an advantage of using grub's xnu bootloader rather than chainloading Apple's? Since I don't have access to any Macs, would you please give the output of os-prober in such a system, and what is the expected output? :P Also, what is the difference between mactel-boot created ESP and genuine OS X installation? (In reply to Hedayat Vatankhah from comment #3) > Since I don't have access to any Macs, would you please give the output of > os-prober in such a system, and what is the expected output? :P If you have a specific command for os-prober output you'd like to see, let me know. Otherwise I'll do a bash -x on grub2-mkconfig with os-prober not suppressed in /etc/default/grub and you can see the whole interaction. > Also, what is the difference between mactel-boot created ESP and genuine OS > X installation? OS X itself doesn't use an EFI System partition. But its Disk Utility, when formatting any disk as GPT, creates a conventional FAT32 ESP. So far, this ESP is only used for staging firmware updates supplied by Apple. It's not used for booting. However, the firmware startup disk manager won't list boot loaders on an FAT32 ESP located on non-removable media. So the mactel-boot ESP is hfs+ and also contains grub.efi renamed as /System/Library/CoreServices/boot.efi which is identical to how the OS X bootloader is named/located. That way the firmware is tricked into thinking it's the OS X bootloader, therefore it's displayed as a boot option both by the firmware's startup manager as well as the OS X System Preferences Startup disk panel. And I'm leaving out a lot of details. But this is likely why os-prober thinks the mactel-boot ESP contains a bootable OS X instance. Actually bash -x on grub2-mkconfig doesn't reveal what's going on in /etc/grub.d/30_os-prober which contains a lot of OS X specific code, including xnu sleep/resume code. What I get for os-prober is: [root@f19s ~]# os-prober /dev/sda2:Mac OS X:MacOSX:macosx /dev/sda4:Mac OS X:MacOSX1:macosx sda2 is a legit install, and sda4 is the mactel-boot produced ESP. I get two entries for each (a 32bit and 64bit option). I guess that distinction is one advantage to grub's xnu bootloader, for some time the 64bit kernel is used by default by Apple, however there's little use case now for 32bit xnu since vendors have long updated their kexts to 64bit. Thank you for the description, and the output. Now, the problem is how os-prober can detect an ESP compared to a real OSX installation? All that might be fixed in os-prober is to remove the non-real entry (the second line in your output). All the rest (e.g. chainloading) should be fixed in grub2 and is not related to os-prober. So, no working OSX entry is actually a grub2 bug. os-prober bug is detecting mactel-boot ESP. The first bug is the same as bug #893179. The second is new, and I need help for fixing it (or it should be fixed in os-prober upstream!). This bug was mainly about punting by removing the bogus entries by disabling os-prober on Apple installs. It's sort of a brut force hammer (other installed linux systems would also not be found as a result). But if the idea is to actually fix the existing bugs, then I'm fine with closing this one and filing the various aspects of this bug with their proper counterparts. This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20 Well, if you want proposing disabling os-prober you should probably open a report against anaconda. But, I'd suggest creating reports for each problem separately to help solving the problem. Personally, I think creating working entries AND non-working entries is better than not creating any entries. I'd be glad to help detecting ESP. |