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:

  • git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/<source package>/+git/<series>

For example, the standard Cosmic kernel is available at:

  • git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/cosmic

There is a tree for each of the currently supported releases as well as any open development and upcoming releases:

  • groovy






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:

  • git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic

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-*

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.

Applying Patches

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>]

For example:

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.

  • git-core
  • debhelper
  • build-essential
  • fakeroot
  • kernel-wedge

And optional packages

  • ccache
  • devscripts
  • xmlto
  • docbook-utils
  • gs
  • transfig
  • sharutils

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.

For example:

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 debian/changelog

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

Kernel/Dev/QuickBuildLocal (last edited 2010-07-20 10:29:33 by manjo)