How I get a copy of the Ubuntu kernel source code (as of Ubuntu 18.04)
For unfortunate reasons beyond the scope of this entry, I've recently needed to once again take a look at the Ubuntu kernel source code, as they're patched and modified and so on from the upstream versions. There are some things where I'll just look at the official kernel source, but for certain sorts of issues, nothing short of the real kernel we're using (or something close to it) will do. Every time I do this I have to re-discover or re-work out how to get a copy of this source code, so this time around I'm going to write it down. The necessary disclaimer is that Ubuntu may change all of this in the future.
There are two approaches you can take here, depending on what you
want. I'll start with the more obvious one, using
theory, what you should be able to do is to just '
on the kernel that you're running, in other words generally:
apt-get source linux-image-$(uname -r)
If you try this, you will get a 'linux-signed' source package, which
does not actually contain any kernel source. It turns out that what
you really want is the source package for the linux-image-unsigned
package. This is the '
linux' source package, so you can do either
of the following commands:
apt-get source linux-image-unsigned-$(uname -r) apt-get source linux
In either case, you end up with the most recent kernel source
package, which is not necessarily the source code to the kernel
that you're actually running. Unfortunately there's no guarantee
that Ubuntu still has the
linux source package for your specific
kernel available as a source package; they appear to purge old ones
from mirrors, just as they purge the old binary packages.
The other approach is the one recommended by Ubuntu and which a
apt-get source' will nag you about, which is to clone
it from Ubuntu's kernel git tree. At the moment (here at the start
of 2019), you can find information on this in Ubuntu's KernelGitGuide
wiki page or
their page on kernel source
(note that this page is incorrect about apt-get). The Ubuntu 18.04
LTS git tree is here,
although per Ubuntu's wiki page, you should clone it with the
protocol URLs. As you can see, there are a variety of tags and
branches in the repo, and I think they're all reasonably obvious
(and there's some explanation of them in the Ubuntu wiki pages).
In the '
apt-get source' version, the Ubuntu package changelog is
debian/changelog; this is what you want to consult if you're
looking for relevant bug fixes and so on. In the git version, the
debian.master/changelog and the '
has other things. In the git version, Ubuntu generally commits
individual Ubuntu changes as individual git commits, which means
that you can use '
git log' to scan for Ubuntu changes to particular
files or directories of interest. Because the git version has tags
for specific releases, it's also the easiest way to see the Ubuntu
kernel tree as of a specific
linux-image version (or to see the
differences between two of them, perhaps in a sub-tree).
For instance, suppose you want to see all changes since Ubuntu's 4.15.0-30 in some areas of the tree. You could do:
git log Ubuntu-4.15.0-30.32.. -- fs/sysfs fs/namei.c fs/inode.c fs/dcache.c
A specific commit can then be shown with '
git show <id>' as usual,
which will show you the diff as well as its commit message.
Ubuntu's kernels have the ZFS on Linux
kernel module code in top-level '
spl' and '
The user level tools are in a separate set of packages with their
own source package, '
zfs-linux'. Apt-getting this source package
will produce a claim that it is really maintained in Debian GIT,
but I'm not sure that's actually true for the Ubuntu version. While
this source package still includes the kernel module source code,
I believe only the user level stuff is used. I'm not sure how Ubuntu
manages changes to all of this, but they appear to keep everything
in sync somehow.
(In Ubuntu 20.04, there will likely only be a single '
directory, since ZFS on Linux has merged the 'spl' package into the
'zfs' one in its development version.)
In theory Ubuntu has instructions on building packages from the git
and they were even updated within the past year. In practice I have
no idea, since I haven't ever built a new Ubuntu kernel package,
but I would probably be inclined to start from '
linux', because that's at least in a format that I sort of understand.
Of course, if I had to build a modified version of a specific, no
longer current linux-image version, I might have to use the git
version because that's the only way I can get the exact source code.
(Perhaps this means we should be routinely saving the kernel source
packages for important kernels that we use. Sadly it's now too late
to do this for the kernel that our Linux fileservers use; we froze their kernel version some time
ago and the '
linux' source package for it is long gone now.)
Comments on this page:Written on 02 January 2019.