Fixing MBR Tables on iMac or MBP Triple Boot Setups

November 6, 2011 · 68 comments

I spent several hours today struggling to fix my iMac triple boot setup with Mac OS X Lion, Windows 7 x64, are Ubuntu 11.10. rEFIt does not handle the new Apple Boot partition included in the latest release of Apple’s operating system. This article provides an example of how to fix your MBR table manually without using the rEFIt partition sync tool.

This is not a triple boot setup guide. I’m providing this information here for any of those poor souls who are also struggling with this problem and looking for a solution.

The Scenario and Problem

You have already gone through the motions of creating a triple boot setup. For example, you’re running Mac OS X Lion,  had installed rEFIt, installed Windows 7 x64, and installed Ubuntu 11.10. However, when the rEFIt menu appears, selecting Linux boots Windows. Selecting Windows also boot Windows. Selecting Mac OS X boots Mac.

If this sounds like the problem you’re having, then read on.

The Cause

You’ve followed all of the triple boot instructions that you can find online. For example, you’ve made sure to install the grub boot loader on the Linux partition rather than on the master boot record (MBR). Everything seems like it should work, but it doesn’t. Only stubborn old Ubuntu [or some other Linux distro] refuses to boot.

From what I can tell, the problem lies with rEFIt in combination with Mac OS Lion. Mac OS X 10.7 adds a new Apple boot partition. If you use the rEFIt partition sync tool, it may place this partition in your MBR table. Since the MBR table can only have 4 partitions in this implementation, that means that one of your other operating systems doesn’t make the cut. In my case, this was Ubuntu.

The Solution

The solution is to fix the MBR table yourself without rEFIt, since rEFIt doesn’t handle this new development. The guide that follows only serves as an example. Your case will likely differ, so read through this for the general process and make adjustments where you need.

  • Boot into Mac OS X
  • Run the Partition Inspector application. This application is normally installed with rEFIt in /Applications/Utiltities.
  • Launch terminal
  • Run the following command to find out what disk# you should be using: diskutil list [hint: it'll be all the one with your operating system partitions on it, usually disk0].
  • Run the following command making any substitutions for disk number in your case: sudo fdisk -e /dev/disk0.

Upon running the fdisk command, it might complain at you and perhaps give you an error message that looks something similar to fdisk: could not open MBR file /usr/standalone/i386/boot0: No such file or directory. Just ignore that message. What’s important is that you should now be at the fdisk prompt which looks something along the lines of fdisk: 1 >

At this prompt enter print and you should get a readout somewhat like the following:

1
2
3
4
5
6
7
8
9
10
fdisk: 1 > print
Disk: /dev/disk0 geometry: 121601/255/63 [1953525168 sectors]
Offset: 0 Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: EE 1023 254 63 - 1023 254 63 [ 1 - 39]
2: 0B 1023 254 63 - 1023 254 63 [ 40 - 409600] Win95 FAT-32
*3: AF 1023 254 63 - 1023 254 63 [ 409640 - 1763671872] HFS+
4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused

Now begins the fun. You need to update this table with the correct information, write it, and then reboot. To help make this process more clear, below is example output generated from the Partition Inspector application in my particular case. You will need to reference this information as you update the MBR partition. This example is also the finished product with everything working, so you can use the information under “Current MBR partition table” as an example of what you’re trying to achieve in the end.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
*** Report for internal hard disk ***

Current GPT partition table:
# Start LBA End LBA Type
1 40 409639 EFI System (FAT)
2 409640 1764081511 Mac OS X HFS+
3 1764081512 1765351047 Mac OS X Boot
4 1765351424 1892032511 Basic Data
5 1892034560 1953523711 EFI System (FAT)

Current MBR partition table:
# A Start LBA End LBA Type
1 1 39 ee EFI Protective
2 * 1765351424 1892032511 07 NTFS/HPFS
3 409640 1764081511 af Mac OS X HFS+
4 1892034560 1953523711 83 Linux

MBR contents:
Boot Code: Unknown, but bootable

Partition at LBA 40:
Boot Code: None (Non-system disk message)
File System: FAT32
Listed in GPT as partition 1, type EFI System (FAT)

