Red Hat Bugzilla – Bug 746901
Apple computers require MBR (full or 'hybrid', not protective) to boot Fedora in CSM mode
Last modified: 2013-01-06 14:28:35 EST
Description of problem:
Apple Intel-based computers require an MBR (full or hybrid), with an appropriate partition entry in the MBR with a boot flag enabled, in order to activate CSM based boot. Problem occurs either with standalone installation of Fedora, or Fedora installed in free space on a disk with preexisting Mac OS X installation.
This bug does not apply to EFI booting of Fedora.
Version-Release number of selected component (if applicable):
Problem occurs with both of these install images:
Steps to Reproduce:
1. Boot either LiveCD or Install DVD with Apple EFI CSM (hold option key at startup, and ensure the CD/DVD icon labled "Windows" is selected).
2. For standalone, installation type "Use All Space". For dual-boot, installation type "Use Free Space".
3. After successful installation, reboot, holding down option-key to bring up the startup disk selection menu.
There is no hard disk icon labeled "Windows" and no means of booting Fedora, by default. Cause appears to be due to Apple's EFI startup disk menu looking for three thing before it will present the disk option that will enable CSM based boot, and loading Grub2.
Upon startup with the option key held down, I expect to see a hard disk icon labeled "Windows" in the Apple EFI startup disk menu. This icon effectively means "boot into Grub2", and if chosen I will end up at a Grub menu.
Apple's EFI startup disk menu appears to look on all disks for the following conditions, before it will present any disk icon as a choice for CSM booting:
a. Full MBR or hybrid MBR. (i.e. a protective MBR only, meaning a single type EE partition entry in the MBR is insufficient).
b. One partition, which is not the "EE" protective partition, must have the boot flag enabled.
c. The first 440 bytes of the disk must contain a bootloader code. (At least, if a. and b. are true, and the first 440 bytes are zero'd, the startup disk menu doesn't show a disk representing an option to boot Fedora.)
This probably means using something like gptsync at some point after parted's partitioning, and formatting the partitions.
Fedora 16 uses Grub2 for CSM based booting, so I'm referring to Grub2. The same three rules apply to Grub Legacy so this is not a Grub/Grub2 issue.
It is *critical* to note that merely setting the boot flag on a one partition MBR, the type "EE" protective MBR entry, will cause both Mac OS and Fedora to be missing from the startup disk menu and unbeatable.
There could be other Apple computer models with different behaviors. This is reproducible on Macbook Pro 4,1 and Macbook Pro 8,2. It's also possible there are other non-Apple computers who's EFI or BIOS expect to see an MBR with a boot flagged partition to boot from.
Test case for "fixing" a Fedora installation manually:
1. Starting with a single disk, repartition with Apple Disk Utility specifying two partitions. One jhfs+ and the other will be set to Free Space.
2. Install Mac OS X.
3. Boot from a Fedora LiveCD or Install DVD and choose installation type "Use Free Space"
4. Reboot with option key held down.
[result at this point will be only one disk icon, representing the partition containing Mac OS X, as an installation choice; maybe a CD/DVD icon as well if the Fedora install disk hasn't been removed.]
5. Reboot from LiveCD or DVD in rescue mode.
6. At command line as root, yum install gdisk.
p [print GPT partition, should result in something like this:]
1 EFI System
2 Mac OS X
3 BIOS Boot
4 linux boot
5 linux lvm
r [recovery and transformation menu]
h [create new hybrid MBR}
5 [specify linux lvm to be added to the MBR]*
y [yes to place EFI partition first in protective MBR)
accept default code [self explanatory]
Y [yes to set bootable flag for this partition]*
n [no to protecting more partitions]
w [write changes to partitions]
y [confirm write changes]
[automatic exit from gdisk]
At this point fdisk can be used to confirm the state of the MBR, which will show the first partition is the protective MBR containing sectors for the GPT, EFI, and Mac OS partitions. And the 2nd MBR partition will be the linux lvm, and it will have a boot flag set. So long as grub2 was successfully installed, all three requirements are now met.
reboot while holding option key
RESULT: A "Windows" disk appears and if selected and booted from, will produce the Grub2 menu.
* I am adding the lvm because it's last in the list, and GPT partitions 1-4 all end up in the 1st MBR partition (type EE, the protective MBR). Other combinations are possible and work, but this one seems the safest and least cluttered.
Same thing here on a Mac Mini. I have managed to install F16 as standalone, but the suggested fix seems to only work if you use the LVM partition layout. At the end of the process, I ended up with 3 partitions (as listed by gdisk): 1. BIOS boot, 2. Linux boot (/boot) and 3. Linux LVM.
After finishing installation from LiveCD, before I rebooted, I´ve entered gdisk and issued the recovery menu and then created new hybrid MBR, adding to it only the 3. Linux LVM partition. Then, I could reboot with no problem and the grub menu was working just fine.
(In reply to comment #1)
> Same thing here on a Mac Mini. I have managed to install F16 as standalone, but
> the suggested fix seems to only work if you use the LVM partition layout.
No, as I wrote: "I am adding the lvm because it's last in the list, and GPT partitions 1-4 all
end up in the 1st MBR partition (type EE, the protective MBR). Other
combinations are possible and work..."
If you're not using LVM that's fine. I'd still suggest the last partition be the only one to go into the MBR as partition 2. That last partition if you don't use LVM is probably linux root. All of the other GPT partitions get stuffed into the protective MBR as partition 1, hex code 0xEE.
I can confirm that the gdisk workaround as described in the initial report worked for me. I had the same partition layout.
(It is frustrating though, that for a number of Fedora releases in a row, the Macbook dual boot scenario has failed out of the box.)
*** Bug 503149 has been marked as a duplicate of this bug. ***
Fedora Bugzappers volunteer triage team
It seems to me we kind of have multiple scenarios to consider here, assuming we want to 'support' installing to Macs via CSM at all:
1. User has a Mac with OS X on it. They download a Fedora install image and run it. They don't know anything about Boot Camp, they haven't do any Boot Camp prep. They expect to install Fedora alongside OS X. Assuming we're in CSM mode for the nonce (I'm not sure if this is true, but let's assume it), for dual-boot to work, Fedora is going to have to understand how to create a hybrid MBR that OS X will be happy with, right?
2. User has a Mac with OS X on it, and tries to use Boot Camp to prepare a hybrid MBR and partitions for Fedora before installing it. Is this ever going to work, or can Boot Camp only really handle creating a hybrid MBR and partitions for *Windows*?
3. User tries to do a complete wipe of OS X and install Fedora as the only OS. In this case 'all' we need to do is create a conventional MBR rather than use GPT, right - so for this scenario, on F16, all you need to do is pass 'nogpt'?
Fedora Bugzappers volunteer triage team
(In reply to comment #6)
1: Correct. However you have an earlier problem which is resizing the existing file system to make room for Fedora. Boot Camp is the only included GUI means for resizing an existing jhfs+ volume and creating "free space" which is actually formatted FAT32.
2. Boot Camp helps resize an existing jhfs+ volume so that there is at least space for a Fedora installation. This is the first step in Boot Camp. Subsequent steps involve downloading Windows only drivers, and doing initial installation work. But as the resulting "free space" is FAT32, presently anaconda won't do an automatic partitioning to use a FAT32 partition that otherwise doesn't contain anything. It would be nice if 'Free Space' installation type would use FAT32 if there's nothing on it. Or ask.
Further, in every case so far I've seen parted get involved, it blows away the hybrid MBR leaving only a protective MBR.
3. Correct. I have done this, and at least Fedora installs. But I never kept it around long enough to see how well the resulting system works. An unanswered question I have with this scenario is the consequence of not having the Firmware.scap file present on the EFI system partition. I do not know if this is used by Apple's CSM or what. This is a 15MB file, which only becomes present on the EFI System partition if Mac OS X is installed, and connected to the internet, and there is a first user login. If those three things aren't true, the file is not downloaded. If they are true, it is silently downloaded without user being informed.
chris: right, for the disk space thing, if we wanted to make it work without previous configuration, we might want to support jhfs+ resizing (if possible) and/or recognize the fingerprints of a 'post-bootcamp' layout and blow away the FAT32 partition.
Fedora Bugzappers volunteer triage team
Still a problem with Fedora-17-Nightly-20120307.09-x86_64-Live-kde.iso and CSM-BIOS mode boot method. Resulting installation will not boot Fedora without manual post-install creation of hybrid MBR.
Closing this as not a bug. Supporting CSM and hybrid MBRs is perilous. EFI work on GRUB2 and the mactel boot package obviates this bug.