/read/online

21: Compiling Kernels The Debian Way

It seems Debian has its own special way of doing pretty much everything, including compiling kernels. Debian has a system that allows you to compile your kernel and automatically build a Debian package around it, allowing you to install a new kernel in the same way as you install any other package. It also means you can build a kernel on one machine and then just install the package on other machines without having to recompile or track down all the loose ends - great if you need to upgrade a number of similar machines!

Getting The Source

You can get the kernel source yourself directly from kernel.org or a mirror if you like, but of course there are even packages of the kernel source. A quick

apt-cache search kernel-source

will get you a list of kernel source packages all ready to go. Picking one as an example, you could just do

apt-get install kernel-source-2.4.20

to get the source downloaded to your system. You'll then end up with an archive sitting in /usr/src, which is where most kernel work is done. Now you can extract the source package:

cd /usr/src
bunzip2 kernel-source-2.4.20.tar.bz2
tar xf kernel-source-2.4.20.tar

That will leave you with a "/usr/src/kernel-source-2.4.20" directory, uncompressed and ready to configure. First though create a symlink to it called "linux", like this:

ln -s kernel-source-2.4.20 linux

If there's already a symlink there (such as to an old kernel source) you'll need to delete it first. Now you can easily get to your kernel source tree just by typing

cd /usr/src/linux

Tools You Will Need

In order to configure, compile and package your new kernel you will need a range of tools. To install the main packages:

apt-get install kernel-package libncurses5-dev

This will also cause it to grab a pile of supporting packages based on their dependencies.

Configuration Methods

There are a number of ways to configure a kernel prior to compiling it, and all are invoked as arguments to the 'make' command. Make sure you have a shell open in the kernel source directory (should be /usr/src/linux if you followed my directions above) before you try any of these. In increasing order of sophistication, they are:

editing .config

The actual configuration is saved in the source directory as a text file called '.config'. If you really want to (or if you are trying to find an option some readme has listed by name, such as 'CONFIG_PACKET') you can edit this file directly using a text editor such as Vi or Anjuta. This should be very rare though.

make config

The most basic approach, this will just ask you a whole heap of questions one after another. Personally I hate doing it this way, because it's sequential and you have to go through a heap of stuff you probably couldn't care less about. Only bother with this as a last resort, such as if other options aren't available to you for some reason.

make menuconfig

This is the most common way to do the configuration. It will display a nice, keyboard-driven menu which you can navigate using arrows, enter and the space bar. However, one catch that can trip you up is that you need to have the development libraries for Ncurses installed, not just Ncurses itself. That's why I got you to install the libncurses5-dev package a few paragraphs ago ;-)

make xconfig

The preferred method for machines with X, this is very similar to menuconfig except it's all done in a nice point-n-click GUI with mouse navigation. The possible gotcha to getting this working is you'll need tk8.3: if you get errors saying it can't find 'wish', do:

apt-get install tk8.3

and all should be well.

Configuring The Kernel

Whichever configuration method you choose, the next thing to do is examine the settings for the different kernel options and make changes as required.

There are a huge number of kernel options, so to help you find things they are grouped together in a logical way in different major and minor sections. The different configuration methods have their own ways to represent this, but they should all be fairly straightforward to follow.

I won't go into details of how to do the kernel configuration here, because what you need to configure will vary dramatically and there are plenty of tutorials on the net (including the Kernel-HowTo!) that explain this in detail. Basically though you need to work through each menu in turn to find options and modules you want to enable, and set them to either off (not available), on (compiled straight into the kernel) or module (compiled separately so it can be loaded when needed).

Once you've finished going through the options, quit and save to have your choices written out to a configuration file to be used by the compiler.

One little trick to note is that the actual configuration details are stored in a file called ".config" in the kernel source directory. Once you've gone to all the trouble of setting up a kernel the way you want it, moving to a new kernel can be painful if you have to go through the configuration process from scratch and you'd be almost certain to miss something crucial - I know I usually do! To make things easier for yourself, you can copy the .config file into the new kernel source directory to have all your options carried over automatically. Then you can run the configuration again just to check things over, save and go on as before. Provided you're not changing to a totally new kernel type, that trick can save you a lot of time. Beware if you're moving to a totally different kernel though, such as from 2.4.x to 2.5.x, because many of the options will be totally different and while the old config will still work, it may not have some options activated that only appear in the new kernel.

