Comments on Jérôme Andrieux: Setup Virtualbox on MacOSX to boot Linux (Debian) ...

@Ivan: Thanks ! I should consider rewriting / upd...

2010-04-07T09:53:42.534-07:00

@Ivan: Thanks !

I should consider rewriting / updating this whole article to include Steve's workaround.

It is worth to mention this setup still works today.

I haven't upgraded MacOSX to now Leopard though ...

Excellent blogpost! You may however want to: 1. R...

2010-04-07T09:10:13.551-07:00

Excellent blogpost! You may however want to:

1. Replace the test in "Create a VMDK image" step. It is checking for .../Library/VirtualBox folder, instead of checking for .../Library/VirtualBox/HardDisks
2. Change references to /Users/USERNAME/ into ~/. This means people can more easily copypaste the instructions :)

I'm now tinkering with setting up XP in VirtualBox from my triple-boot Mac :)

@Who : Debian is on ext3. There is no good to di...

2009-11-22T03:09:02.335-08:00

@Who : Debian is on ext3. There is no *good* to directly access the filesystem.
For now, I mostly use network FS (SMB/NFS/MacFuse+SSHFS) or mercurial/git for code related files.

MacOSX support for Linux FS'es is really poor :-/

I'm intrigued as to which filesystems and driv...

2009-11-15T18:02:32.146-08:00

I'm intrigued as to which filesystems and drivers you're using here. Is Debian on ext2/3? Are you using fuse-ext2 to access it on OSX? If no, what's the more elegant solution?

Thanks Steve for this feedback. Not being famili...

2009-09-27T23:26:05.528-07:00

Thanks Steve for this feedback.

Not being familiar with GPT lead me to VMWare but your workaround feels much better :)

I tried to use the VBoxManage "-mbr" switch without success, with subtles variations.

Having read the VMWare's VMDK specs, I guess we could also use "RO" or "NOACCESS" instead of "RW" to reduce risks (though perms on /dev/diskXX should be enough).

Maybe should you post your comment on :
http://www.virtualbox.org/ticket/1461 !

Thanks, Jérôme, this works well. I had to adapt y...

2009-09-27T09:12:55.071-07:00

Thanks, Jérôme, this works well.

I had to adapt your instructions a bit. Firstly, I had 5 partitions in the GPT, and MBR only supports 4 primary partitions, so I had to do a pure-GPT set up. But the raw disk creator tools in both VirtualBox and VMWare Fusion do not seem to work with GPT, so I had to intervene, manually editing the VMDK file. It was actually not too hard; as a nice side effect, we do not really need to fall back on VMWare anymore.

Here is what I did:

Step 1. Using the Disk Utility from Mac OS X, I resized my HFS+ partition, and left free space for Linux.

Step 2. I booted a Fedora Linux install CD outside of VirtualBox. Its partition editor understands GPT, so I set up the partitions I want there. (Disk Utility is too limited for creating partitions for anything other than Mac and Windows.)

Step 3. After partitioning, I do not install anything yet, but boot back to Mac OS X. I look at the GPT with:

$ sudo gpt -r show /dev/disk0

start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
409640 585675360 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
586085000 102400 3 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
586187400 52387840 4 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
638575240 338196480 5 GPT part - E6D6D379-F507-44C2-A23C-238F2A3DF928
976771720 1415
976773135 32 Sec GPT table
976773167 1 Sec GPT header

Step 4. I make the VMDK file with something like:

$ VBoxManage internalcommands createrawvmdk -filename Fedora12.vmdk -rawdisk /dev/disk0

Step 5. Now I open that VMDK file with a text editor, and change the "Extent description" to what was reported from the GPT:

# Extent description
RW 40 FLAT "gpt.vmdk"
RW 409600 ZERO
RW 585675360 ZERO
RW 102400 FLAT "/dev/disk0s3"
RW 52387840 ZERO
RW 338196480 FLAT "/dev/disk0s5"
RW 1415 ZERO
RW 33 ZERO

The first 40 LBA sectors in the first entry contains the GPT-related data (1 for the Protective MBR, 1 for the Primary GPT header, 32 for Primary GPT table, and 6 slack, as reported by gpt show).
So does the last 33 sectors (e.g. Secondary GPT table, Secondary GPT header). I did not bother to copy the Secondary GPT data, so I just them to zero. (This does cause a harmless warning message from the Linux kernel.) For the two GPT partitions I wanted to access with VirtualBox, I put in their Mac OS X device names. Those devices have to be made readable and writable by your normal user: something like this would do:

$ sudo chown root:admin /dev/disk0s3
$ sudo chmod g+rw /dev/disk0s3

Step 6. I copy the real GPT from the hard disk to the file gpt.vmdk mentioned in the extent description:

$ dd if=/dev/disk0 of=gpt.vmdk bs=512 count=40

I need to copy 40 LBA sectors since that what gpt show reported.

Step 6. Now when the VMDK is registered, Linux should happily see the partition table and be able to access the selected partitions.

Of course, if you ever change the partition layout later, you have to re-do all these steps. Otherwise the hard disk's GPT, VirtualBox, and the virtual GPT would disagree on where things are and your data will be corrupted.