How Ubuntu and Fedora each do kernel packages
I feel the need to say things about the Ubuntu (and I believe Debian)
kernel update process, but before I do that I want to write down
how kernel packages look on Ubuntu and Fedora from a sysadmin's
perspective because I think a number of people have only been exposed
to one or the other. The Fedora approach to kernel packages is also
used by Red Hat Enterprise Linux (and CentOS) and probably other
Linux distributions that use
yum and RPMs. I believe that the
Ubuntu approach is also used by Debian, but maybe Debian does it a
bit differently; I haven't run a real Debian system.
Both debs and RPMs have the core concepts of a package having a
name, an upstream version number, and a distribution release number.
For instance, Firefox on my Fedora 21 machine is currently
37.0, and release
2.fc21 (increasingly people
embed the distribution version in the release number for reasons
beyond the scope of this entry).
On Fedora you have some number of
kernel-... RPMs installed at
once. These are generally all instance of the
kernel package (the
package name); they differ only in their upstream version number and
their release number. Yum normally keeps the most recent five of
them for you, deleting the oldest when you add a new one via a '
upgrade' when a new version of the
kernel package is available.
This gives you a list of main kernel packages that looks like this:
kernel-3.18.8-201.fc21.x86_64 kernel-3.18.9-200.fc21.x86_64 kernel-3.19.1-201.fc21.x86_64 kernel-3.19.2-201.fc21.x86_64 kernel-3.19.3-200.fc21.x86_64
kernel RPM with upstream version
3.19.3 and Fedora
200.fc21 is the most recent kernel I have installed
(and this is a 64-bit machine as shown by the x86_64 architecture).
(This is a slight simplification. On Fedora 21, the kernel is actually
split into three kernel packages:
kernel package for a specific version is just
a meta-package that depends (through a bit of magic) on its associated
kernel-modules packages. Yum knows how to manage all
of this so you keep five copies not only of the
but also of the
kernel-modules packages and so on.
Mostly you can ignore the sub-packages in Fedora; I often forget about
them. In RHEL up through RHEL 7, they don't exist and their contents are
just part of the
kernel package; the same was true of older Fedora
Ubuntu is more complicated. There is a single
(meta-)package installed on your system and then some number of
packages with the package name of
linux-image-<version>-<release>-generic for various <version> and
<release> values. Each of these packages has a deb upstream version
of <version> and a release version of <release>.<number>, where the
number varies depending on how Ubuntu built things. Each specific
linux-image-generic package version depends on a particular
linux-image-<v>-<r>-generic package, so when you update to it it
pulls in that specific kernel (at whatever the latest package release
of it is).
Because of all of this, Ubuntu systems wind up with multiple kernels
installed at once by the side effects of updating
A new package version of l-i-g will depend on and pull in an
linux-image-<v>-<r>-generic package, leaving the old
linux-image-*-generic packages just sitting there. Unlike with
nothing in plain
apt-get limits how many old kernels you have sitting
around; if you leave your server alone, you'll wind up with copies of
all kernel packages you've ever used. As far as the Ubuntu package
system sees it, these are not multiple versions of the same thing but
entirely separate packages, each of which you have only one version
This gives you a list of packages that looks like this (splitting
apart the package name and the version plus Ubuntu release, what
dpkg -l' calls
linux-image-3.13.0-24-generic 3.13.0-24.47 linux-image-3.13.0-45-generic 3.13.0-45.74 linux-image-3.13.0-46-generic 3.13.0-46.79 linux-image-3.13.0-48-generic 3.13.0-48.80 linux-image-generic 220.127.116.11.55
(I'm simplifying again; on Ubuntu 14.04 there are also
On this system, the current 18.104.22.168.55 version of linux-image-generic
depends on and thus requires the linux-image-3.13.0-48-generic
package, which is currently 'at' the nominal upstream version
3.13.0 and Ubuntu release
48.80. Past Ubuntu versions of
linux-image-generic depended on the other linux-image-*-generic
packages and caused them to be installed at the time.
I find the Fedora/RHEL approach to be much more straightforward than the Ubuntu approach. With Fedora, you just have N versions of the kernel package installed at once; done. With Ubuntu, you don't really have multiple versions of any given package installed; you just have a lot of confusingly named packages, each of which has one version installed, and these packages get installed on your system as a side effect of upgrading another package (linux-image-generic). As far as I know the Ubuntu package system doesn't know that all of these different named packages are variants of the same thing.
(A discussion of some unfortunate consequences of this Ubuntu decision is beyond the scope of this entry. See also.)
Sidebar: kernel variants
Both Ubuntu and Fedora have some variants of the kernel; for instance,
Fedora has a PAE variant of their 32-bit x86 kernel. On Fedora, these
get a different package name,
kernel-pae, and everything else works in
the same way as for normal kernels (and you have both PAE and regular
kernels installed at the same time;
yum will keep the most recent five
On Ubuntu I believe these get a different meta-package that replaces
linux-image-generic, for example
versions of this package depend on specific kernel packages with
different names, like linux-image-<v>-<r>-lowlatency. You can see
the collection with '
apt-cache search linux-image'.
Both Fedora and Ubuntu have changed how they handled kernel variants over time; my memory is that Ubuntu had to change more in order to become more sane. Today their handling of variants strikes me as reasonably close to each other.