Ubuntu Kernel Source
Obtaining the source for an Ubuntu release
There are a number of different ways of getting the kernel sources. The two main ways will be documented here.
If you have installed a version of Ubuntu and you want to make changes to the kernel that is installed on your system, use the apt-get method (described below) to obtain the sources.
However, if you wish to get the most up to date sources for the Ubuntu release you are running and make changes to that, use the git method (described below) to obtain the sources.
Obtaining the kernel sources for an Ubuntu release using apt-get
The literal source code which generated a specific binary package may be obtained using the apt-get source <package> command. For example to obtain the source for the currently running kernel you can use the command below:
apt-get source linux-image-unsigned-$(uname -r)
or failing that:
apt-get source linux-image-$(uname -r)
Obtaining the kernel sources for an Ubuntu release using git
The source for each release is maintained in its own git repository on Launchpad.
The git repository is listed in the Vcs-Git: header in the source package and is of the following form:
For example, the standard Cosmic kernel is available at:
There is a tree for each of the currently supported releases as well as any open development and upcoming releases:
Replace your intended OS series in the above, and pull the source for the kernels you need.
The distro kernel is always on the master branch in these repositories. Each release also has a master-next branch containing the commits that will go onto the master branch and become the next release for that release.
A number of releases also have other source packages which represent other related but divergent kernels for other purposes. For example, there is a specialized AWS kernel available in the linux-aws source package. (Previously these sorts of things were done in Topic Branches and some older kernels and projects still use them.)
If you cannot use the git protocol (perhaps because of a firewall), you can use the slower http protocol. For example:
Obtaining a copy
To obtain a local copy you can simply git clone the repository for the release you are interested. The git command is part of the git package.
For example to obtain the Bionic tree:
This will download several hundred megabytes of data. If you plan on working on more than one kernel release you can save space and time by downloading the upstream kernel tree. Note that once these two trees are tied together you cannot remove the virgin Linus tree without damage to the Ubuntu tree:
git clone git://kernel.ubuntu.com/ubuntu/linux.git git clone --reference linux git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/groovy
In each case you will end up with a new directory ubuntu-<release> containing the source and the full history which can be manipulated using the git command from within each directory.
By default you will have the latest version of the kernel tree, the master tree. You can switch to any previously released kernel version using the release tags. To obtain a full list of the tagged versions in the release as below:
$ git tag -l Ubuntu-* Ubuntu-5.4.0-47.51 Ubuntu-5.4.0-48.52 Ubuntu-5.4.0-49.53 Ubuntu-5.4.0-51.56 Ubuntu-5.4.0-52.57 $
To look at the Ubuntu-5.4.0-52.57 version you can simply checkout a new branch pointing to that version:
git checkout -b temp Ubuntu-5.4.0-52.57
You may then manipulate the release - for example, by adding new commits.
Apply patches using git cherry-pick
To apply individual patches from an upstream kernel tree to your current Ubuntu kernel tree use the following command:
git cherry-pick -s -e -x <SHAID>
Where, SHAID is the commit ID of the patch you want to apply.
Set up chroot build environment
Get the automated chroot build scripts
A common set of tools used by the kernel team are maintained in a git repository.
- buildscripts: Scripts used to farm out the kernel builds to very fast remote
- chroot-setup: Scripts to setup jailed kernel compilation enviroments.
- daily-test-isos: Scripts and support files to produce daily, custom test isos.
- git-hooks: Optional hooks to help you commit patches
- maintscripts: Scripts used for general / stable kernel maintenance
- mainline-build: Scripts to produce .debs for mainline kernels
- misc: Everything else...
Download them using the following command.
git clone git://kernel.ubuntu.com/ubuntu/kteam-tools.git kteam-tools
Create the chroot environment
To automatically create the chroot environment use:
chroot-setup/make_chroot <suite> <arch> [<mirror>]
sudo mkdir -p /usr3/chroots # prep environment sudo chroot-setup/make_chroot precise amd64 http://archive.ubuntu.com/ubuntu
- arch stands for different arch supported by the CPU, for example i386 on AMD64 or LPIA on i386 etc.
- suite stands for release name such as hardy, gutsy, intrepid etc.
mirror stands for the http location to download environment from, http://host[:port]/dir/
Note: You don't need to specify a mirror when using the LPIA arch
Packages required on a build system
Please make sure that the following packages are installed on your system.
And optional packages
Install build system package requisites
Certain packages are required to be installed on the build system. You can install these packages using the following command:
sudo apt-get install git-core debhelper build-essential fakeroot kernel-wedge makedumpfile
Optionally you may also install the following packages that might help debuild to function flawlessly.
sudo apt-get install ccache devscripts xmlto docbook-utils gs transfig sharutils libdw-dev libdw1 libelf-dev
Building the kernel packages
chroot into the build environment
Depending on what may be installed on your system you may use "dchroot" or "schroot" to chroot into the build environment.
schroot -c lucid-i386
You should chroot into a 64bit build environment to build 64bit kernel package, 32bit build environemt to build 32bit kernel package.
Setup the build tree
This step generates the debian control files required to build the kernel. The clean target is a bit of a misnomer here since we moved the generated files (control.stub, control) out of version control. The clean target actually creates these files. It is a known drawback, and unavoidable.
fakeroot debian/rules clean
Modify the debian/changelog file to reflect something unique about this build, for example, you may use a launchpad bug number that you might be building this kernel for.
Modify the the first line, for example:
linux (2.6.27-12.28) UNRELEASED; urgency=low
linux (2.6.27-12.28~lpNNNNNNUSERNAME1) UNRELEASED; urgency=low
Build the kernel package
- Arch specific builds:
fakeroot debian/rules binary-generic
- All arches:
fakeroot debian/rules binary-arch
Build the kernel header, source, doc packages
The following will build the header, source, doc packages.
fakeroot debian/rules binary-indep