The yum versionlock problem

July 27, 2008

Update: I'm wrong about this. See the comments for more details.

Since I alluded to this issue recently, here is the problematic interaction between yum's versionlock plugin, which is used to 'pin' a particular version of a package so that it won't get upgraded, and yum's installonly feature, which is used by Red Hat and Fedora to keep only some number of kernels (by default 2).

Here is the problem sequence:

  • you are running version X of the kernel without problems.
  • Fedora releases version Y, so you yum update to it.
  • when you reboot into version Y, you discover that it has a problem (for example, it reliably panics on your hardware, or your Ethernet card performance goes way down).
  • you reboot back into version X, which still works.
  • you want to keep version X around until Fedora releases a new kernel that works, so you list version X of the kernel in /etc/yum/pluginconf.d/versionlock.list to 'pin' it.
  • Fedora releases a new kernel, version Z, and you 'yum update' to it.

What you expect to happen during the update is that yum will apply the 'only 2' default kernel policy but notice that version X is pinned and so either keep three versions around (two regular ones plus one pinned version) or remove kernel version Y. Instead yum removes your pinned version X and leaves you with only Y and Z (both of which may be broken).

Technically speaking this is not a bug as such, because the versionlock plugin does not promise to prevent a package's removal, it just protects it from being updated by newer versions; the kernel you locked isn't being updated, it's just being removed as a side effect of updating another package. But I do think it is both surprising and the wrong thing for yum to do, and that versionlock should prevent a package from being removed for any reason.

There are two workarounds. First, you can increase the number of copies of the kernel that are kept around (and remember to keep increasing it if kernel updates come out that don't fix the problem that keeps you at version X). Second, you can remove every version Y that doesn't fix the problem so that you only have one kernel version (version X) sitting around, although you'll have to not versionlock it if you want to update to new kernel versions to try them out.


Comments on this page:

From 65.172.155.228 at 2008-07-27 16:46:51:

Here is the problem sequence:

  * you are running version X of the kernel without problems.
  * Fedora releases version Y, so you yum update to it.
 [...]
  # Fedora releases a new kernel, version Z, and you 'yum update' to it.

But you'd have to disable versionlock to do the above, unless I'm missing something. For instance right now I have:

% sudo yum --showduplicates ls kernel
Loaded plugins: aliases, changelog, fastestmirror, filter-data, list-data,
              : security, tmprepo
Loading mirror speeds from cached hostfile
 * fedora: fedora.mirrors.tds.net
 * updates: fedora.mirrors.tds.net
Installed Packages
kernel.i686                              2.6.25.6-55.fc9        installed       
kernel.i686                              2.6.25.9-76.fc9        installed       
kernel.i686                              2.6.25.10-86.fc9       installed       
kernel.i686                              2.6.25.11-97.fc9       installed       
Available Packages
kernel.i586                              2.6.25-14.fc9          fedora          
kernel.i686                              2.6.25-14.fc9          fedora          
kernel.i586                              2.6.25.11-97.fc9       updates         

...but if I install versionlock and have:

% cat /etc/yum/pluginconf.d/versionlock.list
kernel-2.6.25.6-55.fc9.i686

...then I get:

% sudo yum --showduplicates ls kernel
Loaded plugins: aliases, changelog, fastestmirror, filter-data, list-data,
              : security, tmprepo, versionlock
Loading mirror speeds from cached hostfile
 * fedora: fedora.mirrors.tds.net
 * updates: fedora.mirrors.tds.net
Reading version lock configuration
Installed Packages
kernel.i686                              2.6.25.6-55.fc9        installed       
kernel.i686                              2.6.25.9-76.fc9        installed       
kernel.i686                              2.6.25.10-86.fc9       installed       
kernel.i686                              2.6.25.11-97.fc9       installed

...ie. versionlock does what it does and removes every other version from the repos. ... the only way to even see a new kernel update at this point is to disable versionlock in some way. At which point, sure, versionlock isn't going to stop anything removing anything because it won't even be there. But if you remove everything except the working kernel then install_only won't be getting rid of it even at 2.

What am I missing?

From 65.172.155.228 at 2008-07-27 16:54:56:

Technically speaking this is not a bug as such, because [...] just protects it from being updated by newer versions; the kernel you locked isn't being updated, it's just being removed as a side effect of updating another packag

The way versionlock works (at least the version I'm looking at in the git repo -- but I don't think it's changed) is that it takes a package name and version, it then searches for all packages in all repos. with that name and "excludes" any with a different evr (epoch, version, release). So atm. it's biggest "feature" is that it doesn't work through obsoletes (as the name changes) ... but I can't see how it'd work differently for installonly pkgs vs. normal ones (and AFAICS it does).

By cks at 2008-07-27 23:20:26:

You're right; in testing a kernel update now I can't seem to reproduce the behavior I was seeing (or that I thought I was seeing; it is quite possible that I misread 'yum update' output the last time I tried this).

I think that versionlock is at least confusingly documented, given the peculiar behavior that it gives kernel updates if you versionlock a kernel. Something more like pinning would be more useful.

Written on 27 July 2008.
« dict.setdefault() as a concurrency primitive
Another advantage of Python builtins »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Sun Jul 27 00:46:16 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.