Section 25.2. Objective 2: Compiling a Kernel | LPI Linux Certification in a Nutshell (In a Nutshell (OReilly))

25.2. Objective 2: Compiling a Kernel

Regardless of the Linux distribution you choose, no two kernels are the same. The creators of your distribution had total freedom to customize the kernel, and so do you. Choosing and making these customizations are discussed in the next section, which covers patching. The current section explains how to apply the customizations, for which you must be able to compile your kernel.

25.2.1. Kernel Configuration Tools

The first step in compiling (or recompiling) a kernel involves the make tool. One set of commands provided with this tool allows you to select and deselect the exact options you want to include and modularize for the new kernel. These configuration settings are stored in a file named .config. Historically, this file was saved within your kernel source to /usr/src/linux or /usr/src/linux-kernel-version, but this is no longer the case. Older applications (based on the standard library called libc) required /usr/src/linux, but the introduction of a new library, glibc, eliminated that dependency. For the purposes of our examples, however, we will continue to show /usr/src/linux^*.

Tip: This book, following LPI program objectives, will assume that kernels are built from the vanilla kernel source available at http://www.kernel.org. Many major distributions, however, on their web sites, offer new kernel sources that incorporate the distributions' own patches.

When you configure a kernel using any of the tools described in this section, you are presented with at least 30 sets of configuration options. These options range from configuration tool preferences to hardware support and even development tools. For an introduction to the meaning of some kernel options, check Understanding the Linux Kernel and Understanding Linux Network Internals (both from O'Reilly).

There are three methods of using make to configure your kernel: make config, make menuconfig, and make xconfig. Each of these methods creates a file with the .config extension that is used when making the zImage or bzImage of the kernel.

Tip: To successfully use make, be sure you have all the appropriate packages or applications installed: All methods of make require the glibc-devel, gcc or egcs, make, kernel-headers, kernel-source, bin86, and cpp packages. If you opt to use the make menuconfig option, you must also have the ncurses and ncurses-devel packages installed. If you opt for the make xconfig option, you must have X Window support.

All make commands used to build and install the kernel must be issued in the top-level directory where you placed the kernel sources.

25.2.1.1. make config

The first method, make config, is a text-based tool that you step through to configure kernel options one by one. It is no longer recommended because the kernel provies so many options, and the interface involves simply stepping one by one through them tediously. However, make config is a standard tool and is provided with all Linux distributions.

When you enter make config, you are prompted line by line to include support for a specific item. Following each question, you are given up to four options: y for yes, n for no, m for modularize, and ? (question mark) for help. Entering the ? option gives you details about the particular item and what the recommended settings are.

The possible settings for a particular item are noted after each question, with the default option capitalized. For instance, the first question, Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL) [Y/n/?] has a default answer of y for yes. So you can accept the default by pressing the Enter key. The following displays the interface used in make config. (The first few lines are commands issued by make before the prompts start.)

 rm -f include/asm ( cd include ; ln -sf asm-i386 asm) /bin/sh scripts/Configure arch/i386/config.in # # Using defaults found in .config # * * Code maturity level options * Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL) [Y/n/?]  Enter key pressed * * Loadable module support * Enable loadable module support (CONFIG_MODULES) [Y/n/?]  Enter key pressed   Set version information on all module symbols (CONFIG_MODVERSIONS) [Y/n/?]  Enter key pressed   Kernel module loader (CONFIG_KMOD) [Y/n/?]  Enter key pressed * * Processor type and features * Processor family (386, 486, 586/K5/5x86/6x86/6x86MX, Pentium-Classic, Pentium-MMX, Pentium-Pro/Celeron/Pentium-II, Pentium-III/ Celeron(Coppermine), Pentium-4, K6/K6-II/K6-III, Athlon/Duron/K7, Elan, Crusoe, Winchip-C6, Winchip-2, Winchip-2A/Winchip-3, CyrixIII/C3) [Pentium- III/Celeron(Coppermine)]  Enter key pressed     defined CONFIG_MK7 Toshiba Laptop support (CONFIG_TOSHIBA) [N/y/m/?]  Enter key pressed Dell laptop support (CONFIG_I8K) [N/y/m/?] n  /dev/cpu/microcode - Intel IA32 CPU microcode support (CONFIG_MICROCODE) [M/ n/y/?]  Enter key pressed /dev/cpu/*/msr - Model-specific register support (CONFIG_X86_MSR) [M/n/y/?]  Enter key pressed /dev/cpu/*/cpuid - CPU information support (CONFIG_X86_CPUID) [M/n/y/?]  Enter key pressed High Memory Support (off, 4GB, 64GB) [off]  Enter key pressed   defined CONFIG_NOHIGHMEM Math emulation (CONFIG_MATH_EMULATION) [N/y/?]  Enter key pressed MTRR (Memory Type Range Register) support (CONFIG_MTRR) [Y/n/?]  Enter key pressed Symmetric multi-processing support (CONFIG_SMP) [N/y/?]  Enter key pressed ...

25.2.1.2. make menuconfig

