Building a Custom Kernel
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.
In the past, you would need to recompile the kernel if you added new hardware on your system. The kernel was, in other words, static. Improvements in the Linux 2.0.x kernels allowed for much of the drivers for hardware to be modularized into components that could only be inserted on demand. However, there were major problems with having multiple kernels on your system that had been compiled for different advancements (a good case being SMP versus UP kernels). Further advancements with the modularization of the Linux 2.2.x kernel have allowed for multiple kernels to more easily co-exist (though not share modules).
For information on handling kernel modules see the section called Loading Kernel Modules in Chapter 3. Most of the changes are hidden except when recompiling a customized kernel for your system.
Building a modularized kernel
These instructions enable you 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.
The most important step is to make sure that you have a working emergency boot disk in case you make a mistake below. If you didn't make a boot disk during the installation, use the mkbootdisk command to make one. The standard command is similar to mkbootdisk --device /dev/fd0 2.2.x, where 2.2.x is the full version of your kernel (such as 2.2.14-5.0). Once done, test the boot disk to make sure that it will boot the system.
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. Available methods for kernel configuration are listed below:
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, and are selected using a mouse. Again, select Y (yes), N (no), or M (module).
make oldconfig — This is a non-interactive script that will set up your Makefile to be the default settings. If you're using the Red Hat patched kernel, it will set up the configuration to be that of the kernel that is shipped for your box. This is useful in setting up your kernel to known working defaults and then turning off features that you don't want.
 | Please Note |
|---|---|
In order to use kmod (see the section called Loading Kernel Modules in Chapter 3 for details) and kernel modules you must answer Yes to kmod support and module version (CONFIG_MODVERSIONS) support in the configuration. |
If you wish to build a kernel with a configuration file (/usr/src/linux/.config — this file is created once one of the above methods has been performed) 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 in making a modularized kernel is to simply edit /usr/src/linux/Makefile and compile 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.
Edit the Makefile and change the line: EXTRAVERSION = to match a "unique" name (such as adding your initials to the end of the string, as in EXTRAVERSION = -2.5.0sjs). This will allow you to have the old working kernel and the new kernel on your system at the same time.
Build the kernel with make bzImage.
Build any modules you configured with make modules.
Install the new modules (even if you didn't build any) with make modules_install. This will install the kernel modules into the directory path /lib/modules/ using the path name that was specified in the Makefile. Our example would be /lib/modules/2.2.15-2.5.0sjs/.
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). Unless you have a specific reason to create an initrd image, do not create one and do not add it to lilo.conf.
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 a possible default /etc/lilo.conf file shipped with Red Hat Linux:
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
linear
default=linux
image=/boot/vmlinuz-2.2.16-12
label=linux
initrd=/boot/initrd-2.2.16-12.img
read-only
root=/dev/hda8
other=/dev/hda1
label=dos |
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=50
message=/boot/message
linear
default=linux
image=/boot/vmlinuz-2.2.16-12
label=linux
initrd=/boot/initrd-2.2.16-12.img
read-only
root=/dev/hda8
image=/boot/vmlinuz-2.2.16-12.sjs
label=test
initrd=/boot/initrd-2.2.16-12sjs.img
read-only
root=/dev/hda8
other=/dev/hda1
label=dos
|
Now when the system boots and you press Tab at the LILO boot: prompt, available choices will be shown;
LILO boot:
linux test dos
|
To boot the old kernel (linux) simply press Enter, or wait for LILO to time out. If you want to boot the new kernel (test), type test and press Enter.
Here is a summary of the steps:
Copy the resulting compiled kernel into your /boot directory using the name that resulted from your earlier changes to the Makefile. Here is an example:
cp -p /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.2.15-2.5.0sjs /usr/src/linux/System.map /boot/System.map-2.2.15-2.5.0sjs
Edit /etc/lilo.conf.
Make a new initial ramdisk, initrd image (see the section called Making an initrd image) if needed.
Run /sbin/lilo (you may want to use /sbin/lilo -t first — this command will test your lilo.conf without actually writing a new boot sector or map file). You can add a -v flag to lilo to get more verbose reporting if you think there might be a problem.
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. If you do not need an initrd image, do not make one and do not edit lilo.conf to include this image.
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.2.15-2.5.0sjs |
Where /boot/newinitrd-image is the file to use for your new image, and 2.2.15 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). Also, you should answer No to kmod support and module version (CONFIG_MODVERSIONS) support in the configuration.
Omit the steps:
make modules make modules_installEdit lilo.conf and add the line append=nomodules.