Notes on Customizing the Kernel

  1. The Linux Kernel Archives is the official repository of Linux kernel source trees. If you are moving from one version to the next, it is simpler to patch your existing source tree. Otherwise it is easier to download the new source tree for the version you want to install.

    Note the increase in size of the kernel files as the release numbers increase. This is an illustration of code bloat, which is endemic to computer software as new features and support for new hardware are added. One major reason for re-building your kernel is to reduce the negative impact of code bloat by tailoring the kernel to match your needs.

  2. Since kernel source tree tarball sizes are in excess of 232 bits, it is to be expected that downloads may occasionally be corrupt. In order to verify your download, you should check the signature against the one from the archive. For example, if you downloaded linux-2.6.37.tar.bz2, you should also download linux-2.6.37.tar.bz2.sign and execute the following commands:
    gpg --keyserver --recv-keys 0x517D0F0E
    gpg --verify linux-2.6.37.tar.bz2.sign linux-2.6.37.tar.bz2
    If you see a message like 'gpg: Good signature from "Linux Kernel Archives Verification Key "', the download was successful. Otherwise you should remove the source tree tarball and start over.

    If there is a question about the correctness of the public key, see

  3. Compressed kernel images are stored in /boot, along with corresponding system symbol maps. It is a good idea to store a copy of the kernel configuration file for each image there as well. This allows a quick feature check for each image you might want to boot.

    Kernel modules are used to reduce memory requirements; they are only loaded as needed. They are stored in /lib/modules, with a seperate sub-directory for each kernel version. Modules can be loaded and removed manually with insmod and rmmod, but usually one uses the modprobe command so that all the required modules are loaded at once. Both insmod and modprobe allow the setting of module parameters, but unless you are playing or debugging, module parameters are usually stored in /etc/modules.conf:

    options (module-name, without the ".ko") (parameters)
    Note that in order to build a kernel, the root filesystem must be mounted writable since both /boot and /lib are written to.
  4. The following commands, issued at the top level of the kernel source tree (often /usr/src/linux-(version)), will perform a complete kernel build:

    make mrproper
    cp /boot/config-2.6.32.full .config
    make menuconfig
    cp .config /boot/config-custom
    (make) 2>&1 | tee ../kernel.log
    cp arch/i386/boot/bzImage /boot/bzImage-custom
    cp /boot/
    (make modules_install) 2>&1 | tee -a ../kernel.log

    These commands assume that you wish to modify the existing kernel configuration (stored in /boot/config-lfsgeneral). It is always a good idea to make relatively few changes at a time to an existing, tested configuration.

    The make targets perform the following actions on the kernel source tree:

  5. In general, it's safest to avoid kernel configuration parameters which are labeled "Experimental". Otherwise, the most important thing is to make sure that your hardware is supported by your configuration.

    Some options must be selected to be built-in, ie., not as a module. This includes any support necessary to access your root filesystem (ie., Enable the block layer, Device Drivers - ATA/ATAPI/MFM/RLL support with its subcategories generic ATA/ATAPI disk support and ATA disk dupport, and any chipset support required).

    Some hardware seems to work best built-in, but if you build it as a module you have the option to play with parameters without rebooting, which can be a real benefit if you're having trouble getting it working. And some parameters are not available as modules; these must either be built-in in order to function properly, or are parameters which do not involve additional code.

    A few configuration parameters deserve additional comment:

    There is help available for the vast majority of configuration parameters, and you can learn a great deal about how the kernel works by reading it!
  6. Be sure to update /boot/grub/grub.cfg or menu.lst (on sdb5 in our lab) to include your new kernel.

    There are several kernel boot options which may be useful:

    See /usr/src/linux-2.6.37/Documentation/kernel-parameters.txt for more options.
  7. EXERCISES on Customizing the Kernel:

    1. Build the 2.6.37 kernel.
    2. Add a grub menu entry (as we did in week 2) and boot your new kernel. Compare the log entries from this boot with the one from your 2.6.32 boot (use diff).
    3. Execute an lsmod to list the modules now loaded.

©2012, Kenneth R. Koehler. All Rights Reserved. This document may be freely reproduced provided that this copyright notice is included.

Please send comments or suggestions to the author.