Virtualbox allows you to run a lot of x86 OS virtual machines, mostly from a "virtual disk image", ie a file. On the other hand, it is now easy to setup a MacOSX / Debian dual boot, for us long time Linux lovers.
While both are convenient and working nicely, it's actually pretty difficult to get Virtualbox on MacOSX using the Linux raw disk partition as a VM. It can work though, with a little help from VMWare ...
REMEMBER : this is said to be experimental and dangerous ! Try at your own risk, but backup first !
Requirements
- a working MacOSX / Debian Linux dual boot setup (using rEFIt), see http://blog.jardinmagique.info/2009/07/debian-linux-on-macbook-install-notes.html for instance
- latest Virtualbox (v3.0.4 r50677 here) from http://www.virtualbox.org/wiki/Downloads
- a copy of VMWare Fusion trial blah, from http://www.vmware.com/fr/products/fusion/
Steps
Create the disk image with Virtualbox
List partitions to work with (3 and 4 here)
$ sudo VBoxManage internalcommands listpartitions -rawdisk /dev/disk0
VirtualBox Command Line Management Interface Version 3.0.4
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.
Number Type StartCHS EndCHS Size (MiB) Start (Sect)
1 0xee 1023/254/63 1023/254/63 200 1
2 0xaf 1023/254/63 1023/254/63 214912 409640
3 0x83 1023/254/63 1023/254/63 38146 440549416
4 0x82 1023/254/63 1023/254/63 3814 518674418
Same thing with fdisk
$ sudo fdisk /dev/disk0Disk: /dev/disk0 geometry: 38913/255/63 [625142448 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 - 440139776] HFS+
*3: 83 1023 254 63 - 1023 254 63 [ 440549416 - 78125002] Linux files*
4: 82 1023 254 63 - 1023 254 63 [ 518674418 - 7812501] Linux swap
Partition #4 is the swap. I won't use it, so I'll just keep #3.
As we need to access the actual raw disks, we need to change permissions on /dev/disk0* to gain the write bit (I think write is only needed for the linux partition, but read is mandatory for disk0 and diskOs3)
$ sudo chown root:admin /dev/disk0* #providing you belong to the admin group
$ sudo chmod 660 /dev/disk0*
Copy your MBR to a file
dd if=/dev/disk0 of=disk0.mbr bs=512 count=1
Create a VMDK image
$ [ -w /Users/USERNAME/Library/VirtualBox/ ] && VBoxManage internalcommands createrawvmdk -filename /Users/USERNAME/Library/VirtualBox/HardDisks/VMNAME.vmdk -rawdisk /dev/disk0 -partitions 3 -mbr disk0.mbr -register
VirtualBox Command Line Management Interface Version 3.0.4
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.
RAW host disk access VMDK file /Users/USERNAME/Library/VirtualBox/HardDisks/VMNAME.vmdk created successfully.
This command produced two files
$ ls -l ~/Library/VirtualBox/HardDisks/
...
-rw------- 1 USERNAME USERNAME - 32256 26 aoû 13:17 VMNAME-pt.vmdk
-rw------- 1 USERNAME USERNAME - 738 26 aoû 14:32 VMNAME.vmdk
...
This disk image have been registered (-register option) so they are ready to be used !
$ grep VMNAME /Users/USERNAME/Library/VirtualBox/VirtualBox.xml
<HardDisk uuid="{b4076b6e-1410-4ab0-b772-3a9cc18f8ceb}" location="/Users/USERNAME/Library/VirtualBox/HardDisks/VMNAME.vmdk" format="VMDK" type="Normal"/>
Create the virtual machine with Virtualbox GUI
Launch Virtualbox and create a new Debian (whatever you like actually) VM using the new registered disk image (VMNAME.vmdk here). You may also go to advanced setup and change the harddisk controller from IDE to SATA so that Debian won't have to bother between sda / hda naming, depending on your machine. I guess all Mactel have SATA disks now, not sure.
Once your machine is created, you can try to launch it and see ... FAIL. Well, Grub is OK, kernel is loading but then "Unknown partition table", "Unable to mount rootfs", ...
Using a custom MBR is not working for now, it seems that on MacOSX host, Virtualbox only supports Bootcamp'ed Vista raw disk partition. See http://www.virtualbox.org/ticket/1461
Use VMWare to produce a working xxx-pt.vmdk file
Of course, we could all use VMWare Fusion from the beginning, but I just don't like them. Anyway, download and install VMWare Fusion trial with command line tools.
Once installed, create a VM within WMWare, following http://fearandloath.us/vmware-fusion-bootcamp-partition.html advices
Basically, run
$ cd "/Library/Application Support/VMware Fusion/"
$ ./vmware-rawdiskCreator create /dev/disk0 3 /Users/USERNAME/VMNAME.vmwarevm/VMNAME.vmdk ide
This will create the same files as before, but this time
$ ls -l /Users/USERNAME/VMNAME.vmwarevm/VMNAME-pt.vmdk
-rw-------@ 1 USERNAME USERNAME - 32256 9 jul 19:52 VMNAME-pt.vmdk
Once you get there, backup your existing Virtualbox generated -pt.vmdk file and copy the VMWare there instead (make sure vbox and fusion are off)
$ cd ~/Library/VirtualBox/HardDisks/
$ mv VMNAME-pt.vmdk VMNAME-pt.vmdk.vbox
$ cp /Users/USERNAME/VMNAME.vmwarevm/VMNAME-pt.vmdk .
You can notice the difference in size between the two of them
$ ls -l ~/Library/VirtualBox/HardDisks/
...
-rw-------@ 1 USERNAME USERNAME - 32256 26 aoû 13:17 VMNAME-pt.vmdk
-rw------- 1 USERNAME USERNAME - 512 19 aoû 17:42 VMNAME-pt.vmdk.vbox
...
Booting
Now, finally, you can boot the VM. Grub and the kernel should understand the partition table and mount the rootfs. Enjoy !
Troubleshooting
Many things can go wrong, especially because I began to look at this a while ago, so some errors could have found their way in.
- permissions : you need to understand UNIX permissions and ownership to fix perms on disks and files. I think this could be made a little bit safer by not letting the write bit on all partitions (disk0s3 only should do).
- permissions again : permissions on disks are only set until reboot, you may have to fix a service otherwise Virtualbox will complain that disks are not accessible (VMWare prompts you for an admin password ... Clever.)
- Grub, MBR, GPT, rEFIt mess : I never took time to read about EFI, GPT, MBR, etc. This could be problematic for you, however, if you already have a working dualboot setup, it should be OK (try gptsync from rEFIt otherwise).
Moreover, it would be nice to understand what VMWare is writing in this -pt.vmdk file to make it understandable by the Linux Kernel or maybe just what Virtualbox is doing wrong ...
Messages
6 commentaires:
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.
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 !
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?
@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 :-/
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 :)
@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 ...
Enregistrer un commentaire