I've written before about the over-arching problems with how Debian and Ubuntu package kernels, but today I ran into another annoying issue with how Ubuntu handles their kernel packaging mess.

The problem Ubuntu has is that their kernel packages need to have the kernel version as part of the package name, but they want to create a simple way of upgrading from kernel to kernel without too much special magic in the tools (as an entirely new package, a new kernel is not an upgrade for any existing package so package managers will just ignore it). So Ubuntu has kernel meta-packages, things like linux-image-server, that exist only to depend on the current specific kernel packages. When Ubuntu releases a new kernel they release a new version of the meta-packages that depend on the new kernel's new package, and so upgrading your meta-package pulls in the new kernel as a dependency.

Now suppose that you want to remove the most recent kernel version for some reason; perhaps it's no good and you're taking the easiest way to avoid having it be the default kernel that your system boots.

In an RPM-based environment you can just rpm -e this kernel, just as you would any other kernel that you wanted to get rid of. On Ubuntu this fails, because the most recent kernel is a dependency of the kernel meta-package (and you don't want to remove the meta-package). In order to remove the most recent kernel, you need to find some way to revert to an old version of the meta-package (one that depends on an older kernel version).

(At this point it may be useful to point at /var/cache/apt/archives.)

The mess with the meta-packages wouldn't be necessary if Ubuntu didn't have to give each new kernel version a completely different package version, and that wouldn't be necessary if the Debian package system allowed more than one version of a single package to be installed at once. Sadly, this single version assumption seems to be very deeply embedded in how the Debian package system stores various bits of data about packages.

Sidebar: what happened to us

Ubuntu 10.04 has an issue where (among other things) unmounting NFS filesystems takes seconds to tens of seconds; this leads to very, very slow system reboots when you have more than 200 NFS mounts, as we do. They had a proposed kernel update that should fix this and that needed testing to verify this, so I installed it on one of our Ubuntu 10.04 test machines. In the process I also wound up installing the kernel meta-package that went with it.

Today, Ubuntu came out with a security update for the recently disclosed 32-bit emulation on 64-bit kernels local root exploit. Presumably because this was an urgent security issue, they did not release some version of the proposed kernel update but instead patched the older official 10.04 kernel. Which left me wanting to get rid of the proposed kernel update that I had installed, which is where I ran into the meta-package issue.