Why Grub2 doesn't solve my Ubuntu kernel problem

September 27, 2010

A commentator on this entry asked what sounds like a good question: why don't I have Grub2 boot the older kernel that I want to use, instead of removing the newer one?

The problem is that it's not a robust solution. The first and largest issue is that what I really want to do is enforce a negative ('never boot this specific kernel'), but the only tool Grub gives me is a positive one ('boot this specific kernel'). There are a number of plausible situations that cause what kernel I want to boot to change; for example, if Ubuntu releases a new kernel update that is anything but a point version. In any of these situations, I lose.

The other issue is specific to my somewhat unusual situation and how Ubuntu packages kernel updates, but cannot be fixed even with a true negative option in Grub. Suppose, not entirely hypothetically, that Ubuntu gets around to releasing some version of their proposed kernel update as an official update. This official update will have the 32-on-64 security fix, and we will want to run it. However, it's quite possible that Ubuntu will make it a point release of the general proposed kernel update version. As already established, such a point release increase will use exactly the same kernel names and file names as the current proposed kernel update, and as such Grub will see it as exactly the same kernel. Even with a true negative option, there is no way for Grub to get this one right (short of reaching into the packaging system to pull out detailed metadata on just what exactly the kernel is).

The only way to fix both issues is to make the undesirable kernel disappear and then to have Grub do its normal thing of 'default to the highest version kernel'. Only then will any normal Ubuntu kernel update do the right thing.

(If this was a bad kernel update from the regular Ubuntu repositories, instead of a proposed testing one from elsewhere, I would then have to arrange to block reinstallation of that specific version of the kernel package.)


Comments on this page:

From 195.26.247.141 at 2010-09-27 05:30:44:

If you get a bad kernel update, then just don't install it. You can blacklist installs of packages, as long as nothing else explicitly depends on that exact version.

(I assume you have machines for testing, duplication of services where possible, etc)

Packaging mess-ups like overwriting existing installed kernels are rather serious, and a good reason to stay away from Ubuntu for important services if they continue to do such horrible things...

Written on 27 September 2010.
« The problems with OpenSolaris
Why there is no POSIX standard for a Unix GUI »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Sep 27 02:35:22 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.