Fixing MBR Tables on iMac or MBP Triple Boot Setups

转自 http://jonsview.com/fixing-mbr-tables-on-imac-or-mbp-triple-boot-setups

 

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 Problem

You have already gone through the motions of creating or 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.

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!