Slashdot

The goal is to be able to natively boot 4 Operating Systems on my laptop, a first-generation MacBook Pro 15.4". These notes detail how I succeeded or failed.

My short-term goal is to run the following OSes:

1. Mac OS 10.4 -- Tiger
2. Windows XP
3. Windows Vista
4. Linux

My medium-term goal is to run the following OSes:

1. Mac OS 10.4 -- Tiger
2. Mac OS 10.5 -- Leopard
3. Windows Vista
4. Linux

Long-term, I'd like to have a triple-boot system with Leopard, Vista and Linux plus a partition that allows me to experiment with any 4th OS of my choice.

[Before starting]

I currently run a dualboot Bootcamp system with MacOS 10.4 Tiger and Windows XP. I have acquired a TOSHIBA MK2035GSS SATA drive of 200 Gigabits (186.3 GB of usable space), which is connected via external USB. Both Tiger and XP are installed into their own partition on the internal drive. I plan to clone them over to the external USB drive, then open up the MacBook Pro case and switch the hard drives. After that, I'll tackle the Vista and Linux installation.
The 200 Gb hard drive is currently connected to the laptop. The laptop is running under MacOS 10.4 Tiger.

[MacOS 10.4 Tiger]

I launched DiskUtil, selected the external USB drive and created 7 partitions. This is done by selecting "7 Partitions" in the drop-down menu under the UI label "Volume Scheme". The 7 partitions are ("name" size - format):

1. "TigerGPT" 32GB - MacOS Extended (Journaled)
2. "LeopardGPT" 32GB - MacOS Extended (Journaled)
3. "XPGPT" 32GB - MS-DOS File System
4. "VISTAGPT" 32GB - MS-DOS File System
5. "FATGPT" 32GB - MS-DOS File System: I plan to use this has a read/write area between all operating systems
6. "SwapGPT" 2GB - UNIX File System
7. "LinuxGPT" 26.12GB - UNIX File System

In order to create the GPT scheme, click on "Options..." and select "GUID Partition Table". Then click "OK".
To commit this change to disk layout, click "Partition".

Since Windows XP and Vista 32bit can not run with a GPT layout on the hard drive, we need to add a dual MBR layout next to the GPT layout that we have created. Fortunately, both layout definitions can coexist on the same hard drive, each independently defining the list of partitions it cares about.
Obviously, if the two partition layouts don't agree about the boundary of each partition, we will soon run into problems. That's why it is important to keep the two layouts in synch.

Dropping down at the command line-level, we can see the new layout of the external drive by typing

diskutil list /dev/disk1

(assuming the external drive has been identified as "disk1").

/dev/disk1
#: type name size identifier
0: GUID_partition_scheme *186.3 GB disk1
1: EFI 200.0 MB disk1s1
2: Apple_HFS TigerGPT 31.9 GB disk1s2
3: Apple_HFS LeopardGPT 31.9 GB disk1s3
4: Microsoft Basic Data XPGPT 32.0 GB disk1s4
5: Microsoft Basic Data VISTAGPT 32.0 GB disk1s5
6: Microsoft Basic Data FATGPT 32.0 GB disk1s6
7: Apple_UFS SwapGPT 1.9 GB disk1s7
8: Apple_UFS LinuxGPT 24.0 GB disk1s8

It is interesting to note that there is an unnamed partition of type "EFI" and of size 200.0MB that has been created at the beginning of the drive by DiskUtil (with identifier disk1s1). It is because we chose "GUID Partition Table" as option.
The SwapGPT partition is actually not absolutely necessary. It will be used as a swap partition, but we could also use a swap file inside the Linux partition instead. It is a matter of taste.

For reference, the output of

gpt show /dev/rdisk1

is as follows:

gpt show: /dev/rdisk1: Suspicious MBR at sector 0
start size index contents
0 1 MBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
409640 66846720 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
67256360 262144
67518504 66846720 3 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
134365224 262144
134627368 67108864 4 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
201736232 67108864 5 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
268845096 67108864 6 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
335953960 3932160 7 GPT part - 55465300-0000-11AA-AA11-00306543ECAC
339886120 262144
340148264 50311520 8 GPT part - 55465300-0000-11AA-AA11-00306543ECAC
390459784 262151
390721935 32 Sec GPT table
390721967 1 Sec GPT header