Compiling And Packaging

This is the point where your kernel is actually compiled and placed in a package. Normally that would be a lot of work, but thanks to the tools provided by the 'kernel-package' package it's now one of the easiest steps.

If you've read a Kernel How-To you've probably seen a sequence of commands such as 'make dep && make clean && make bzImage'. You don't need to do any of that, just type:

make-kpkg kernel-image

in the /usr/src/linux and it'll be taken care of. The kernel packaging tools first compile your kernel and modules according to the configuration you just generated, then build a Debian package called 'kernel-image-<version>_<architecture>.deb' outside the current source directory, ie: in /usr/src.

This stage can take a while, depending on your machine speed and what modules you selected. Expect anything from 10 minutes to a half hour, during which time you'll see a very long stream of debugging information that probably won't be of any interest to you at all unless something goes seriously wrong.

Installing Your Kernel Package

We're almost there! What you will have now is a kernel, custom compiled according to your requirements and set up as a Debian package ready to install.

Installing your new kernel is now just a matter of using dpkg as root to install the package like you would any other Debian package:

dpkg -i kernel-image-2.4.20_10.00.Custom_i386.deb

(or whatever your package is called). It may ask you if you want to create a boot floppy using that image: the dozens of machines I manage don't have a single floppy drive among them, so I always say no, but if you want to you can say yes to have it create one for you.

It will then ask you if you want to install a boot block using the existing /etc/lilo.conf: if you are using Lilo as a bootloader (the default for Woody) then just say yes.

By now what will actually have happened is that Dpkg will have put your new kernel image in the /boot directory where kernels are normally stored, created a symlink from /vmlinuz to your new kernel (you can verify this by typing 'ls -l /vmlinuz'), modified your /etc/lilo.conf so Lilo can find your new kernel, moved the previous kernel so it's available as an emergency fallback in case your new kernel borks, and re-run Lilo to activate the changes.

Note that at this point you will not be running the new kernel: it's just set up, ready to go for next time you reboot. Installing a new kernel is one of the very few things that actually requires you to reboot a Linux system.

Setting Lilo Prompts

Lilo allows you to have a number of kernels installed and select which one you want to use. To play it safe, you should configure Lilo to display a list of available kernels so that if you reboot to your new kernel and find you made a big mistake you can just reboot and select the previous kernel from Lilo's list.

Open /etc/lilo.conf in a text editor, and make sure you have lines in it similar to the following:

prompt
delay=100
timeout=100

Those lines are probably already in there, but commented out (and probably with different delay values). All they do is tell Lilo to bring up a list of available kernels on boot, and wait 10 seconds (100 deci-seconds Ð don't ask me why that interval was chosen!) before proceeding to boot the default kernel.

Rebooting And Testing

Time for the big test! If you are running X, exit the session and reboot. If not, just type 'reboot' as root. When Lilo loads you will be presented with a list of available kernels, including your new one. Select it and hit Enter.

Once your machine has booted, you can check the boot messages to see what the new kernel loaded by looking through the dmesg log:

less /var/log/dmesg

If everything worked as expected, congratulations! You've just compiled and installed a custom kernel The Debian Way.

Installing On Other Machines

This is where the convenience of compiling kernels The Debian Way becomes most obvious. If you want to install your custom kernel on other machines, the process is very simple: just copy the .deb package you created to the target machine, and install it using Dpkg exactly as before. Simple!

There's no need to compile the kernel on each machine, or copy the source code to them, or even have a compiler installed on them. All the hard work was done once on one machine, and doesn't need to be repeated.

Errata/Addendum: This is stuff I still need to incorporate into the main text, stuck here so you know it's not forgotten (and so I don't forget it!)

there is a mostly unknown makefile target namend "oldconfig".
when you upgrade your kernel, you may copy your old ".config" 
file to the new source tree and type in "make oldconfig".

