Archive for September, 2010

Virtualbox, and upgrading

September 5th, 2010 1 Comment

So, today I ran the monthly update on Pogo, our trusty lil file/print server, especially since there has recently been a kernel update to get rid of a vulnerability when using X11.  In doing so I had to rebuild the VirtualBox drivers to work with my new kernel.  Since this is not a core package available in the Arch Linux repository, I have to use the Arch User Repository and realized that there was an update available.  I ran the update and all was well until I decided to give my virtual windows machine a spin for hohos. When I tried to run my virtual Win XP machine this is what I encountered.

Medium type of ‘/home/rob/.VirtualBox/HardDisks/{0cf3783a-83e4-4282-882d-304855c197da}.vmdk’ is differencing but it is not associated with any parent medium in the media registry

Yikes!  Not good at all, I almost wept in frustration as we had a couple printer problems with my wife.  As we always seem to have, I think the printer secretly hates her and by extension, me, since I am always called upon to remedy the situation.  Back to the problem at hand, it was an odd error which gave me no insight into what was going on or what was expected of me.  So I ran to google, my friend in all of these types of problems.   Fortunately, it found a trouble ticket on the VirtualBox site.  This ticket stated that:

  • The reason is that an older release of VirtualBox wrote a wrong information to your .vdi images. VBox 3.2.8 is more paranoid.
  • Only some base .vdi images are affected, the snapshots need no fixing. The fact that the base .vdi was declared inconsistent (having a non-zero parent UUID) makes the snapshots implicitly inaccessible too.

As with a lot of projects like this a fix was provided by the next day.  This can be downloaded here.  Make sure you download the file for your host system, in my case it was the VBoxFixHdd-Linux file.  Then I had to:

$ chmod u+x VBoxFixHdd-Linux

Then you just need to(in the words of the VirtualBox devs):

  1. Identify the affected images. You can either use the VirtualBox GUI and check which base images are inaccessible, but shouldn’t be. The same can be done with “VBoxManage list hdds”, in this case make sure you only look at images which say “Parent UUID: base”.
  2. Run the repair tool:

    $ VBoxFixHdd –filename /path/to/image.vdi –zeroparentuuid

  3. Repeat for all affected images. The tool can fix images in all formats supported by VirtualBox.
  4. After you’re done, double check the results either in the VirtualBox GUI (go to the Virtual Media Manager and click on the “Refresh” button), or with:

    $ VBoxManage list hdds

Once you do all that, you should have all the affected images fixed.  As was stated this was an import image from my laptop so that may have been what triggered it.  I only had one affected image but it worked just fine once I ran the fix utility and now my virtual machine is happy happy again. They did state that future versions of VirtualBox would have a utility which would do this automatically so this can be avoided in the future.  Hope this helps all you peeps out there.