Partition at LBA 409640:
Boot Code: None
File System: HFS Extended (HFS+)
Listed in GPT as partition 2, type Mac OS X HFS+
Listed in MBR as partition 3, type af Mac OS X HFS+

Partition at LBA 1764081512:
Boot Code: None
File System: Unknown
Listed in GPT as partition 3, type Mac OS X Boot

Partition at LBA 1765351424:
Boot Code: Windows BOOTMGR (Vista)
File System: NTFS
Listed in GPT as partition 4, type Basic Data
Listed in MBR as partition 2, type 07 NTFS/HPFS, active

Partition at LBA 1892034560:
Boot Code: GRUB
File System: ext4
Listed in GPT as partition 5, type EFI System (FAT)
Listed in MBR as partition 4, type 83 Linux

Editing the partition table

This is an example of how the editing process will go based on my example scenario above.

We can cross reference the fdisk print report about the MBR and compare it to the GPT table. For example, in MBR slot #2 [in the fdisk print results above], it has a start of 40 and a size of 409600. This corresponds to the GPT entry “Partition at LBA 40.” This can also be found in the first group of results generated by the Partition inspector. This MBR entry #2 corresponds to GPT partition #1. It has a start of 40. You can calculate the end by subtracting 1 from the size. For example: 40 + 409600 – 1 = 409639 (the ending LBA).

In my case, MBR slot #4 is reportedly unused [in my case rEFIt reports this as the Apple Boot partition]. Comparing the MBR table to the GPT table we can see that the MBR table properly has my Mac partition, the EFI protection partition, and the Windows partition. So, I need to add my Ubuntu partition to the MBR table in slot #4.

Do not remove the “EFI Protective” partition from the MBR. According to the Myths page on the rEFIt Web site, this partition tells GRUB not to overwrite the GPT tables. Additionally, Curtis Shimamoto reports that the protective partition must start at LBA 1.

Referring to the Partition inspector, we can see that the “Partition at LBA 1892034560″ is the Ubuntu partition. This is because its boot code is “GRUB” and its filesystem is ext4. Those are some distinct GNU/Linux markers right there. Before heading back to fdisk though we need to do a quick bit of math. fdisk takes a start LBA, but it takes a size instead of an end LBA, so the size must be calculated. Fortunately, Partition inspector provides this information in the first grouping of results under “Current GPT Partition Table.” Take the end LBA and subtract the start LBA and add 1 to obtain your size. For example, 1953523711 - 1892034560 + 1 = 61489152.

Now that we have the information that we need, it’s time to go back to the terminal which should still be waiting at the fdisk prompt. Since I want to update MBR table slot #4, type in edit 4 The first thing it will probably say is Partition id ('0' to disable) [0 - FF]: [B] (? for help) ?. fdisk is asking for the partition type. If you enter “?” it will provide you with a list of all your options. In this case, for Linux, I’ll use “83″

If fdisk asks Do you wish to edit in CHS mode? say “n”.

fdisk will ask for the Partition offset. This is the starting LBA, so enter that. Remember that in my case it was 1892034560, but this is almost guaranteed to be different for you. The final question that fdisk will ask is for the size, so enter the previously calculated size.

Finally, write the MBR table with the write command. You will probably receive an error asking if it’s o.k. to make the changes after a reboot because the device could not be accessed exclusively. Say yes ["y"] and then quit with quit.

Repeat the process as necessary until your MBR table is completed.. If you’re only struggling with the new Apple boot partition taking up one of the MBR slots, then one pass similar to what I just did above should get the rEFIt triple boot menu back on track in and in working order.

Concluding Remarks

This is certainly an inelegant solution, but it’s a satisfactory workaround until the problem with the gptsync tool can be resolved. I have filed a bug report that can be tracked if you’re interested in following this issue: gptsync mishandles apple boot partition in Mac OS X Lion

Be Sociable, Share!

{ 63 comments… read them below or add one }

OldGregg March 24, 2014 at 10:12 pm

Hi Jon!

Awesome guide, very comprehensible and taught me a lot.
And yet there’s a huge problem:
I’m trying to achieve a triple boot with OSX Mavericks, OSX Snow Leo and WinXP.
As you state, the MBR can only have 4 entries/slots, plus the EFI Protective one should not be removed.
So I end up with my MBR being as this:

