KernelMaintenanceStarter

Revision 9 as of 2008-09-26 16:30:13

Clear message

This document is based on the KernelMaintenance page and meant to be a more elaborate version for people (like me) that are not familiar with the Debian build system.

Basic system setup

For doing kernel maintenance there are a few packages required:

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

Those can be installed by calling

sudo apt-get install git-core debhelper build-essential fakeroot kernel-wedge

Without the packages above, the kernel build will not work. But there are some more to make the system more complete (or life simpler).

First there is the ccache package, which speeds up rebuilds. After installing the package /usr/lib/ccache should become the first item in the '$PATH' environment. The directory contains link substitutions for compiler binaries , so gcc, for example, is automatically done with caching. To do so, the following section could be used in the .bashrc file:

if [ -d /usr/lib/ccache ]; then
        export PATH=/usr/lib/ccache:"${PATH}"
        export CCACHE_NLEVELS=8
fi

Second there is the devscripts package, which contains (beside of other stuff) the debuild script. This can be used to check whether all build dependencies are met by the current installation. After calling

debuild -b

on my system, the script choke up the following additional packages that should be installed:

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

After installing those, the debuild run runs quite a while, up to the stage where some upload packages are tried to be signed for the user that created the last debian/changelog entry (which usually isn't somebody reading this document).

Build system breakdown

Building is done by calling debian/rules [<target>] (which is a executable makefile). The call should be given a target name (though for the kernel the default seems to be something like make all). The debian defined targets are:

  • clean
  • binary
  • binary-arch
  • binary-indep
  • build
  • build-arch
  • build-indep

There are others for the kernel, LUM (linux user modules), LRM (linux restricted modules) and LBM (linux backport modules) which are Ubuntu specific and will be explained later on.

Building the kernel

First, the kernel sources have to be fetched. This can either be done as described in the KernelGuide or in the following way (which enables useing git push to work but requires a valid user id on zinc.ubuntu.com):

git clone <user>@zinc.ubuntu.com:/srv/kernel.ubuntu.com/git/ubuntu/ubuntu-hardy.git <dir>

In the top-level kernel directory

fakeroot debian/rules binary-arch

will build the binary packages for all kernel flavours. The packages itself will go, by Debian convention, to the directory one level above the current directory. Other files created during the process are located in the debian directory.

In order to compile only a specific flavour, the name of that can be used instead of arch, like in the following example:

fakeroot debian/rules binary-generic

Another special target is binary-headers which creates an architecture independent package which contains just the kernel headers. This has to be installed before compiling any modules packages.

fakeroot debian/rules binary-headers

Note: The headers package generated by calling this target is not sufficient to build linux modules. This also requires the flavour specific headers package generated by calling the binary-<flavour> target.

Building linux-ubuntu-modules

First get the source

git clone <user>@zinc.ubuntu.com:/srv/kernel.ubuntu.com/ubuntu/ubuntu-hardy-lum.git <dir>

Then check for the ABI version (debian/changelog) and install the linux-headers (all and flavour specific) package that matches that and the flavour of modules that are to be build.

After that the modules can be build by

fakeroot debian/rules binary-modules-<flavour>

where flavour is one of generic, rt, ume, xen, etc.

Building in a chroot environment

This is useful to do builds for other architectures that are supported by the CPU (like LPIA (low power intel architecture) on i386 or i386 on x86_64) or to do builds for newer release without upgrading the whole machine.

There is an utility called debootstrap that will simplify this task a lot. First install it with apt-get, then call (as root)

debootstrap --arch <arch> <suite> <target>

This will create the directory target and then download and install a basic system in that directory. The suite is for example hardy and arch might be i386 or lpia.

Note: To be able to use hardy as a suite from a system install with gutsy, I had to enable gutsy-backports in the installation sources.

After debootstrap finishes successfully the chroot environment also has to be prepared for building.

Note: I usually copy /etc/hosts and /etc/sudoers into the chroot for some more comfort.

While chroot is also good to change into the chroot environment, there is a more comfortable way through the schroot package. This allows certain users to change the root and also can prepare the environment, so a normal user is able to work (including bind mounting /home)

This configuration in /etc/schroot/schroot.conf allows the user foo to switch into the chroot environment hardy:

[hardy]
type=directory
description=Ubuntu hardy
location=/srv/hardy-chroot
priority=2
users=foo
run-setup-scripts=true
personality=linux32

Note: The personality option is optional and only useful in a amd64 environment. But there it will automatically set up 32bit mode.

This is done by calling:

schroot -chardy

Of course this environment has to be prepared for building as it was described before.