The second type of make method is make menuconfig. It gives you a graphical menu-based display without requiring you to use the X Window System. When you use make menuconfig, you are presented with a directory tree menu system. Following each selection, you are presented with the available options. To include an option, use the y key; to exclude it, use the n key; and to include it as a module, use the m key. Letters that are highlighted are considered hotkeys and allow you to quickly maneuver through the menu options. To exit a window, select the Exit option, or press the Esc key twice.

25.2.1.3. make xconfig

The third type of make method is make xconfig. This method is very popular among new Linux users and users who are accustomed to graphical interface tools. The make xconfig tool requires X Window System support. When starting make xconfig, you are presented with a window with buttons for each class of configuration. Pressing a configuration button, you are prompted, in a tree style, the options available. You can then select, deselect, or modularize each option by pressing the corresponding button next to the item. One of the benefits of using this configuration method over the standard make config method is the backward mobility of the configuration. This means that if you change your mind, or make a mistake, you can move back and change the option in make xconfig; you can't do this with make config. Figure 13-2 in Chapter 13 shows the graphical user interface used with the make xconfig method.

25.2.2. Compiling and Installing a Custom Kernel

When compiling and installing a kernel, you use various make options. There are as many as 11 options, which we will describe in this section, that you can use when compiling and installing your kernel from start to finish. Follow these steps to compile and install a new kernel:

You must first configure your kernel as discussed in the "Kernel Configuration Tools" section earlier in this chapter. Several options are available. First, to compile your kernel, you must be in the directory with your kernel source files, such as /usr/src/linux directory. Next, if you plan to configure your kernel completely from scratch, enter make mrproper. Doing so removes your current .config file and allows you to set up all new options for your kernel without knowing your current default configuration. If you wish to see your current default options, skip the make mrproper step. To configure your kernel, use your choice of make config, make menuconfig, or make xconfig, as discussed earlier in this chapter.
Next, you must do some general kernel housekeeping. This means that you need to clean up any unneeded or temporary files from the kernel source tree. To clean the source tree, run make clean.
In 2.4 kernels, build dependency tables between the various features and modules you have chosen so that they can be built in the correct order and without building unused features and modules. To build these tables, run make dep. This step should not be performed for 2.6 kernels, because the build process generates dependency information automatically.
Create the kernel image using make bzImage (or make zImage if your hardware requires this older image type; the rest of this text assumes you use bzImage). This command compiles a kernel image and places it in the file arch/i386/boot/bzImage. After the image is created, copy the bzImage to the /boot directory. In the /boot directory, you may wish to rename the image to something like vmlinuz-kernel-version, e.g., vmlinuz-2.4.18. You should also copy the file System.map to /boot/System.map-2.4.18, which enables such things as module loading and the symbolic display of kernel routines by the top program.
Compile your modules. If you made a completely monolithic kernel, skip ahead to Step 7. Otherwise, run make modules to compile all of your selected modules.
Install your compiled modules by running make modules_install. When you install the modules with this make option, make installs them to /lib/modules. With the postconfiguration make options such as make clean, make dep, make bzImage, make modules, and make modules_install, you don't have to invoke each make command one at a time. You can string them together to run automatically without user intervention by simply running:
```
 # make clean dep bzImage modules install modules_install 
```
Create the RAM disk image (if required). The RAM disk image is used to preload block device modules (such as SCSI drivers to access SCSI hard drives) that are required during a boot to access the root filesystem. To create this RAM disk image, use the mkinitrd command, which is covered in more depth later in this chapter.
Lastly, you need to set up your boot loader for your new kernel. If you're using LILO, do this by editing the etc/lilo.conf file. Simply add an additional boot image section to /etc/lilo.conf or change the current boot image section to reflect your new kernel image name and initrd image (if necessary).
For instance, if you just compiled kernel 2.4.18, named the image /boot/vmlinuz-2.4.18, and created an initrd image named /boot/initrd-2.4.18, your new boot image section of /etc/lilo.conf should look like this:
```
 boot=/dev/hda map=/boot/map install=/boot/boot.b delay=20 timeout=240 root=/dev/hda3 read-only image=/boot/vmlinuz-2.4.18        label=2.4.18        initrd=/boot/initrd-2.4.18 
```
Tip: After you have edited your /etc/lilo.conf file, be sure to install the new configuration by running /sbin/lilo or all changes to the file will be ignored.

If you use GRUB instead of LILO, the GRUB configuration file needs to be updated, although no command needs to be run for it to take effect on the next boot. A grub.conf that is analogous to the one shown previously should look like the following listing. GRUB's filenames are relative to the top of your boot partition; that is why the pathnames look different from those in the lilo.conf file shown earlier.

 timeout=240 splashimage=(hd0,0)/grub/splash.xpm.gz title Linux 2.4.18         kernel (hd0,0)/vmlinuz-2.4.18 root=/dev/hda3         initrd (hd0,0)/initrd-2.4.18

25.2.3. Using initrd

