Building a Custom Kernel

With the introduction of modularization in the Linux 2.2.x kernel there have been some significant changes in building customized kernels. In the past you were required to compile support into your kernel if you wanted to access a particular hardware or filesystem component. For some hardware configurations the size of the kernel could quickly reach a critical level. To require ready support for items that were only occasionally used was an inefficient use of system resources. With the capabilities of the 2.2.x kernel, if there are certain hardware components or filesystems that are used infrequently, driver modules for them can be loaded on demand. For information on handling kernel modules see the section called Kernel Daemon Configuration in Chapter 3.

Many people new to Linux often ask, "why should I build my own kernel?" Given the advances that have been made in the use of kernel modules, the most accurate response to that question is, "unless you know why you need to build your own kernel, you probably don't." So unless you have a specific reason to build a customized kernel (or you're just the curious sort), you may skip ahead to the section called Sendmail.

Building a modularized kernel

These instructions provide you with the knowledge needed to take advantage of the power and flexibility available through kernel modularization. If you do not wish to take advantage of modularization, please see the section called Building a monolithic kernel for an explanation of the different aspects of building and installing a monolithic kernel. It's assumed that you've already installed the kernel-headers and kernel-source packages and that you issue all commands from the /usr/src/linux directory.

It is important to begin a kernel build with the source tree in a known condition. Therefore, it is recommended that you begin with the command make mrproper. This will remove any configuration files along with the remains of any previous builds that may be scattered around the source tree. Now you must create a configuration file that will determine which components to include in your new kernel. Depending upon your hardware and personal preferences there are three methods available to configure the kernel.

make config -- An interactive text program. Components are presented and you answer with Y (yes), N (no), or M (module).
make menuconfig -- A graphical, menu driven program. Components are presented in a menu of categories, you select the desired components in the same manner used in the Red Hat Linux installation program. Toggle the tag corresponding to the item you want included; Y (yes), N (no), or M (module).
make xconfig -- An X Window System program. Components are listed in different levels of menus, components are selected using a mouse. Again, select Y (yes), N (no), or M (module).

Please Note: In order to use kerneld (see the section called Kernel Daemon Configuration in Chapter 3 for details) and kernel modules you must answer Yes to kerneld support and module version (CONFIG_MODVERSIONS) support in the configuration.

Please Note: If you are building a Linux/Intel kernel on (or for) a machine that uses a "clone" processor (for example, one made by Cyrix or AMD), it is recommended to choose a Processor type of 386.

If you wish to build a kernel with a configuration file (/usr/src/linux/.config) that you have already created with one of the above methods, you can omit the make mrproper and make config commands and use the command make dep followed by make clean to prepare the source tree for the build.

The next step consists of the actual compilation of the source code components into a working program that your machine can use to boot. The method described here is the easiest to recover from in the event of a mishap. If you are interested in other possibilities, details can be found in the Kernel-HOWTO or in the Makefile in /usr/src/linux on your Linux system.

Build the kernel with make boot.
Build any modules you configured with make modules.
Move the old set of modules out of the way with:
rm -rf /lib/modules/2.0.36-old mv /lib/modules/2.0.36 /lib/modules/2.0.36-old
Of course, if you have upgraded your kernel, replace 2.0.36 with the version you are using.
Install the new modules (even if you didn't build any) with make modules_install.

If you have a SCSI adapter and made your SCSI driver modular, build a new initrd image (see the section called Making an initrd image; note that there are few practical reasons to make the SCSI driver modular in a custom kernel).

In order to provide a redundant boot source to protect from a possible error in a new kernel you should keep the original kernel available. Adding a kernel to the LILO menu is as simple as renaming the original kernel in /boot, copying the new kernel to /boot, adding a few lines in /etc/lilo.conf and running /sbin/lilo. Here is an example of the default /etc/lilo.conf file shipped with Red Hat Linux:
boot=/dev/hda map=/boot/map install=/boot/boot.b prompt timeout=100 image=/boot/vmlinuz label=linux root=/dev/hda1 read-only

Now you must update /etc/lilo.conf. If you built a new initrd image you must tell LILO to use it. In this example of /etc/lilo.conf we have added four lines in the middle of the file to indicate another kernel to boot from. We have renamed /boot/vmlinuz to /boot/vmlinuz.old and changed its label to old. We have also added an initrd line for the new kernel:
boot=/dev/hda map=/boot/map install=/boot/boot.b prompt timeout=100 image=/boot/vmlinuz label=linux initrd=/boot/initrd root=/dev/hda1 read-only image=/boot/vmlinuz.old label=old root=/dev/hda1 read-only

Now when the system boots and you press Tab at the LILO boot: prompt, two choices will be shown;

LILO boot:
linux    old

To boot the new kernel (linux) simply press Enter, or wait for LILO to time out. If you want to boot the old kernel (old), type old and press Enter.

Here is a summary of the steps:

mv /boot/vmlinuz /boot/vmlinuz.old
cp /usr/src/linux/arch/i386/boot/zImage /boot/vmlinuz
edit /etc/lilo.conf
run /sbin/lilo

You can begin testing your new kernel by rebooting your computer and watching the messages to ensure your hardware is detected properly.

Making an initrd image

An initrd image is needed for loading your SCSI module at boot time. The shell script /sbin/mkinitrd can build a proper initrd image for your machine if the following conditions are met:

The loopback block device is available.
The /etc/conf.modules file has a line for your SCSI adapter; for example:
alias scsi_hostadapter BusLogic

To build the new initrd image, run /sbin/mkinitrd with parameters such as this:
/sbin/mkinitrd /boot/newinitrd-image 2.0.36
where /boot/newinitrd-image is the file to use for your new image, and 2.0.36 is the kernel whose modules (from /lib/modules) should be used in the initrd image (not necessarily the same as the version number of the currently running kernel).

Building a monolithic kernel

To build a monolithic kernel you follow the same steps as building a modularized kernel with a few exceptions.

When configuring the kernel only answer Yes and No to the questions (don't make anything modular).

Omit the steps:
make modules make modules_install

Edit the file /etc/rc.d/rc.sysinit and comment out the line depmod -a by inserting a "#" at the beginning of the line.