29 dec 2010
running mac os x from virtualbox helps to experiment with software deployment for that platform. i’m using gentoo linux as host system with 2.6.34-gentoo-r6 kernel on a 64 bit core 2 duo machine with virtualbox 3.2.10 OSE. there are various blog postings about how to get it running so i won’t repeat this here.
the most important thing is to use the snow leopard retail dvd. as the dvd coming with the mac (a mac book pro in my case) won’t work. you can get the retail dvd on ebay or various other sources. note: the retail dvd is not labeled ‘snow leopard retail dvd’ but something like ‘snow leopard update dvd’ in most auctions (don’t blame me if that is wrong).
having snow leopard not only native, but also in a virtualbox image, makes testing of software easier.
i use about 40 gb here, and about 25 gb are actually in use with:
i wasted a lot of disk space with a default installation. but i don’t want to spend too much time on that right now so i will leave it that way. i removed the printer drivers later on, saved me 600mb.
import dmg images, which are used to install software from, using samba from the host. this way you do not have to copy the dmg onto the virtual machine using ssh or by mapping an external harddrive (note: the OSE version i am using, does not support USB host mapping anyway) into the virtual machine.
this also reduces the host image size by a few gigabyte of disk space. initially i was doing it wrong: i copied the file, installed from it and finally removed it. however, removing it did not have much of an effect, as virtualbox does not know about hfs+ partition scheme, therefore the file is only deleted inside the virtualmachine, still the host image uses the diskspace.
example:
my current disk image: mac os x [snow leopard].vdi is at 25Gb. but inside the virtual machine is is only 18gb.
[global]
workgroup = MYGROUP
server string = Samba Server
security = share
dns proxy = no
[rw-files]
comment = Temporary rw files
path = /home/user/smbshare/rw
read only = no
writable = yes
public = yes
[ro-files]
comment = Temporary ro files
path = /home/user/smbshare/ro
read only = no
writable = no
public = yes
don’t forget to:
consider using a user/password for that.
use wget to download it. it is about 3,6gb and it failed several times here. also resuming did not work well. after several attempts downloading it (must be about 12gb i’ve already downloaded) i had a, yet again, broken download at 99%. i thought: “not again”! and as there was no resuming (using a webbrowser) i downloaded a torrent.
next i used the torrent and started the download, which created a file with the same filename. i closed the torrent client (rtorrent) and moved the previously metioned 99% download file, to the place where the torrent expected it’s download. then i restarted the torrent download.
thanks i did not have an offset error (this can happen on wrong resumes, anyway i did not use resume).
finally the torrent checked all chunks and finnaly there was only 1mb left to download. so i repaired my download, using bittorrent. all i had to do is wait 5minutes.
next thing was file integrity. it seems that apple does encode some individual information into the xcode download. if rumors are true, it is no wonder that users sue apple, see [1]. anyway, this means we can’t create a md5sum. it would be interesting to know what is going on.
what we do know already is that most of the file, apparently 99% of the download is generic. if not, then i would not be able to repair the xcode download with the torrent content of a different user. see discussion at [2] for more input on this.
virtualbox supports snapshots, use them! they are a great way to update various system components as xcode without having to uninstall any components. this results in a cleaner system, saves time & resources as deleted files are only deleted virtually inside the vm.
every virtually deleted file is not really deleted as virtualbox works on a block device layer. that means: if hfs+ decides to use deleted inode for a newly created file it will be good as vm disk and real disk are in sync. but i guess more often than not this is not the case and the real disk image will grow over time.