Why we hold kernels and other packages on our Ubuntu machines

October 12, 2015

Apparently, it may be the case that if you do not hold kernels and other packages on your Ubuntu machines, 'apt-get autoremove' may do what I want for limiting installed Ubuntu kernels. Unfortunately this is not an option for us (and we're probably not alone in this).

Our fundamental rule is that for certain sorts of packages, we install or update them only occasionally, under controlled circumstances. For kernels, this is because reboots must be planned (and we don't like divergent kernel versions on different machines). For various other packages like GRUB, it's because their package updates have historically caused problems for our hands-off update mechanisms.

(And for some packages it is because they're so sensitive that we can't risk an update unless we're very sure it's going to work well, and we've been burned before by even theoretically small updates. Our Samba servers do not update their Samba versions unless we explicitly tell them to, for example.)

In RHEL/CentOS, we can do this manually during update time by explicitly excluding those package, eg 'yum update --exclude "kernel*"', and in fact we routinely do this when doing updates on our RHEL machines. However, as far as I can see apt-get has no such on the fly mechanism; instead, you must explicitly hold these packages and then explicitly do something to force them to be updated later. Problems here are compounded by how 'apt-get upgrade' does not update packages that have new dependencies. Since Ubuntu installs new kernels by updating the dependencies of the meta-packages (eg linux-image-generic), we must override this behavior too. Oh, and we only want to do this for whatever we're specifically doing at the time, not all packages that we've held.

It's possible that the official process we should be following is un-holding just the kernel packages and then doing 'apt-get dist-upgrade', never mind the somewhat scary warnings in the documentation for dist-upgrade. In practice it's unlikely that we're going to switch to a more complex and less controlled update mechanism just to perhaps have 'apt-get autoremove' remove obsolete kernel packages.

(Less controlled? Yes, as 'apt-get dist-upgrade' will upgrade (with new dependencies) any and all packages that are being held back for this reason, not just kernel packages. We have seen such held back packages want to do rather significant violence to the current package sets of systems for whatever inscrutable Ubuntu reasons. It's possible that this is because the new package version 'recommends' a pile of additional things and apt is defaulting to installing them too, which seems to be a problem with 'apt-get install' for us. The whole situation with this irritates me, but that's another rant.)

Written on 12 October 2015.
« Bad news about how we detect and recover from NFS server problems
Why I've come to really like git »

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

Last modified: Mon Oct 12 00:59:17 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.