Kernel Building

One of the scariest moments in many Linux users’ lives is the moment when they ask someone for help, and they get the reply, “You really have to/need to/should recompile your kernel to make that work.”

In this article, I hope to take some of the fear out of the process, and make it all a bit less intimidating. This article is aimed at the user who is familiar with the use (or at least the basic concepts) of file storage and the command line, but doesn’t necessarily know about compiling things from source.

What is a kernel?

The kernel is the most fundamental part of the operating system. It’s the Linux part of GNU/Linux (see :/GNUandLinux). It controls the memory allocation, handles the multitasking of applications, enforces some security controls, deals with the interfaces to all of the hardware (through device drivers), and manages the file storage on the machine (through filesystem drivers).

Why would I want to recompile it?

There could be several reasons to recompile your kernel. Among them:

• Optimising for your processor.
• Adding a driver or feature which wasn’t in the original kernel shipped by your distribution.
• Upgrading to a new kernel before your distribution packages it.
• Removing all the unused cruft from the “generic” kernels supplied by your distribution.
• Testing development kernels.
• Add a patch for a new piece of hardware

How do I recompile my kernel?

There are four stages you need to go through: get the sources & unpack, configure, compile, and install. The most complicated is the configuration. After that, it gets easier and, in general, considerably less intimidating.

Getting the sources

First, you will need the kernel source. Most distributions ship kernel source packages for various versions. These will almost always have additional patches in them, giving you extra features or bugfixes. Some of the vendor kernels (like Red Hat’s, for example) are very heavily modified. Take a look in your distribution’s package store for a suitable kernel source package.

There are also a large number of other kernel sources available – the most commonly-used one is the “official” one from Linus Torvalds, sometimes referred to as the “Linus”, or the “vanilla” kernel. These can be downloaded from http://www.kernel.org/ and its mirrors.

: Debian In debian, you can easily download the kernel source using apt-get (apt-get install kernel-source-VERSION). Depending on whether you are running “woody”, “sarge” or “sid” will depend on what “kernel-source” files are available.

: Gentoo In gentoo, you can easily download (the extraction happens automatically) the source by typing in one of the following commands, depending on which kernel you would like to run.

• for 2.4.x kernel, type emerge gentoo-sources

• for 2.6.x kernel, type emerge gentoo-dev-sources

After downloading the kernel source, unpack it. This will depend on the form that you got it in (Debian, for example, will unpack it automatically), but the standard “tarball” (linux-x.y.z.tar.gz or linux-x.y.z.tar.bz2) form from kernel.org can be unpacked with either

$ tar -xvzf linux-x.y.z.tar.gz

or

$ tar -xvjf linux-x.y.z.tar.bz2

depending on which one you downloaded. I would suggest doing this either in /usr/src or in /usr/local/src. (Note for the advanced: it is considered good practice, but not essential, to compile things as a non-root user. See LinuxHints/NonRootBuildEnvironment for more details.)

Patching

Download the patch file into /usr/src/ (in Debian, or /usr/local/src/ if you use that).

If it is a bz2 patch then $ bunzip2 nameofpatch.bz2. gz patch files should be unziped using the gunzip command.

Descent into the kernel directory ($ cd linux).

Dry run the patch: $ patch –dry-run -p1 < ../patchfile If all is good, patch the file properly (as above, remove the –dry-run).

There is a guide here

Configuration

If you already have a kernel configuration file (these are frequently installed in files such as /boot/config-x.y.z), then you can re-use that configuration by copying it into your kernel source tree and updating it:

$ cp /boot/config-x.y.z /usr/local/src/linux/.config

(assuming that you have your kernel source in /usr/local/src/linux, of course)

Then change to the root of your kernel source tree (e.g. $ cd /usr/local/src/linux), and run:

$ make oldconfig

Make oldconfig will ask you questions about the new features of the kernel source you’ve installed that weren’t in the old config file. In almost all cases, using the default option (just hit Return) is acceptable.

If you don’t have a previous kernel configuration file, or you want to configure from scratch, then (again, from the root of your kernel source tree) you can use either a text-based interface (“menuconfig”) or an X Window System interface (“xconfig”). The menuconfig interface requires the ncurses development libraries to be installed (apt-get install libncurses5-dev on Debian; libncurses-devel on Fedora). The xconfig inteface requires the Qt development libraries (libqt3-dev or libqt-devel) to be installed. The commands to start the two configuration interfaces are:

$ make menuconfig

or

$ make xconfig

It is also important to note that you must be in the correct directory to do this, that is change into the directory that contains the source that you have just extracted (cd /usr/src/kernel-source-2.6.5)

In either case, there are several hundred configuration options available, and the only real solution is to trudge through them all one at a time. Most options have help on them, and will suggest what to pick if you don’t know what you should be choosing. Fortunately, you will only have to do this once

You will need to know what hardware you have in your machine. lspci is likely to give you a good idea of what you have on your PCI bus. (Add -v for more verbose information. Add more v’s for more info.)

As to what to include in your kernel configuration, you will need at a minimum the following compiled into the kernel (selected as Y or *, rather than as M):

• The driver for your boot drive (e.g. IDE)
• The filesystem driver for your boot partition (e.g. ext3)

If you get a kernel panic on boot, saying that it can’t mount the root device, then you have almost certainly forgotten to build in one or other of the two items above.

After you’ve configured your kernel, you should probably take a copy of the configuration file and put it in a safe place. The file is called .config, and is in the main directory of your kernel source tree.

Building the kernel

you’re running Debian, you should probably skip to [[LinuxHints/KernelCompiling at this point.]]

Building a kernel is the easiest bit of the process, although possibly the longest as well. Just run (from your kernel source directory):

• for Kernel 2.4.x, type make bzImage

• for kernel 2.6.x, type make

If you are using modules (you chose [M] to any options when configuring), you should also run

for kernel 2.4.x and 2.6.x, type make modules

Note: In kernel version 2.6 the make commands are slightly different. Just a “make” with no parameters will do both of the above. You can type “make help” to get more information in 2.6 kernels.

This will take anywhere between a couple of minutes and several hours, depending on the number of features you configured in, the speed of the machine, and the vintage of the kernel. My K6-2/500 takes about an hour to compile a fairly feature-rich 2.4 kernel. It can do an empty-ish 2.0 kernel in a few minutes.

Installation

This section is incomplete.

 1. make modules_install  1. cp arch/i386/boot/bzImage /boot/vmlinuz-newkernel  1. nano /etc/lilo.conf  1. /sbin/lilo

Note: In 2.6 you can type “make install” and “make modules_install” to copy the boot image, run lilo, and copy all the compiled modules to the right place. Again, “make help” will help you here.