I still have Gutsy on my work computer. I should really upgrade it to Hardy but unfortunately “dist upgrade in progress” is not really an acceptable excuse for not doing actual work so I keep putting it away. Ideally I could probably just run dist-upgrade during my lunch break, and then come back to a fully upgraded system. But every single dist-upgrade I did in the past required some babysitting so I’m not expecting this one to be any different. So for the time being I will stick with Gutsy – at least until I carve out a good chunk of time to devote to upgrading it, and potentially fixing anything that broke in the process.
Then again, maybe if I have upgraded earlier I wouldn’t have this VirtualBox issue today. At work I’m usually running a Windows XP instance inside VirtualBox so that I can access and use various Windows specific apps. Yesterday it just stopped working – it simply wouldn’t boot telling me that a wrong kernel module is installed. I wish I took a screenshot of the error message but I didn’t. Instead I started troubleshooting. First I needed to find out which version of kernel was installed on my machine:
lmaciak@malekith:~$ uname -a
Linux malekith 2.6.22-15-generic #1 SMP Tue Jun 10 09:21:34 UTC 2008 i686 GNU/Linux
It seems that my Kernel is 2.5.22-15. I vaguely remember pulling down some updates on Friday morning. A new kernel was among them, I believe. Next I took a quick peak on my VirtualBox installation:
lmaciak@malekith:~$ aptitude search virtualbox-ose-modules
i virtualbox-ose-modules -
i virtualbox-ose-modules-2.6.22-14-generic - virtualbox-ose modules for linux-image-2.6.22-14-generic
p virtualbox-ose-modules-2.6.22-14-server - virtualbox-ose modules for linux-image-2.6.22-14-server
It immediately became clear – there is a mismatch between my kernel and the installed modules. Unfortunately the only VirtualBox kernel modules in the repositories were the 2.6.22-14 ones. A 2.6.22-15 version simply doesn’t exist. Not for Gutsy at least and the Hardy release has to many unresolved independecies. So if you are still on Gutsy for some reason (like me) and you just updated your kernel (like me) you are now totally screwed (like me). The OSE version of VirtualBox just won’t work and there is no solution for this yet – and there may never be since Gutsy is on it’s way out.
There is a quick workaround though. Ditch the OSE version, and use the non-free binary under the PUEL License. I believe that my use of the software falls uder the “Personal use or Evaluation” clause since I’m not using it for hosting, and not sharing or distributing it. And I will likely only keep it only until I upgrade to Hardy.
If you are in the same boat, here is what you do. First get rid of your current VirtualBox installation:
sudo aptitude remove virtualbox-ose
Next, head over to the sun download page and grab yourself an appropriate deb file (pick Gutsy from the pull-down list). Install it via dpkg:
dpkg -i virtualbox_1.6.2-31466_Ubuntu_gutsy_i386.deb
It will go through the motions, and you may need to acknowledge one or two prompts as it configures appropriate kernel module. Once it is done, you should be all set. Please note that /usr/bin/virtualbox is unlinked replaced by /usr/bin/VirtualBox (note the camel case) which means any old aliases, shortcuts and key bindings will no longer work. You will have to manually adjust them. Other than that, the difference between the two versions in minimal. They use slightly different icons, and a different splash screen but for the most part it is the same software and you can easily use your regular VirtualBox images.
I hope this will help any potentially pissed off VirtualBox users who are still clinging to Gutsy for whatever reason. :mrgreen:
[tags]virtualbox, gutsy, linux, ubuntu, hardy[/tags]
Clinging to Gusty? I’m still on Fiesty on my primary machine, Edgy on one, and Gusty on my family’s computers. I haven’t even tried Hardy.
Heh! Good to know I’m not the only “late adopter” out there. :)
If everything works I see no reason to upgrade. If I’m having problems, I will upgrade. As simple as that.
If a distro is unsupported, I’ll upgrade. I’ll also install Hardy if I ever want to make a new Ubuntu install.
Same problem here.
Finally, I’ve done the same you did: installed the PUEL version.
Don’t expect a totally smooth upgrade to Hardy. I made a clean install on my home computer on the release day, and have had quite some issues with many components that have been swapped out with “better” alternatives I am less used to. Some examples: Pulseaudio for audio gives endless issues with Skype, Xrandr for multimonitor xorg support that I just failed to configure for my nvidia card, gnome-vfs -> gvfs breaks certain things, the default firefox (Firefox 3 beta 5) had freezing issues, the bluetooth layer seems to have changed subtly, there are new issues with suspend to ram for me, and for the first time in my life on Linux/unix I had an uninteruptable process take 100% cpu :(.
On that computer I actually have the non-ose Virtualbox. After a recent kernel upgrade it also complained over the kernel module not being compatible. However, my error message said something like: “run /etc/init.d/virtualbox setup”. This gave a “recompiling kernel module”, and then it worked again. But it may very well be that this only works for the manually installed non-ose version.
[quote post=”2554″]After a recent kernel upgrade it also complained over the kernel module not being compatible. However, my error message said something like: “run /etc/init.d/virtualbox setup”. This gave a “recompiling kernel module”, and then it worked again. But it may very well be that this only works for the manually installed non-ose version.[/quote]
Yep. The OSE version gives the same message, but /etc/init.d/virtualbox does not recognize the “setup” command. It only knows about start, stop and restart.
The non OSE version can recompile it’s own modules I believe.
It’s pretty easy to build a .deb for the vboxdrv module for gutsy along the lines of:
apt-get source virtualbox-ose-modules-2.6.22-14-genericapt-get build-dep virtualbox-ose-modules-2.6.22-14-generic
Then edit the debian/control file to change the version to -15 and build the package with
dpkg-buildpackage -BInstallation of the resulting .deb requires removing the -14 version first with dpkg –force-depends
You are my hero. I’ve been holding off on the 2.6.22-14 -> 2.6.22-15 update for a long time because I knew my binary nvidia drivers would be an issue.. Anyways, I bit the bullet and upgraded to 2.6.22-15 and (OOPS) I didn’t expect vbox kernel modules to have a problem. Anyways– thanks for the advice.. moving to this non-opensource version was pretty much a breeze — it even converted my old Virtualbox config files from the “old” format to the “new” format. I didn’t loose any data on my virtualized host operating systems. Woo HOO!!!!!!
You can repair your virtualbox install on gutsy with a 2.6.22-15 kernel by :
– removing virtualbox 2.6.22-14 module :
– rebuild the module for the new kernel :
– reinstall virtualbox :
@Axel: Very nice! Thanks for this solution. I didn’t think about that and jumping ship to the non ose version just seemed like a logical next step. Perhaps this will help someone who doesn’t want to make that leap. :)