The index block start of each partition and the block count are displayed. If we could just load those numbers into a Linux fdisk utility, we could easily synchronize GPT and MBR on the external disk.

Note: It is interesting to see the couple of 128MB partition (262144 blocks of the standard-size 512 bytes) that have been added, one for each MacOS journaled partition, and one for each Linux partition. I have no idea why that is. To keep the journal, maybe? Anyway, it won't impact us.

Now we need to focus on the MBR story and on cloning Windows. To do so, still within MacOS, we will have a look at the fdisk utility. At this tage, running the command line

fdisk -e /dev/rdisk1

displays the following information once we type print at the interactive prompt.

fdisk: could not open MBR file /usr/standalone/i386/boot0: No such file or directory
Enter 'help' for information
fdisk: 1> print
Disk: /dev/rdisk1 geometry: 24321/255/63 [390721968 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] <Unknown ID>
2: AF 1023 254 63 - 1023 254 63 [ 409640 - 66846720] HFS+
3: AF 1023 254 63 - 1023 254 63 [ 67518504 - 66846720] HFS+
4: 0B 1023 254 63 - 1023 254 63 [ 134627368 - 67108864] Win95 FAT-32

It is interesting to note that the MBR information is not empty. On the contrary, it has been smartly initialized by MacOS to include the 4 first meaningful partitions of the disk. This includes the 200.0MB unnammed EFI partition at the beginning of the disk, the two MacOS Extended partitions (TigerGPT and LeopardGPT) and the first Windows partition (XPGPT). The two small 128MB partitions of 262144 blocks that follow the HFS+ partitions have been literally skipped by the default MacOS synch behavior between GPT and MBR.

By choosing only 4 partitions, the default synch behavior allows to surface 4 GPT partitions as 4 primary partitions into the MBR world, in a simple and effective way, without worrying about extended partitionning and all. This is probably a wise decision.
The choice of the 4 partitions is however not ideal. In our case, it would have been much more interesting to surface XPGPT, VISTAGPT, FATGPT and LinuxGPT instead. Now that we have the start index and the size of each partition, we could easily setup the MBR info to include the 4 partitions that we like best using fdisk.
This is however not a great idea because, even if the disk contains a GPT layout, MacOS first looks for an MBR one and verifies that the type or 'id' of the partition is EE -- that is Unknown ID. This means that we have used the hidden EE EFI partition as our primary partition #1 in the MBR. This further implies that, if we want to see the 4 partitions XPGPT, VISTAGPT, FATGPT and LinuxGPT, then XPGPT will be primary partition #2, VISTAGPT will be primary partition #3 and we need to create partition #4 as an extended partition in order to put FATGPT and LinuxGPT in there. That is what we will do, and we will throw in the SwapGPT partition in as well.

First, at the fdisk prompt, we must type

erase

Then, edit 2 and follow through with the wizard. We enter the values that were displayed by gpt for the first Windows partition (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) that we are interested in. The same is done with edit 3 for the second Windows partiton. Then for the next partition, we will create an extended partition via edit 4. Then we need to type select 4 to add a new MBR inside that extended partition. And again edit 1 and edit 2. This first extended partition will contain FATGPT, plus another extended partition. Type select 2 to enter this nes extended partition and initialize it with a fresh MBR. This new extended partition will contain the SwapGPT partition. And another extended partition. That last extended partition will contain the LinuxGPT partition.
At the end of the process, typing

fdisk /dev/rdisk1

shows the following information

