[update:03-01-2011] Add OSE caveat [update:03-10-2011] Removed install virtualbox-ose-guest-dkms

This describes how to update Vagrant’s lucid64.box base box to the latest Guest Additions for VirtualBox 4.0.4. The only wrinkle was that the base box did not have the ppa:debfx/virtualbox repository configured.

Start The Old Vagrant VM

Make a backup and extract to a temporary folder:

$ mkdir tmp
$ cp lucid64.box tmp/lucid64.box
$ vagrant box add lucid64_4.0.4 lucid64.box
$ cd tmp
$ vagrant init lucid64_4.0.4
$ vagrant up

You should see message like:

[default] The guest additions on this VM do not match the install version of
VirtualBox! This may cause things such as forwarded ports, shared
folders, and more to not work properly. If any of those things fail on
this machine, please update the guest additions and repackage the
box.

It is this we aim to eliminate….

Update VirtualBox’s Guest Additions

$ vagrant ssh
vagrantup:~$ sudo apt-get update
vagrantup:~$ sudo apt-get install python-software-properties
vagrantup:~$ sudo add-apt-repository ppa:debfx/virtualbox
vagrantup:~$ cd /opt
vagrantup:~$ sudo wget -c http://download.virtualbox.org/virtualbox/4.0.4/VBoxGuestAdditions_4.0.4.iso \
                       -O VBoxGuestAdditions_4.0.4.iso
vagrantup:~$ sudo mount VBoxGuestAdditions_4.0.4.iso -o loop /mnt
vagrantup:~$ cd /mnt
vagrantup:~$ sudo sh VBoxLinuxAdditions.run --nox11
vagrantup:~$ cd /opt
vagrantup:~$ sudo rm *.iso
vagrantup:~$ exit

According to Brett Alton you can ignore the last error about the windows system driver’s failure to install, it should be harmless in non-GUI contexts.

Now check the Guest additions ‘just work’:

$ vagrant halt
$ vagrant up
[default] VM already created. Booting if its not already running...
[default] Running any VM customizations...
[default] Clearing any previously set forwarded ports...
[default] Forwarding ports...
[default] -- ssh: 22 => 2222 (adapter 1)
[default] Cleaning previously set shared folders...
[default] Creating shared folders metadata...
[default] Booting VM...
[default] Waiting for VM to boot. This can take a few minutes.
[default] VM booted and ready for use!
[default] Mounting shared folders...
[default] -- v-root: /vagrant

Excellent. No more warniings.

Package The New VM

$ vagrant halt
$ vagrant package
$ mv package.box lucid64_4.0.4.box

Done.

Caveats

An OSE version of guest additions seems to be only available via a Ubuntu package (virtualbox-ose-guest-x11) that has an X11 dependency. As of The Ruby gem virtualbox-0.8.3: Running a non-OSE Guest on a OSE Host (both VitualBox v4.0.4), with non-OSE Guest Additions installed, leads to this issue

A quick post to address this Chef issue. These issues (and more) can be resolved by using this fork of Bundler that targets the Chef use case. I’ll cover this in another post, but fro now note that this bundler fork is only intended for dealing with Chef Cookbook. Hopefully it’ll get to the point where the Bundler team accept (or provide) the requisite features.However, Bundler’s specs (and code base) make extending its behavior a nightmare – c.f Chef’s sweetness.

Anyway, the issues…

• A Cookbook is installed only if dependencies are present in the Gemfile.
• Installed dependencies are only updated if they have changed.
• Only cookbooks specified in a gemfile are downloaded.
• If you don’t specify dependencies, it gives LOTS of warning about that missing cookbook
• Cookbooks are downloaded individually by branch, tag, or commit hash.
• Cookbooks can be downloaded from any Git Repository (e.g. https://github.com/cookbooks )
• Cookbooks can be downloaded using Git clone recognized URI’s

Outstanding:

• Make pending specs pass (Bundler’s spec suite is a first class nightmare)
• Make bundle update and bundle show change into a folder pointed to by --lockfile-path

The Gemfile

This where to list (just) the Cookbooks you want to download. You can think of a Gemfile as describing an application stack. Defining and is as simple as listing the Cookbooks repos in the Gemfile – to get the stack configured and running is Chef’s domain of expertise. You can download from just about any Git repository. Most git clone URI syntax should work (but not path/file names with spaces – i.e. it uses an unencoded file:// URI). The Gemfile corresponding to Opscode’s build-a-rails-stack example is shown in this gist.

Downloading the Cookbooks

The transript of downloading the build-a-rails-stack example’s cookbooks is here.
Use --gemfile to point at any file containing Gemfile data. Download the Chef Cookbooks to any folder pointed to by --install-path, if the folder does not exist it will be created. There will also be a lockfile created: Gemfile.lock

Update the Cookbooks

The transript of updating the build-a-rails-stack example’s cookbooks is here.
If there is no update nothing is downloaded, per the issue request. If you use Git commit hashes, then you can ensure your Cookbook(s) never change, e.g. when you are in production. Currently you need to change into the folder containing the lockfile (Gemfile.lock), created by bundle install ... in the folder the --gemfile ... option pointed to.

Show/List the Cookbooks and their Git hash.

The transript of the build-a-rails-stack example is here.
As with updating, you need to change into the lockfile folder.

Missing a Cookbook dependency

Remove the couchdb entry from the Gemfile. This is required by Chef. As we can see in this gist, show, update and install behave in ways that are not unreasonable for Chef users.