I've managed to resolve the issue myself somewhat after -alot- of trickery. It seems the problem (or my instance of it at least) stems from the fact that, rather stupidly, Intel have specified that Linux partitions get the same GUID in the GPT as XP partitions. The fun part is changing the GUID without losing the said linux partition. I managed to fix this by booting the OSX install dvd, starting a terminal, unmounting all the hard drive partitions, killing the installer and diskarbitrationd daemon (to prevent remounts of the hdd, the gpt tool doesn't like editing mounted partitions, naturally), using gpt to remove the linux partition entry from the table altogether, then use gpt again to add a partition starting at the same sector, with the same size and same index as the old linux partition, but changing the partition type to anything other than 'windows' or 'linux'. In the end I chose to use the 'linux reserved' guid: 8DA63339-0007-60C0-C436-083AC8230908. Now parallels won't complain about multiple bootcamp partitions. (do not try at home, and if you do, don't come running to me when everything stops working)
But, this was only half my problem. The MBR that exists in the hybrid setup also needs to be altered. EFI says this should contain a single cover-all unknown-type partition entry to prevent overwriting gpt tables, and that a gpt entry should have the 'mbr partition' guid to specify that it be treated as a hard drive in it's own right with it's own mbr at the start of the partition. Apple with their bootcamp assistant violate this specification slightly in that the protective 'unknown-type' partition in the mbr covers just the gpt header+table and the efi system partition, treating xp as a normal mbr partition listed in the mbr. This would be fine except all the /other/ setups out there expect either the full-blocked efi hybrid with individual mbr, _or_ the full-standard mbr without any consideration for efi, and so they tend to leave the efi system partition listed in the mbr as a hidden-type fat32 and thus ending up with a normal run of the mill mbr. rEFIt's gptsync.efi utility will correct this and replace the gpt header+table + efi system partition as a single unknown in the mbr as per the apple way that bootcamp does when used alone and as parallels expects. In the end parted under linux and alot of dd use were also called for to get things straight (I had to restore the gpt portion from the backup at the end of the disk to get started)
This is however not something one can undertake on their own without extensive knowledge of the inner workings of their computers.
And again, I don't feel that this is a necessary hurdle to cross with some very minor changes to how parallels tries to access partitions. (Does it even -need- to know what the gpt is if the partitions are already presented in the devfs?)
ps: If you are reading this expecting to fix your greyed out bootcamp problem, and none of what I said above makes sense, then it's of no help to you anyway. Don't go playing with rewriting mbr's unless you're prepared to take full responsability for losing everything on your hard drive, specially the part that mentions dropping an entry from the gpt then re-adding it)
Last edited: Jan 11, 2007