Disk: /dev/rdisk1 geometry: 24321/255/63 [390721968 sectors]
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: EE 1023 254 63 - 1023 254 63 [ 1 - 409639] <Unknown ID>
2: 07 1023 254 63 - 1023 254 63 [ 134627368 - 67108864] HPFS/QNX/AUX
3: 07 1023 254 63 - 1023 254 63 [ 201736232 - 67108864] HPFS/QNX/AUX
4: 05 1023 254 63 - 1023 254 63 [ 268845096 - 121614688] Extended DOS
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: 0B 1023 254 63 - 1023 254 63 [ 268845159 - 67108738] Win95 FAT-32
2: 05 1023 254 63 - 1023 254 63 [ 335953897 - 54505887] Extended DOS
3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: 82 1023 254 63 - 1023 254 63 [ 335953960 - 3932160] Linux swap
2: 05 1023 254 63 - 1023 254 63 [ 340148264 - 50311520] Extended DOS
3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: 83 1023 254 63 - 1023 254 63 [ 340148327 - 50311457] Linux files*
2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused

Since we have fdisk at hand, we used it to also set a more fine-grained partition type for each partition: twice 07 for NTFS, 05 for extended, 0B for FAT32, 82 for Linux Swap and 83 for Linux.

The FATGPT information that is stored in the GPT table contains the following inacurate information:

268845096 67108864 6 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

The MBR data for the same partition says the following correct information:

1: 0B 1023 254 63 - 1023 254 63 [ 268845159 - 67108738] Win95 FAT-32

We can correct the GPT information the following way:

# gpt remove -b 268845096 /dev/rdisk1
gpt remove: /dev/rdisk1: Suspicious MBR at sector 0
gpt remove: /dev/rdisk1: 1 partition(s) removed

# gpt add -b 268845159 -s 67108738 -i 6 -t windows /dev/rdisk1
gpt add: /dev/rdisk1: Suspicious MBR at sector 0

If we look now at the output from

gpt show /dev/rdisk1

, we can see that the FAT-32 partition now has the same size and the same starting block in GPT and in MBR. Note also the two 63-block partitions before and after it. Those are two of the extended partitions.

gpt show: /dev/rdisk1: Suspicious MBR at sector 0
start size index contents
0 1 MBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
409640 66846720 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
67256360 262144
67518504 66846720 3 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
134365224 262144
134627368 67108864 4 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
201736232 67108864 5 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
268845096 63
268845159 67108738 6 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
335953897 63
335953960 3932160 7 GPT part - 55465300-0000-11AA-AA11-00306543ECAC
339886120 262144 4
340148264 50311520 8 GPT part - 55465300-0000-11AA-AA11-00306543ECAC
390459784 262151
390721935 32 Sec GPT table
390721967 1 Sec GPT header

The same can be done with the LinuxGPT partition:

# gpt remove -b 340148264 /dev/rdisk1
gpt remove: /dev/rdisk1: Suspicious MBR at sector 0
gpt remove: /dev/rdisk1: 1 partition(s) removed

# gpt add -b 340148327 -s 50311457 -i 8 -t 55465300-0000-11AA-AA11-00306543ECAC /dev/rdisk1
gpt add: /dev/rdisk1: Suspicious MBR at sector 0

Looking at the output of diskutil list /dev/disk1, we now see that the two partitions that we have resized have lost their name.

/dev/disk1
#: type name size identifier
0: GUID_partition_scheme *186.3 GB disk1
1: EFI 200.0 MB disk1s1
2: Apple_HFS TigerGPT 31.9 GB disk1s2
3: Apple_HFS LeopardGPT 31.9 GB disk1s3
4: Microsoft Basic Data XPGPT 32.0 GB disk1s4
5: Microsoft Basic Data VISTAGPT 32.0 GB disk1s5
6: Microsoft Basic Data 32.0 GB disk1s6
7: Apple_UFS SwapGPT 1.9 GB disk1s7
8: Apple_UFS 24.0 GB disk1s8

This is disk1s6 and disk1s8. As such, they are not mounted by MacOS anymore. Well, for disk1s8, it is not so much of a problem because it will contain a Linux distribution, and we don't necessarily want MacOS to peak into it. But for disk1s6 -- which used to be called FATGPT --, it is a problem because it is the partition that will be used by all operating systems to exchange files together. Hopefully, we will be able to fix that once we reboot under Windows.

Now that we have the GPT and MBR info in synch, we can boot into Windows.

Let's reboot into MacOS and see if Windows played nice with our existing MBR table.

