cashiers-imac:VDI cashier$ hexdump -C foo.vdi |less
00000000 3c 3c 3c 20 69 6e 6e 6f 74 65 6b 20 56 69 72 74 |<<< innotek Virt|
00000010 75 61 6c 42 6f 78 20 44 69 73 6b 20 49 6d 61 67 |ualBox Disk Imag|
00000020 65 20 3e 3e 3e 0a 00 00 00 00 00 00 00 00 00 00 |e >>>...........|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 7f 10 da be 01 00 01 00 90 01 00 00 02 00 00 00 |..ھ............|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000150 00 00 00 00 00 02 00 00 00 62 00 00 00 00 00 00 |.........b......|
00000160 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 |................|
00000170 00 00 00 80 01 00 00 00 00 00 10 00 00 00 00 00 |................|
[...]
cashiers-imac:VDI cashier$
According to this post, the offset in bytes from start of the VDI of the start of enclosed disk data is at offset 0x158. It's a little-endian 32-bit integer, so the value above is 0x6200.
cashiers-imac:VDI cashier$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
obase=16
512
200
ibase=16
6200 / 200
31
^D
cashiers-imac:VDI cashier$
Here, we are converting the offset in bytes of 0x6200 into an offset in sectors of 0x31. The numbers are all hex. A comment in the VirtualBox source (horray for freedom!) referenced in the above forums thread promises the offset is always meant to be in sectors for performance reasons, so there should be no remainder to that division.
cashiers-imac:VDI cashier$ hdid -section 0x31 -nomount foo.vdi
hdid: attach failed - not recognized
cashiers-imac:VDI cashier$ ln foo.vdi foo.img
cashiers-imac:VDI cashier$ hdid -section 0x31 -nomount foo.img
/dev/disk2 FDisk_partition_scheme
/dev/disk2s1 DOS_FAT_16
cashiers-imac:VDI cashier$
hdid has a -section
option, and hdiutil does not.
However I think hdid is encapsulating -section
into some
kind of fancy property and passing it to secret internal
``frameworks'' used by hdid and hdiutil that are less likely to disappear in Mac OS 10.6 than
hdid itself. I'm a little worried to not understand that part.
When I tried this command on the .vdi
file without ln, it
did not work. If you start hdid with -debug
, you'll see
one of the things it cares about when trying to dynamically determine
an ``image type'' is the extension. It does not recognize VDI, and
only probes for some magic numbers of hdiutil-style wrapped disk
images that it knows about. I tried .dd
, and that didn't
work, either. Using .img
seems to make it work!
Apple, your voodoo is of high-quality, but sorry, that doesn't excuse you from the obligation to document it, and your market share doesn't make said documentation my problem, because as you can see I'm the one who has to do it. In my view, you're competing with Linux and Solaris, not with Windows, so...fuck you for that.
If it works, you'll see the tangled Mac disk subsystem recognized the MBR table and called it FDisk_partition_scheme, and made some slices for you. Nevermind the DOS_FAT_16---Windows seems to tag its NTFS partitions as FAT16 without caring. It's a correct image mount. No filesystems are mounted yet.
cashiers-imac:VDI cashier$ mkdir /Volumes/ExPee
cashiers-imac:VDI cashier$ sudo /usr/local/bin/ntfs-3g /dev/disk1s1 /Volumes/ExPee -o ping_diskarb,volname=ExPee
kextload: /Library/Filesystems/fusefs.fs/Support/fusefs.kext loaded successfully
cashiers-imac:VDI cashier$
I found this incantation on some lame blog that was the first hit on Google.
cashiers-imac:VDI cashier$ umount /Volumes/ExPee
cashiers-imac:VDI cashier$ rmdir /Volumes/ExPee
cashiers-imac:VDI cashier$ hdiutil detach /dev/disk2
"disk2" unmounted.
"disk2" ejected.
cashiers-imac:VDI cashier$
Please clean up your mountpoint---the ``disk arbitration'' stuff seems to be not done enough to automount and autounmount. But, you are able to use hdiutil when you're done, not required to use hdid.