Hi all,
I recently spent a whole day getting Parallels working with my triple-booted MacBook Pro. I found some good hints in this forum so I thought I'd post my discoveries to maybe save someone else some time. I'm using Parallels Desktop 3.0 build 5584.
My Mac has 3 partitions on its internal drive. The EFI partition table looks like this:
Code:
$ diskutil list
/dev/disk0
#: type name size identifier
0: GUID_partition_scheme *74.5 GB disk0
1: EFI 200.0 MB disk0s1
2: Apple_HFS Macintosh HD 44.0 GB disk0s2
3: EFI 10.0 GB disk0s3
4: Microsoft Basic Data NO NAME 20.2 GB disk0s4
So disk0s2 is the MacOS X partition, disk0s3 is linux (not recognised in Mac OS X), and disk0s4 is Windows. The first partition disk0s1 is EFI scratch space used when updating firmware, etc.
Since I can boot Windows, I must also have an MBR (Master Boot Record) partition table that must be kept in sync with the EFI one. The fdisk command shows it looks like this:
Code:
$ sudo fdisk /dev/rdisk0
Disk: /dev/rdisk0 geometry: 9729/255/63 [156301488 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: AF 1023 254 63 - 1023 254 63 [ 409640 - 92274688]
HFS+
3: 83 1023 254 63 - 1023 254 63 [ 92946472 - 20971520]
Linux files*
*4: 0C 1023 254 63 - 1023 254 63 [ 113917992 - 42383456]
Win95 FAT32L
As you can see they are in sync and I'm not going to lose any data when I boot into another operating system.
Notice the asterisk '*' before partition 4? That's very important as it marks the active partition. When a computer is booted using a BIOS loader, it will usually end up booting whatever operating system is on the active partition.
Now what happens when Parallels boots off a Boot Camp partition? Well its BIOS loads the MBR off the hard disk and jumps into its bootcode, like any BIOS loader! But to protect the rest of your disk it takes an extra step: whether it chooses the Boot Camp partition itself with 'Disk 0:0 image = Boot Camp' or you tell it explicitly which one to use with 'Disk 0:0 image = Boot Camp; disk0s4', it first edits the MBR in memory so that it only contains the partition you want to boot from. If you could run fdisk at boot time it would look like this:
Code:
#: id cyl hd sec - cyl hd sec [ start - size]
----------------------------------------------------------------
1: 0C 1023 254 63 - 1023 254 63 [ 113917992 - 42383456]
Win95 FAT32L
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
This is a fine approach to take, but did you notice anything missing? There is no asterisk there at all!
Parallels fails to mark the boot partition as active!
When most bootloaders encounter this situation, they give up and display a message like 'Operating system missing' or 'No bootable partition' or something like this. Which is exactly what happened to me, and took me so long to fix.
Now assuming you're reading this because you're having the same problem, there are three directions to take from here:
1. Lobby to get Parallels to improve their virtual boot process (see below)
2. Get a bootloader that will boot off a non-active partition
3. Fix it yourself
For Parallels developers: The best thing would be to have Parallels boot in a saner way. Ideally, there would be no editing of the MBR at all! Instead the Parallels BIOS itself could just load the 2nd-level bootloader from the partition it wants to boot, and jump right into it, skipping the MBR completely. It's possible some bootloaders would have a problem with this, but I doubt it. After all this is what the EFI bootloader rEFIt does. Alternatively, marking the active partition as active would be a quicker fix and ought to solve most problems.
When I figured out what the problem was, I first tried option 2 above, i.e. find a bootloader that didn't mind what Parallels was doing. After trying lilo and syslinux I gave up on this, and instead fixed it myself. I modified the syslinux bootloader to boot off the first partition if no active partitions were found. I now have a system that can triple-boot into Mac, Windows and Linux and from the Mac environment run either Windows or Linux in a virtual machine.
But if you don't feel up to modifying bootcode yourself (I sure never expected to be writing 16bit x86 assembler again 
and you encounter this bug then your best bet is to hassle the developers to fix Parallels.
OK, hopefully this helped someone out there!
As a side-note to other triple-booters, it's worth mentioning that installing LILO as your MBR bootloader is a bad idea if you want to use rEFIt, because rEFIt recognises LILO and displays an extra icon for it in the OS selection screen. It also display the icons for the OSes it finds on your partitions, but when you select any of them it runs everything through LILO, so they all do the same thing. If however you use something like syslinux as your MBR bootloader, rEFIt doesn't recognise it, and boots directly from the partition bootloader, bypassing the MBR bootloader completely, and everything works as expected.
{P^/