[MacOS 10.4 Tiger]
Everything seems to be OK. The tables have been unchanged, the NTFS partitions are readable from within MacOS. And the FATMBR partition name that was reassigned when formatting the unnammed FAT32 partition was succesfully propagated. The output of

diskutil list /dev/disk1

shows the following output:

/dev/disk1
#: type name size identifier
0: GUID_partition_scheme *186.3 GB disk1
1: EFI 200.0 MB disk1s1
2: Apple_HFS TigerGPT 31.9 GB disk1s2
3: Apple_HFS LeopardGPT 31.9 GB disk1s3
4: Microsoft Basic Data XPGPT 32.0 GB disk1s4
5: Microsoft Basic Data VISTAGPT 32.0 GB disk1s5
6: Microsoft Basic Data FATMBR 32.0 GB disk1s6
7: Apple_UFS SwapGPT 1.9 GB disk1s7
8: Apple_UFS 24.0 GB disk1s8

Now, let's go back to Windows and try to clone the XP partition from the internal hard drive into XPGPT on the external gard drive.

[Windows XP]
To clone Windows XP from one partition to another, I used a commercial tool that I acquired with my external hard drive case called Apricorn EZ Gig II. I am not specially impressed by this tool, so I can not really recommend it. I guess there are many other tools that can do the same thing as Apricorn EZ Gig II does, and even improve on the screwing up of the partitions.

[MacOS 10.4 Tiger]
Rebooting into MacOS after Apricorn has finished cloning Windows XP on the external hard drive, I can fully appreciate the extend of the damage. Of course, Windows XP and Apricorn could not possibly edit the GPT data since then know nothing about that format. But the MBR table is another story, as the following fdisk /dev/rdisk1 output shows:

Disk: /dev/rdisk1 geometry: 24321/255/63 [390721968 sectors]
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
*1: EE 1023 254 63 - 1023 254 63 [ 1 - 409639] <Unknown ID>
2: 07 1023 0 1 - 1023 254 63 [ 134624700 - 67103505] HPFS/QNX/AUX
3: 07 1023 254 63 - 1023 254 63 [ 201736232 - 67108864] HPFS/QNX/AUX
4: 0F 1023 212 31 - 1023 254 22 [ 268845096 - 121614688] Extended LBA
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: 0B 1023 254 63 - 1023 254 63 [ 268845159 - 67108738] Win95 FAT-32
2: 05 1023 254 63 - 1023 254 63 [ 335953897 - 54505887] Extended DOS
3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: 82 1023 254 63 - 1023 254 63 [ 335953960 - 3932160] Linux swap
2: 05 1023 254 63 - 1023 254 63 [ 340148264 - 50311520] Extended DOS
3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: 83 1023 254 63 - 1023 254 63 [ 340148327 - 50311457] Linux files*
2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused

The partitionning actually changed the size and the block start value of the XPGPT partition. It reads now

2: 07 1023 0 1 - 1023 254 63 [ 134624700 - 67103505] HPFS/QNX/AUX

instead of the previous info, which was:

2: 07 1023 254 63 - 1023 254 63 [ 134627368 - 67108864] HPFS/QNX/AUX

The partition is basically shorter: 67,103,505 blocks vs 67,108,864. And it starts earlier on the disk: at block number 134,624,700 instead of 134,627,368. That's 2668 blocks too early!

The EFI partition has been flaged has bootable (the * tag). And something is funky about cyl hd sec which reads now 1023 0 1 instead of the former 1023 254 63. But I don't understand that part, so I will not comment.

I however have some good expertise about findling with Windows. And something is certain: if Windows is happy with its MBR layout, don't play with it. So I won't play with it anymore. Instead I will once again align the GPT table info to mirror the new MBR content. This means that I have to shorten the size of the XPGPT partition in the GPT table. I also have to move it 2668 block forward on the disk.

Moving the XPGPT partition 2668 block forward would typically be impossible because there is another partition that is using that space already. However, in our case, we actually have 262144 (128MB) of empty space there that were left out after the creation of the HFS+ partitions. Great, let's make good use of it! First, we delete the XPGPT partition. Then we recreate it with the new size and block start information.