Installing Virtualbox Guest Additions On a Vagrant Lucid64 Box

I’ve been working through the new Deploying Rails book and found that the Ubuntu lucid64 image installed by Vagrant doesn’t come bundled with the latest version of the VirtualBox Guest Additions. I’ll walk through the steps necessary to install the latest version of the Guest Additions via the command line on your freshly built lucid64 box.

Here’s a summary of the commands to issue. A detailed explanation follows, but if you just want the quick-and-dirty then ssh into your new box (defaults to 127.0.0.1, port 2222, username: vagrant, password: vagrant) and issue these commands:

wget -c http://download.virtualbox.org/virtualbox/4.1.8/VBoxGuestAdditions_4.1.8.iso
sudo umount /mnt
sudo mount VBoxGuestAdditions_4.1.8.iso -o loop /mnt
sudo apt-get update
sudo apt-get install dkms
sudo apt-get install linux-headers-$(uname -r)
sudo sh /mnt/VBoxLinuxAdditions.run
sudo restart

Now the blow-by-blow explanation.

When you run vagrant up you’ll get an error message explaining that the guest additions don’t match the installed version of Virtualbox. Note that I’m running this from the command line on a Windows 7 machine.

> vagrant up
[default] Importing base box 'lucid64'...
[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.

Guest Additions Version: 4.1.0
VirtualBox Version: 4.1.8
[default] Matching MAC address for NAT networking...
[default] Clearing any previously set forwarded ports...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Creating shared folders metadata...
[default] Clearing any previously set network interfaces...
[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

The first thing to do is ssh into your new box. Normally this will be on 127.0.0.1 port 2222 (username: vagrant, password: vagrant) unless you’ve specified something else in your Vagrantfile. Once into the box issue the command:

wget -c http://download.virtualbox.org/virtualbox/4.1.8/VBoxGuestAdditions_4.1.8.iso

to download the guest additions (4.1.8 is the current version as of this writing — see the error message when you run vagrant up for the version installed on your host machine).

Next we try and mount the guest additions .iso image and run the installer:

sudo umount /mnt
sudo mount VBoxGuestAdditions_4.1.8.iso -o loop /mnt
sudo sh /mnt/VBoxLinuxAdditions.run

Verifying archive integrity... All good.
Uncompressing VirtualBox 4.1.8 Guest Additions for Linux..........
VirtualBox Guest Additions installer
Removing installed version 4.1.0 of VirtualBox Guest Additions...
tar: Record size = 8 blocks
Removing existing VirtualBox DKMS kernel modules ...done.
Removing existing VirtualBox non-DKMS kernel modules ...done.
Building the VirtualBox Guest Additions kernel modules
The headers for the current running kernel were not found. If the following
module compilation fails then this could be the reason.

Building the main Guest Additions module ...fail!
(Look at /var/log/vboxadd-install.log to find out what went wrong)
Doing non-kernel setup of the Guest Additions ...done.
Installing the Window System drivers ...fail!
(Could not find the X.Org or XFree86 Window System.)

If you look in /var/log/vboxadd-install.log you’ll see the error message

/tmp/vbox.0/Makefile.include.header:94: *** Error: unable to find the sources of your current Linux kernel. Specify KERN_DIR= and run Make again. Stop.
Creating user for the Guest Additions.
Creating udev rule for the Guest Additions kernel module.

Easy enough to fix. Run the following commands to install the linux kernel sources:

sudo apt-get update
sudo apt-get install dkms
sudo apt-get install linux-headers-$(uname -r)

Now that all the pieces are in place (if you miss one you’ll see another error in /var/log/vboxadd-install.log) you can install the guest additions:

sudo sh /mnt/VBoxLinuxAdditions.run

Verifying archive integrity... All good.
Uncompressing VirtualBox 4.1.8 Guest Additions for Linux..........
VirtualBox Guest Additions installer
Removing installed version 4.1.8 of VirtualBox Guest Additions...
tar: Record size = 8 blocks
Removing existing VirtualBox DKMS kernel modules ...done.
Removing existing VirtualBox non-DKMS kernel modules ...done.
Building the VirtualBox Guest Additions kernel modules ...done.
Doing non-kernel setup of the Guest Additions ...done.
You should restart your guest to make sure the new modules are actually used

Installing the Window System drivers ...fail!
(Could not find the X.Org or XFree86 Window System.)

You’re done! Since we’re running this server without a GUI you don’t have to worry about the “Could not find the X.Org or XFree86 Window System” error message. If you do have any more problems then refer to /var/log/vboxadd-install.log for the source of any errors.

Now just restart your box:

sudo restart

or run:

> vagrant halt
> vagrant up

from the host command line.

Posted in Uncategorized | 11 Comments

Testing XML in Flex and Ruby

I’ve just started reading Ruby Best Practices and the TDD chapter pointed out how best to test complex XML output. I found myself in a similar situation in Flex the other day so it was relieving to read that my solution paralleled the solution presented in the book.

You can read the relevant section from the free copy of the first chapter posted on Github. See page 22.

The reader’s digest version: parse the XML and then set up a series of tests to check the XML DOM for the important elements. The advantage is you’re not doing a brittle string comparison between two pieces of XML nor are you writing an enormous test that checks for every piece of data in the XML. This keeps each test small and understandable as well as making it easy to see where your problem is should a test fail.

Posted in Uncategorized | 1 Comment

Why I’ve Moved From PHP to Ruby

This year I’ve started playing with Ruby and Rails. Once I had put together some basic demo apps I realized how much faster it is to use Rails instead of PHP. I’ve been discussing this with one of our sysadmins at work and I realized what I like most about Ruby (and Rails) is the culture of the Ruby community.

First off, there’s a strong bias towards testing. With RSpec and Cucumber you can easily work in a BDD style of development. I’m reading The RSpec Book right now and it’s fundamentally shifting the way I develop software, especially after seeing what Josh Kerievsky had accomplished with his company using thorough test coverage as the foundation for continuously deploying their product. The Rails 3 In Action book also illustrates a behavior-driven approach to developing Rails projects.

I find the BDD style more intuitive to grasp than TDD and it feels like a natural progression to me. Ruby, from what I’ve seen (and please correct me if I’m wrong!), has the best BDD support with RSpec and Cucumber.

Then there’s the focus on DRY (Don’t Repeat Yourself) which is inevitably mentioned in any discussion about designing Rails software.

The last big advantage which puts Rails above PHP is the sheer number of plugins and gems available to the Rails developer. Since there’s one dominant framework in the Ruby world all the plugins and gems are written to work with it. PHP, with it’s multitude of competing frameworks, doesn’t have anywhere near the number of pre-written plugins to solve issues like adding roles and permissions to your site or put together an e-commerce site.

All this points to one fact I’ve learned after years of working in PHP: it’s faster to develop robust, high-quality websites in Rails.

Posted in Uncategorized | Leave a comment

Commands, Events, or Calling a Function Directly

I was talking with a coworker about the best way to trigger actions from a component in Flex. There are a few ways you can do it and each language has it’s preferred technique.

In Flex, you’d most likely handle the event dispatched by a component. Using a button click as an example:

<s:Button click="handleClick(event)"/>

In C# you’d use Commanding to hand a command class that encapsulates your function to be called to the button. Here’s a snippet from a Silverlight project:

<Button Content="Save" cal:Click.Command="{Binding Path=SaveOrderCommand}" />

Other languages such as Javascript and Ruby allow you to pass functions around as variables or even use anonymous functions that get called when an action is triggered. You’ve probably handed an anonymous function to an Ajax call in Javascript. Here’s a jQuery sample:

$.ajax({ url: "mypage.html", context: document.body, success: function(){
// Do something on success
}});

Actionscript also allows you to pass functions around but events seem to be the “Flex way” of doing things.

Events, commands, or functions are all legitimate ways to call a function when an action needs to be handled. I find I stick with the technique that’s best supported by the environment I’m working in.

Posted in Uncategorized | Leave a comment

How to Fail (and look good doing it)

VanDev has an interesting talk coming up called How to Fail (and look good doing it) which talks about how to turn a project failure into a learning experience for the team. I’m curious to see what they say about this! Talk is on Thursday, Nov 18 at UBC Robson Square.

Posted in Uncategorized | Leave a comment

Always Shippable

Yesterday I attended Josh Kerievsky’s Always Shippable tutorial at the Agile Vancouver conference. Josh is a sharp guy and went over how his company has implemented Continuous Delivery in the past 6 months.

Josh explained that Industrial Logic has reduced their time for a code commit to the source repository to move into production to about 1 hour and that this production push is entirely automated. That’s impressive because, as Josh said, it lets you get that value into the hands of your customers right away.

There were two big takeaways for me: First, you need to work in an organization where the culture will support your team’s efforts to improve their process. You also need a solid foundation of tests which you can rely on to catch bugs and regressions since you don’t have a QA step in between your code commit and that code being pushed to production. Josh mentioned they were doing TDD, which I can imagine is the only way you can keep up the high level of test coverage you’d need to go to Continuous Delivery.

Test driven development is something I’ve messed with in the past but it’s never become part my daily workflow. Now that I’m playing with Rails I’m taking another crack at it since Rails has testing and BDD baked right in with Rspec and Test::Unit. Given I’d like to one day be deploying applications in a Continuous Delivery fashion I need to get on top of TDD.

Posted in Uncategorized | Leave a comment

Rails Jam For Newbies!

Over the past couple of months I’ve been hacking on Ruby and Rails for fun. The local Rails group has organized a Rails Jam for Newbies event on Nov 20 and I will be there! It’ll be neat to work on Rails with a gang of eager geeks. I’m looking forward to it.

And now I’m off to the Josh Kerievsky tutorial at the Agile Vancouver conference.

Posted in Uncategorized | Leave a comment

VanDev Kanban Talk

On Monday night I checked out Chris Simmons talk on Kanban, a system of visualizing work in progress, as applied to software development. Chris got into specifics about how they use Kanban at Sophos and how it’s worked for them.

Kanban is basically a way to track your stories/tasks workflow using post-its and a whiteboard. One thing I found interesting was the idea of setting Work In Progress limits on each stage in the workflow. QA, for example, could be limited to 3 items at a time. That way if the dev team gets blocked because QA is saturated then it’s a clear signal to have a conversation and figure out what’s holding up the workflow. Maybe QA is under-resourced or in need of some temporary help. With the WIP you can quickly spot problems as they happen.

While I was reading more about Kanban I stumbled across an article on InfoQ that provides a good, comprehensive overview. Visualizing Agile Projects using Kanban Boards.

Next week I attend Josh Kerievsky’s talk, Always Shippable, at the Agile Vancouver Conference. I’m looking forward to that!

Posted in Uncategorized | Leave a comment

Estimating

There’s so many good presentations happening now and Monday was another one called Estimating: The Sociological Effects in a Group. Great talk by Todd Williams who specializes in rescuing failing projects. There were two big takeaways for me:

Statistically, the time to complete a task will be less than your original estimate only 50% of the time. The other 50% you’ll be over. If you estimate a number of tasks, such as at the start of a sprint, you’ll average out to roughly the sum of all your estimates.

This ties in with the second, more important takeaway which is that most people treat estimates as quotes. As the consequences become more serious for the accuracy of their estimate then they’ll increase their estimate to make sure they can “hit the number.” The problem with this is the student syndrome where a person doesn’t tackle the task until the last moment, burning up any padding in the estimate and expanding the schedule for the whole job.

To prevent this from happening Todd recommended the Agile practice of short iterations and also cautioned project managers about treating estimates as quotes.

Posted in Uncategorized | Leave a comment

Agile 101

Yesterday I attended the Agile 101 workshop put on by Agile Vancouver. I’ve had some experience with Agile techniques before but wanted to go through a refresher and also hear what they had to say about lean software development, since I haven’t had much exposure to those ideas (yet).

The day started off with an explanation of what failed projects tended to look like and moved into how Agile was attempting to solve these common problems. Having been in a variety of projects over the past 12 years, I’ve seen all manner of problems in software projects. The biggest thing that was reinforced for me was that software projects don’t work with a deterministic process. Engineers can plan a building and lay out blueprints because the building isn’t going to change as you build it. Not the case with a software project! Since you know the least about the project at the beginning, you’re better off working closely with your client, releasing in small increments, and letting the direction change with the frequent feedback you’ll receive from these releases.

After an entertaining team exercise where we formed small Agile teams to build small houses out of construction paper, Michael Vax took the stage for the latter part of the day to introduce everyone to Lean Software Development. It was a great talk, and a good introduction. To me, Lean is quite overlapped with the principles of Agile. Once I finish The Agile Samurai I’m going to get a copy of Mary Poppendieck’s lean software book.

While there was a good turnout for the workshop, I’m surprised more people don’t take advantage of these things. To get that kind of education for $30 and a Saturday is great value and I’m going to try to sell this workshop to a few of the people I work with.

Posted in Uncategorized | 3 Comments