Should ship new kernel modules at same time as new kernel

[Pascal d'Hermilly]

Binary package hint: linux-image-2.6.24-20-generic

I use virtualbox, and everytime I get a kernel upgrade, e.g. from 2.6.24-19 to 2.6.24-20, my virtualization breaks for several days. It renders the whole virtualization option useless as I can not depend on it.

Anyway, there should be a procedure to make certain that the kernel modules for the new kernel are shipped at the same time as the new kernel.

Otherwise people will stop updating as their computer is often rendered useless at certain tasks for several days after.

//Pascal

[Anders Kaseorg (andersk)]

This could be solved by modifying each module metapackage to depend on an exact version of the corresponding linux-image metapackage. For example:

Package: virtualbox-ose-modules-generic
Depends: virtualbox-ose-modules-2.6.26-5-generic, linux-image-generic (= 2.6.26.5.7)

Then kernel upgrades would be held back by default until all the wanted modules are available for the new kernel.

[Pascal d'Hermilly (pascal-tipisoft)]

Now, after rolling linux-image-2.6.24-21 out, my virtualization will be broke again. Last time it took almost a week before it worked again.

I think Anders proposes a good idea. Now, how does this practice become spread out? I suppose this message has got to go out to the maintainers, right?

[Daniel Hahler (blueyed)]

That won't work, since the old images still are available (and therefore won't cause a conflict).
Apart from that, a missing kernel module (from universe) should not block a security kernel update.

There's a solution in sight (DKMS, IIRC) for Intrepid. Somebody wanted to look into it, but it does not look that there's a solution yet.

There's a method/workaround to manually build the module using module-assistant though (some m-a commands) - it gets often posted to bug reports "like this one".

[Anders Kaseorg (andersk)]

> That won't work, since the old images still are available (and
> therefore won't cause a conflict).

I don’t understand your objection. Note that the goal is not to conflict with any kernel image packages, but only with new versions of the linux-image-generic _metapackage_, which is responsible for causing new ABI-incompatible kernel image packages to be automatically installed.

I know that this strategy works, because we have successfully used it for openafs kernel modules in the Debathena project <http://debathena.mit.edu/>.

> Apart from that, a missing kernel module (from universe) should
> not block a security kernel update.

No upgrades will be blocked unless the user installs the virtualbox-ose-modules-generic package, which is as good an indication as any that the user _needs_ a kernel with virtualbox modules, and a security kernel update that comes without modules is worse than useless for them. If the user wants to make a different choice, they can either install virtualbox-ose-modules-2.6.26-3-generic instead of virtualbox-ose-modules-generic, or they can install linux-image-2.6.26-5-generic anyway when it becomes available (since only the linux-image-generic metapackage is held back).

Even a user that does install virtualbox-ose-modules-generic will see that the new kernel upgrade is available. I’ve tried this with apt-get, aptitude, synaptic, adept, and update-manager—they will all notice the conflict, and either report that updates were held back, or propose resolving it by removing virtualbox-ose-modules-generic. In either case it should be clear what’s going on. This is infinitely better than the current solution which will silently break packages that the user wants to use.

[Lothar (lothar-tradescape)]

I also don't see why providing the module would be a problem anyway. It's open source and as long as the kernel changes are not breaking the build of that module it should always be delivered with the new kernel.

[Wouter Stomp (wouterstomp-deactivatedaccount)]

According to the release notes, intrepid alpha 5 now includes dkms. Could this be used to solve this problem?

[Duncan Hawthorne (duncan.hawthorne)]

this is done now in ubuntu intrepid

[Pascal d'Hermilly (pascal-tipisoft)]

Yes. DKMS seems like a really good way of doing it.

Unfortunatly it doesn't work very well for Virtualbox yet.
This is what I get when I start virtualbox, even though I have the packages installed and the module is compiled everytime I kernel-upgrade:
-------------------------
WARNING: The character device /dev/vboxdrv does not exist.
         Please install the virtualbox-ose-source package and the appropriate
         headers, most likely linux-headers-generic.

         You will not be able to start VMs until this problem is fixed.
-----------------------

Is there a way to recompile the modules manually to see exactly what is happening?

//Pascal

[Duncan Hawthorne (duncan.hawthorne)]

try doing /etc/init.d/vboxdrv restart, then running virtualbox. if that works read on:

if you have been doing an upgrade on intrepid for a while, you are stuck with some old settings that dont work (but have since been fixed on fresh installs)
if you remove and purge all the virtualbox stuff, and reinstall, all should be good from now on.

and of course, be sure to install virtualbox and virtualbox-ose-source packages

mark this bug as fix released if this fixes your problems

[Pascal d'Hermilly (pascal-tipisoft)]

It finds vboxdrv now.

However, now VirtualBox reports the following error:

VirtualBox can't operate in VMX root mode. Please disable the KVM kernel extension, recompile your kernel and reboot.
VBox status code: -4011 (VERR_VMX_IN_VMX_ROOT_MODE).

Does this mean I can't have kvm installed in parralel or does it mean that the new kernel has been compiled with something that virtualbox can't handle?
I'm using the standard kernel:
Linux pascal-laptop 2.6.27-7-generic #1 SMP Fri Oct 10 03:55:24 UTC 2008 i686 GNU/Linux

[Daniel Hahler (blueyed)]

I'm closing this bug as "Fix Released" since in Intrepid virtualbox-ose uses dkms to automatically build the kernel module for ABI bumps.

Pascal, please file a new bug report for your new issue. Sorry, I cannot say anything about the combination of kvm/virtualbox: it works for me using the standard/generic kernel just fine.
Have you installed anything kvm specific (which may cause the conflict then)?
But as said, please report a new bug (or find an appropriate one) and provide this information there, too.