When Upgrades Break Vagrant Boxes

Posted By Doug / December 23, 2013

Promet developers work on local copies of sites built using Vagrant and Chef. In the tech industry, software is constantly changing. Updates and upgrades are intended to fix bugs and improve the software, but all too often, new bugs and issues arise as a result. When bugs and issues arise with Vagrant, work slows drastically, and it becomes necessary to identify and resolve the issues as quickly as possible. The developers at Promet recently experienced this and share their story in hopes of saving others time, money, and frustration.

The Exposition

Without warning, local sites suddenly stopped working. We tried to SSH into the Vagrant box to check the error logs but were unable to connect to the box. In typical debugging fashion, we tried turning the box off and on again. When we attempted to shut down the box, Vagrant gave a rather unhelpful error:

[/Applications/MAMP/htdogs/loggia]$ vagrant halt

[default] Attempting graceful shutdown of VM

Guest-specific operations were attempted a machine that is not ready for guest communication.  This should not happen and a bug should be reported.

[/Applications/MAMP/htdics/loggia]$

The Rising Action

Since there was an update available, we used VirtualBox’s update tool to upgrade to version 4.2.18. We then encountered the following error:

<code>There was an error while executing `VBoxManage`, a CLI used by Vagrant

for controlling VirtualBox. The command and stderr are shown below.

Command: ["hostonlyif", "create"]

Stderr: 0%...

Progress state: NS_ERROR_FAILURE

VBoxManage: error: Failed to create the host-only adapter

VBoxManage: error: VBoxNetAdpCtl: Error while adding new interface: failed to open /dev/vboxnetctl: No such file or directory

VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component HostNetworkInterface, interface IHostNetworkInterface

VBoxManage: error: Context: "int handleCreate(HandlerArg*, int, int*)" at line 68 of file VBoxManageHostonly.cpp</code>

Googling led us to a workaround: Restart Virtualbox:

<code>sudo /Library/StartupItems/VirtualBox/VirtualBox restart</code>

However, this had to be done after every system reboot and did not work for some.

We then tried updating Vagrant to the then latest version (1.3.5) and VirtualBox to 4.23. Due to a bug that left the old kernel versions in place, we had to manually uninstall VirtualBox before installing the new version. (VirtualBox fixed these installer issues in version 4.3.2.) These updates resolved the VirtualBox network adapter issues.

The Climax

Next, we encountered an error when installing a package on the virtual machine (VM):

<code>Error executing action `install` on resource 'package[apparmor-utils]'</code>

The Falling Action

Using Debian Wheezy on the box resolved the error when installing apparmor-utils but caused an error with using the latest version of the mySQL cookbook. Using an older version (specifically, 3.0.12) resolved the issue, and our local site worked once again!

The Conclusion

Pooling our resources and drawing on the community for the affected programs allowed us to draw on the experiences of others and save time. We also learned the importance of full documentation (steps that were taken, error messages, and environment configuration) of an issue. This prevents "I remember having this issue, but how did I fix it…" moments down the line and saves time, money, and frustration.