KernelMaintenanceStarter

Differences between revisions 1 and 2
Revision 1 as of 2008-01-10 19:05:47
Size: 4257
Editor: 245
Comment: Initial version
Revision 2 as of 2008-01-11 00:31:14
Size: 5481
Editor: 245
Comment:
Deletions are marked like this. Additions are marked like this.
Line 23: Line 23:
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:

 *
Line 59: Line 79:
'''Note:''' When using dpkg to install the package created by the binary-headers package, I had to create ''/lib/modules/<version> directory and the softlink called ''build'' from that directory to ''/usr/src/linux-headers-<version>, manually. '''Note:''' When using dpkg to install the package created by the binary-headers package, I had to create ''/lib/modules/<version> directory and the softlink called ''build'' from that directory to ''/usr/src/linux-headers-<version>, manually. (''version'' being for example ''2.6.24-4-generic'')
Line 95: Line 115:
{{{
sudo chroot <target>
apt-get-install git-core debhelper build-essential fakeroot kernel-wedge
}}}

I personally liked to work with my normal user within that environment. So I did the following optional steps _before_ the ''chroot'':
I personally like to work with my normal user. So the next step is rather optional:
Line 107: Line 122:
'''Note:''' The bind mount, as far as I know, has to be done after each reboot. This will allow to ''su'' to any user that is able to login to the main system. For a more complete environment /dev could be bind moounted as well.

'''Note:''' The bind mount step(s), as far as I know, has to be done after each reboot.

After that it is possible to change into the new environment by

{{{
sudo chroot <target>
}}}

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

Include(KernelTeamHeader)

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:

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 are fetched like described in the KernelGitGuide. In the top-level kernel directory

fakeroot debian/rules binary-arch

will build the binary packages for all kernel [https://wiki.ubuntu.com/KernelMaintenance#head-2568e78ff098da48bf1dac0dcb64c5263833e7cb 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: When using dpkg to install the package created by the binary-headers package, I had to create /lib/modules/<version> directory and the softlink called build from that directory to /usr/src/linux-headers-<version>, manually. (version being for example 2.6.24-4-generic)

Building linux-user-modules

First get the source

git clone git://kernel.ubuntu.com/ubuntu/ubuntu-hardy-lum ubuntu-hardy-lum

Then check for the ABI version (debian/changelog) and install the linux-headers 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 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.

I personally like to work with my normal user. So the next step is rather optional:

sudo cp /etc/passwd /etc/shadow /etc/group /etc/sudoers <target>/etc
sudo mount --bind /home <target>/home

This will allow to su to any user that is able to login to the main system. For a more complete environment /dev could be bind moounted as well.

Note: The bind mount step(s), as far as I know, has to be done after each reboot.

After that it is possible to change into the new environment by

sudo chroot <target>

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

KernelTeam/KernelMaintenanceStarter (last edited 2015-11-24 06:23:03 by anthonywong)