Warning: Attempting to boot from physical partition may damage data on your disk, both inside the partition you’re trying to boot from and off of it. Consider yourself warned!
I’m apparently running a somewhat unusual setup for a Mac user: MacOS, Linux and Windows.
$ sudo fdisk /dev/rdisk0
Password:
Disk: /dev/rdisk0 geometry: 30401/255/63 [488397168 sectors]
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: EE 1023 254 63 - 1023 254 63 [ 1 - 409639]
2: AF 1023 254 63 - 1023 254 63 [ 409640 - 322003488] HFS+
3: 83 1023 254 63 - 1023 254 63 [ 322675272 - 59155896] Linux files*
*4: 07 1023 254 63 - 1023 254 63 [ 382093312 - 106303488] HPFS/QNX/AUX
To create a VMDK to access the fourth physical partition, containing Windows, I use the following command:
$ sudo VBoxManage internalcommands createrawvmdk -filename BootCamp.vmdk -rawdisk /dev/disk0 -partitions 4
In VirtualBox I also have to turn on APIC IO and pick ICH6 as the HDD controller. Partition also must be unmounted before booting.
Attempting to boot this results in an error. Windows’ bootloader sees us as having a three-partition setup, which is blatantly incorrect. One can edit BOOT.INI and tell Windows to use partition (3) instead of partition (4).
[boot loader]
timeout=3
default=multi(0)disk(0)rdisk(0)partition(4)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(4)\WINDOWS="Microsoft Windows XP Professional " /noexecute=optin /fastdetect
multi(0)disk(0)rdisk(0)partition(3)\WINDOWS="Microsoft Windows XP Professional on partition 3"
multi(0)disk(0)rdisk(0)partition(3)\WINDOWS="Microsoft Windows XP Professional on partition 3 - fast" /noexecute=optin /fastdetect
This results in a blue screen of death.
Creating a VMDK with VMware Fusion, then using its [name]-pt.vmdk file results in a successful boot. First clue is that VMware Fusion created a 32256 byte file, while VirtualBox created a 512 byte file. Googling reveals that 32256 is the size of the MBR. Hence, it could be that VMware simply copied 32256 bytes, as opposed to 512 bytes that VirtualBox took!
$ sudo dd bs=1 count=32256 if=/dev/disk0s4 of=BootCamp-pt-dd.vmdk
32256+0 records in
32256+0 records out
32256 bytes transferred in 0.203430 secs (158561 bytes/sec)
$ cmp -l BootCamp-pt-dd.vmdk BootCamp-pt-vmware.vmdk
451 356 55
467 257 55
483 203 55
So that isn’t the case, but the differences are much smaller than they could be.
So, brave souls, anyone have any idea what the differences might be? Using non-free VMware Fusion to be able to boot physical partition, when all that separates us from success is measly three bytes, is so… undignified.
Grab my .vmdk files; “old” is VirtualBox-generated file, “vmware” is VMware generated file (that works on my setup), and “dd” is file copied with DD.
BootCamp-pt-old BootCamp-pt-vmware BootCamp-pt-dd
Ah-ha! Further examination (at 1:46 CET 🙂 ) revealed that those three bytes, at correct offsets 1C2, 1D2 and 1E2 are partition type identifiers, and were all changed to 2D. That’s the only difference from the dd-captured data! This means perhaps even 512-byte bootsector change would suffice. But that’s a subject for another post. Have fun — try fixing your [name]-pt.vmdk file with a hex editor and post results in comments 🙂
*sigh* must … go … sleep … (2:13 CET)
These lines of code create a working BootCamp VMDK for me, when I have four partitions on my physical hard drive. Playing with physical partitions is dangerous — consider yourself warned before you run these. And of course, running both dd and fdisk on physical partitions is always dangerous; luckily we run fdisk on a file here, but still…
sudo VBoxManage internalcommands createrawvmdk -filename BootCamp.vmdk -rawdisk /dev/disk0 -partitions 4
sudo dd bs=1 count=32256 if=/dev/disk0 of=BootCamp-pt.vmdk # 32256 == mbr size
sudo chown `whoami` BootCamp*
sudo
echo "setpid 1
2d
setpid 2
2d
setpid 3
2d
write" | fdisk -e BootCamp-pt.vmdk
Additionally you need to set /dev/disk0s4 to be writable to your user (which means you’ll probably make it writable to everyone). Since this is even more dangerous, and a horrible, horrible security practice, I won’t put down the command to do this; easiest way to do it has something to do with changing mode to 777 to the mentioned file.
(Note! As of July 22nd, while playing with setting up booting of physical Ubuntu 12.04, I got the equivalent of BootCamp-pt.vmdk that was 37376 bytes long. Changing the dd command accordingly did not help with the problems I was having, but it didn’t seem to harm either.)
Once again: All in this section applies to having four partitions! All in this section can be dangerous!