initrd is a contraction of "initial ram disk." This initrd image is used by the kernel to load drivers before it starts booting. The purpose of this is to let users build modularized kernels that do not contain support for all 40 different SCSI controllers (for example) and still are able to boot from any SCSI hardware. In this case, the initrd image would contain the needed SCSI drivers and any other drivers needed to get the kernel off the ground.

An initrd image is typically constructed automatically by the mkinitrd command. This command differs substantially among distributions.

25.2.3.1. mkinitrd on Red Hat/Fedora

Tip: To be able to build and use initrd images on Red Hat, you need support for two things in your kernel: RAM disks and loop devices. Loop devices lets the kernel mount a file as if it were a device.

Red Hat and Fedora systems check various files for things that are likely to be needed to boot the machine. In /etc/modules.conf, they look for a line reading alias scsi_hostadapter that defines which SCSI module is needed to boot. They check for LVM (Logical Volume Manager) configurations and include the LVM drivers if they find anything, in case the boot depends on LVM. They look for md configurations to see whether it's necessary to include RAID drivers. Then they check all these module dependencies and include the whole bunch in the initrd image. This is all done automatically in a script; your job is restricted to running the right command. The most likely options are shown:

--preload module: Name a module you want loaded before the others.
--omit-scsi-modules: Skip the check for SCSI modules. You can use this if you know that SCSI is not needed to boot your system. Instead, the module will be loaded after the root filesystem is mounted.
--omit-raid-modules: Skip the check for whether MD modules are needed.
--omit-lvm-modules: Skip the check for LVM modules.
--with=module: Include a specific module.
-v: Be verbose.

An example follows. It shows how to make an initrd for the 2.4.18 kernel mentioned earlier in the file /boot/initrd-2.4.18. If the kernel has any EXTRAVERSION parts (described later), these must also be included in the version given and should be included in the filename as well.

 # mkinitrd -v /boot/initrd-2.4.18 2.4.18 Looking for deps of module ide-disk Looking for deps of module lvm-mod Looking for deps of module ext2 Using modules: Using loopback device /dev/loop0 /sbin/nash -> /var/tmp/initrd.c19229/bin/nash /sbin/insmod.static -> /var/tmp/initrd.c19229/bin/insmod # ls -l /boot/initrd-2.4.18 -rw-r--r--    1 root     root       101224 jan 11 13:01 /boot/initrd-2.4.18

25.2.3.2. mkinitrd in Debian

Tip: To be able to use an initrd image on Debian, you need support for cramfs (Compressed ROM filesystem) in your kernel.

The Debian mkinitrd command has fewer options and more customization files, making it harder to customize for a one-time generation, but easier in the long run because the files remain around for the next time. The general behavior is described in /etc/mkinitrd/mkinitrd.conf, and any modules you may want included are listed in /etc/mkinitrd/modules. As usual with Debian, the files are heavily documented and are thus largely self-explanatory. A default mkinitrd.conf follows:

 # /etc/mkinitrd/mkinitrd.conf: #  Configuration file for mkinitrd(8).  See mkinitrd.conf(5). # # This file is meant to be parsed as a shell script. # What modules to install. MODULES=most # The length (in seconds) of the startup delay during which linuxrc may be # interrupted. DELAY=0 # If this is set to probe, mkinitrd will try to figure out what's needed to # mount the root filesystem.  This is equivalent to the old PROBE=on setting. ROOT=probe # This controls the permission of the resulting initrd image. UMASK=022 # Command to generate the initrd image. MKIMAGE='mkcramfs %s %s > /dev/null'

With these defaults, mkinitrd is largely self-configuring. Generating an image analogous to the image made for Red Hat in the previous section is as simple as the following command. Note that, instead of the kernel version demanded by Red Hat's mkinitrd, this one wants the name of the kernel's module directory where it will find the modules it should use.

 # mkinitrd -o /boot/initrd-2.4.18 /lib/modules/2.4.18 # ls -ld /boot/initrd-2.4.18 -rw-r--r--    1 root     root       811008 Jan 11 13:32 /boot/initrd-2.4.18

25.2.4. Updating Your Kernel

Updating your kernel involves applying a patch or getting a complete source tree in a tarfile. The updated Linux kernels are best found at http://www.kernel.org. There you will also find the change logs for each patch level of the kernel. kernel.org stores compressed files in both bz2 and gzip formats. bz2 is compressed and decompressed by bzip2. gzip is compressed by the more familiar gzip. We will use bz2 for the rest of this chapter.

If you are looking to upgrade from 2.6.15.5 to 2.6.15.6, as an example, you will need to retrieve patch-2.6.15.6.bz2 for just the patch or linux-2.6.15.6.tar.bz2 for the complete source code. It is also a good idea to retrieve ChangeLog-2.6.15.6, which contains the developers' descriptions of what has changed in this release. In this file you may find important information about fixed bugs, including security, new features, and perhaps features that were removed.

If you fetched the full source tree, you just have to unpack it, configure it, and install it as described earlier in this chapter. If you fetched the patch, use the patching process described in the next objective.