by this way, you are prompted with just a few questions witch
cover the different kernel options since the last kernel version
used.
it`s look & feel is similar to "make config", but when upgrading
from one minor version to another, you usualy only get about five
questions, and you can be sure you don't miss anything.

Thorsten Kraft

make-kpkg installs .config used for kernel compilation as
/boot/config-version

This thing worth mentioning, becouse it allows one to easily find
compilation options of currently running kernel.

So, where you describe configuration process, you can add

"If you are running already packaged kernel, you can start
configuration process by copiing /boot/config-`uname -r` into
/usr/src/kernel-source-/.config"

Victor B. Wagner

1. Compiling and building 3rd-party modules.
  modules target in make-kpkg,
  Debian *-source packages (pcmcia-source, thinkpad-source etc).

  Lot of people wouldn't satisfied with functionality included in the
  official kernel. Some run NVidia graphic cards and need kernel
  support for video acceleration, some have notebooks, which require
  special hardware support, some use VPN or other software which need
  special kernel modules.

  make-kpkg provides way to handle such modules and Debian developers
  do their best to package modules source in make-kpkg compatible way.

  So, I think it is neccessary to document this

  I cannot say from the first glance if information how to build one's own 
  packages for custom modules fits your book.

2. Applying a patches to the kernel.
  There is some debianized kernel patches such as xfs support,
  international kernel patch.

  do apt-cache search --names-only kernel-patch

  to see the complete list
  
  Using this patch packages should be covered too.

3. Kernel version management
  
   make-kpkg --append_to_version argument as way to
   distinguish between your own kernel builds and keep 3rd-party modules
   packages in sync with kernel proper.

   May be you should ask about best practices of version management
   in some debian mailing list, and summarize responces.

4. Using fakeroot to avoid compiling kernel as root. 
   
5. Considerations about installation. 
   It is not evident from the "Setting Lilo Prompt" section of your
   article, that Debian user almost never need to touch default
   lilo configuration - package system would care about providing
   known-good kernel fallback.

   There are somewhat different situations when you are installing
   new build of same version kernel with same --append_to_version
   and when you are upgrading to new kernel.

   I also have tradition to keep installation kernel as third target
   in lilo.conf, typically named "dist" along with "linux" and
   "linux.old" targets in my lilo.conf. 
   
   It becomes very helpful if I need to boot from distribution CD.
   If distribution kernel modules are available, kernel, booted from
   CD in rescue mode is able to find its modules.


BTW, I never have non-zero timeouts in my lilo.conf. On rare occasions
when kernel builds incorrectly and I have to reboot into old version,
it is always possible to press a Shift key when machine is booted and
get lilo prompt regardless of timeout.

Victor B. Wagner

But ... I thing it will be better if you will add
section about adding kernel patches. 
        Something like "Patching kernel Debian Way". 
        For example 
                apt-get instal kernel-patch-badram
        And then explain what to type before compiling.
        Except that I would suggest to explain to beginer
        (as me) what are kernel-header *.deb file 
        and for what I can use them.
		
Marek Jambrich

I think of the conflicting custom versions, the 
fact that the modules installed in /lib will conflicts, and such 
problems. What I think that would be great is that you add the few lines 
that are needed just to expose this solution :
make-kpkg --config menu --revision=2.4.20.7 --append-to-version custom7 
--bzimage kernel_image

-> this way, if you tell them just to incrment the "subsubversion" number 
(the number 7 in the example), then they will be able to use as many 
versions they want, all installed at the same time, without any conflict.

Finally, I would really love that you just remember what they have to do 
when they've installed the .deb custom package if they are using grub :
"Just type update-grub as root and all is fine."

Michel Nolard

Say, you left out patching and that you can do a --config=menuconfig 
from the make-kpkg command line. :)


Mark Wolfe

|      Provided you're not changing to a totally new kernel type, that
| trick can save you a lot of time. Beware if you're moving to a totally
| different kernel though, such as from 2.4.x to 2.5.x, because many of
| the options will be totally different and while the old config will
| still work, it may not have some options activated that only appear in
| the new kernel.

     The problems you mention can occur not only when moving to a
new major version, but also when moving from e.g. 2.4.20 to
2.4.21-rc3. 

     Check out the "make oldconfig" command in the kernel source
README.  This overcomes the reusing a .config file.

Bob Hilliard