Partition Inspector:

*** Report for internal hard disk ***

Current GPT partition table:
# Start LBA End LBA Type
1 40 409639 EFI System (FAT)
2 409640 322059287 Mac OS X HFS+
3 322059288 323328831 Mac OS X Boot
4 323328832 360859647 Mac OS X HFS+
5 361121792 488396799 EFI System (FAT)

Current MBR partition table:
# A Start LBA End LBA Type
1 1 409639 ee EFI Protective
2 * 409640 322059287 af Mac OS X HFS+
3 322059288 323328831 ab Mac OS X Boot
4 323328832 360859647 af Mac OS X HFS+

MBR contents:
Boot Code: Unknown, but bootable

Partition at LBA 40:
Boot Code: None (Non-system disk message)
File System: FAT32
Listed in GPT as partition 1, type EFI System (FAT)

Partition at LBA 409640:
Boot Code: None
File System: HFS Extended (HFS+)
Listed in GPT as partition 2, type Mac OS X HFS+
Listed in MBR as partition 2, type af Mac OS X HFS+, active

Partition at LBA 322059288:
Boot Code: None
File System: HFS Extended (HFS+)
Listed in GPT as partition 3, type Mac OS X Boot
Listed in MBR as partition 3, type ab Mac OS X Boot

Partition at LBA 323328832:
Boot Code: None
File System: HFS Extended (HFS+)
Listed in GPT as partition 4, type Mac OS X HFS+
Listed in MBR as partition 4, type af Mac OS X HFS+

Partition at LBA 361121792:
Boot Code: Windows NTLDR
File System: NTFS
Listed in GPT as partition 5, type EFI System (FAT)

and fdisk printed this:

Disk: /dev/disk0 geometry: 30401/255/63 [488397168 sectors]
Offset: 0 Signature: 0xAA55
Starting Ending

#: id cyl hd sec – cyl hd sec [ start - size]

1: EE 1023 254 63 – 1023 254 63 [ 1 - 409639]
*2: AF 1023 254 63 – 1023 254 63 [ 409640 - 321649648] HFS+
3: AB 1023 254 63 – 1023 254 63 [ 322059288 - 1269544] Darwin Boot
4: AF 1023 254 63 – 1023 254 63 [ 323328832 - 37530816] HFS+

Please help me, how can I add the WinXP back to the MBR?
Or is it simply impossible to use those three OS on one harddrive?

Thank you SO so much in advance!

Yours OldGregg!

Reply

bazz February 11, 2014 at 10:16 pm

You are the man!! Thanks for this!

Reply

Wm Fiske January 15, 2014 at 12:57 pm

I had been trying to triple boot using Mavericks, Windows 8.1 Pro, and Windows 7. I was frustrated as I had triple booted my MacBook Pro in the past, but I was hitting my head against the wall on this one.

Your guide pushed me in the right direction.

I had 5 partitions listed using Partition Inspector and 4 of them were taken up in the MBR. In the MBR, OSX had 3 (EFI, OS, and Recovery), which had one left for Windows 8.

The fifth partition was Windows 7.

Since the MBR did not need a pointer for Recovery, I edited the MBR and overwrite the Recovery partition information with the Windows 8 info. I then overwrite the fourth entry with the Windows 7 partition info.

All is good now!

Reply

pmult January 12, 2014 at 4:54 am

/dev/disk0

: TYPE NAME SIZE IDENTIFIER

0: FDisk_partition_scheme *320.1 GB disk0
1: Apple_HFS 10.9 32.2 GB disk0s1

diskutil mergePartitions “Journaled HFS+” “Mac OS” disk0s1 disk0
“The given partitions are not ordered sequentially on disk”.

Reply

I love you January 10, 2014 at 11:07 pm

THANK YOU. I’ve put over a dozen hours into getting this to work. You are a saint for posting this online. You truly have made a difference in my life, I was on the edge of despair. Thank. You. So. Much.

Reply

Lars Holte June 15, 2013 at 11:27 am

I had been working on this for days before I found this guide. It solved my problem in minutes.

Thanks a bunch!

Reply

Leave a Comment

{ 5 trackbacks }

Previous post:

Next post: