Nonstandard BootCamp setup - Parallels behaviour

Discussion in 'Installation and Configuration' started by FyKnight, Apr 3, 2008.

  1. FyKnight

    FyKnight

    Messages:
    2
    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^/
     
  2. daveDM

    daveDM

    Messages:
    2
    thanks, more info please

    That is very cool. Can you post your modified syslinux bootloader code?

    I have a similar triple boot system, partitioned manually and where I use refit to boot into any of the three OS's. I can use parallels to run either of the installed OS's from their respective partitions from within the MacOS, but I can not run both simultaneously from within Parallels because of the same problem you describe.

    More specifically, refit marks the MBR booted OS partition active before it boots into it (ie I boot into Linux and the linux partition is flagged, I boot into XP and now XP instead of Linux is flagged, I boot Mac and XP stays flagged). Because of that I can run only the most recently booted OS from within Parallels. If I try to run both simultaneously, the one I haven't booted into recently will fail. And in order to run that OS within parallels, I have to reboot into it, shut it down, reboot into the Mac and select it with parallels.

    It would be very helpful if the Parallels developers could make the non marked partition bootable, perhaps by flagging it just before load as refit does.
     

Share This Page