15.2 Objective 2: Reconfigure, Build, and Install a Custom Kernel and Modules

Because Linux is an open source operating system, you are free to create a customized Linux kernel that suits your specific needs and hardware. For example, you may wish to create a kernel for your system if your distribution installed a generic kernel that was compiled using the 80386 instruction set. Such a kernel will run on any compatible processor but may not utilize some of the capabilities of newer processors. Running a kernel optimized for your particular CPU can enhance its performance.

You can also install new kernels to add features, fix bugs, or experiment with kernels still under development. While the compilation of such kernels isn't much of a leap beyond recompiling your existing version, it's beyond the scope of the LPIC Level 1 exams.

15.2.1 Kernel Background

If you are new to the idea of building a custom kernel, don't feel intimidated. Linux developers have created a simple and reliable process that you can follow, and everything you need is available in your Linux distribution.

15.2.1.1 Kernel versions

Nearly all software projects, even small ones, use a numerical versioning scheme to describe each successive release. Kernel versions are numbered using the following convention:

major.minor.patchlevel

Major release

Increments in the major release indicate major developmental milestones in the kernel. The present release is 2.x.x (don't let the low major release number fool you -- there have been plenty of developmental milestones in the Linux kernel's history).

Minor release

The minor release indicates significant changes and additions, which taken together will culminate in a new major release. The Linux kernel minor release numbers fall into one of the following categories:

Even-numbered releases

Kernels with even-numbered kernel versions (2.0, 2.2, 2.4, and so on) are considered stable.

Odd-numbered releases

Kernels with odd-numbered minor release versions (2.1, 2.3, and so on) are in development and are primarily used by kernel developers. When goals for the development of a minor release are met and testing shows that the kernel is stable, a new even-numbered minor release is created. This is how development kernels are released as production kernels.

Patch level

As bugs are found and corrected or as planned features are added, the kernel patch level is incremented (2.2.15, 2.3.38, and so on). Generally speaking, it is safest to run the latest patch level of the kernel to be assured of having the most current bug fixes. In reality, it is more important to track kernel development and upgrade your kernel only if your existing version is found to have a serious problem or if you are already experiencing difficulty.

15.2.1.2 Required tools and software

To compile a custom kernel, you need development tools including a C compiler, assembler, linker, and the make utility. If you selected a kernel development option when you installed Linux, you should already have these tools on your system. The C compiler is the program that translates C source code into the binary form used by your system. The standard compiler on most Linux systems is the GNU C Compiler, gcc. The assembler and linker are needed for some portions of the kernel compilation.

The compilation process is controlled by make, a utility that executes commands such as gcc as directed by a list of dependency rules. These rules are stored in the Makefile. A brief introduction to make is provided in Section 14.3.

Of course, you also need the kernel source code. Your Linux distribution will come with one or more packages containing everything you need. For example, on a Red Hat system, use the following two RPM packages (listed here without their version numbers):

kernel-source

This package contains the C language source code for the kernel and modules.

kernel-headers

This package contains C language header files for the kernel. The header files define structures and constants that are needed for building most C programs, as well as the kernel itself.

On most systems, the kernel's source code can be found in /usr/src/linux, which should be a symbolic link to the specific version of the kernel you're using. For example, here is the /usr/src directory for a system with several kernel versions:

# ls -l /usr/src
lrwxrwxrwx  1 root  root      12  Feb 16 04:19 
        linux -> linux-2.3.45
drwxr-xr-x 15 root  root    1024  Jan 29 01:13 linux-2.2.14
drwxr-xr-x 17 root  root    1024  Feb 16 03:00 linux-2.2.5
drwxr-xr-x 14 root  root    1024  Feb 16 04:35 linux-2.3.45

In this example, symbolic link /usr/src/linux points to the directory hierarchy for development kernel 2.3.45. The /usr/src/linux link is important when you work with multiple kernels, as it is assumed that the link will be manually removed before installing new kernel source trees. For the purposes of Exam 102, you need to be concerned only with the kernel source installed by your distribution.

On the Exam You will need to know where the kernel source code is stored (e.g., /usr/src/linux). Explore the kernel source tree to familiarize yourself with its contents. Pay particular attention to .config and the Makefile.

15.2.2 Compiling a Custom Kernel

This section provides an overview of kernel compilation and installation by way of example. This example uses kernel Version 2.2.5, and our objective is to create a single-processor 2.2.5 kernel for a Pentium system with IDE disks^[2] to replace a generic kernel that came with the distribution.

^[2] A system that boots from a SCSI disk and has the SCSI driver compiled as a module requires the use of an initial RAM disk, which is not covered here.

Assume that the development environment -- including compiler, make, kernel source code, and kernel headers -- is installed. The root account will be used to create and install the kernel, although any user can compile a kernel given the appropriate filesystem permissions. Before building a customized kernel, you should read /usr/doc/HOWTO/Kernel-HOWTO and /usr/src/linux/README.

15.2.2.1 Creating a kernel configuration

The first step in creating a kernel is configuration. There are more than 500 options for the kernel, such as filesystem, SCSI, and networking support. Many of the options list kernel features that can be either compiled directly into the kernel or compiled as modules. During configuration, you indicate for each option whether you want that feature:

• Compiled into the kernel ("yes" response)

• Compiled as a module (module response)

• Don't want the feature at all ("no" response)

Some selections imply a group of other selections. For example, when you indicate that you wish to include SCSI support, additional options become available for specific SCSI drivers and features. The results from all of these choices are stored in the kernel configuration file /usr/src/linux/.config, which is a plain text file that lists the options as shell variables set to one of y, m, or n in accordance with your response for each item.

To begin, set the current working directory to the top of the source tree:

# cd /usr/src/linux

There are several ways to set up .config. Although you can do so, you should not edit the file manually. Instead, you may select from three interactive approaches. An additional option is available to construct a default configuration. Each is started using make.

Syntax

make config

Description

Running make config is the most rudimentary of the automated kernel-configuration methods and does not depend on any form of display capability on your terminal. In response to make config, the system presents you with a question in your console or window for each kernel option. You respond to the questions with y, m, or n for yes, module, or no, respectively. This method can admittedly get a bit tedious and has the liability that you must answer all the questions before being asked if you wish to save your .config file and exit. However, it is helpful if you do not have sufficient capability to use one of the menu-based methods (described next). A make config session looks like this:

# make config
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
/bin/sh scripts/Configure arch/i386/config.in
#
# Using defaults found in arch/i386/defconfig
#
*
* Code maturity level options
*
Prompt for development and/or incomplete code/drivers 
(CONFIG_EXPERIMENTAL) [Y/n/?]Y

Each option is offered in this manner.

Syntax

make menuconfig

Description

This configuration method is more intuitive and can be used as an alternative to make config. It creates a text-mode-windowed environment where you may use up/down/left/right and other keys to configure the kernel. The menu depends on the ability of your terminal or terminal window to use curses, a standard library of terminal cursor manipulation instructions. If your terminal does not support curses (though most do), you must select another method. The make menuconfig window is illustrated in Figure 15-1 in an xterm.

Figure 15-1. The make menuconfig menu display

Syntax

make xconfig

Description

If you are running the X Window System, the make xconfig configuration method presents a GUI menu with radio buttons to make the selections. It is the most appealing visually but requires a graphical console or X display. Figure 15-2 shows the top-level make xconfig window.

Figure 15-2. The make xconfig menu display

The options presented in each case are the same, as is the outcome.

Syntax

make oldconfig

Description

make oldconfig can create a default .config file. This method sets up a default .config file without interaction from the user. This is convenient if you need a starting point and your distribution did not install a default .config file. This method will also build a new .config file from one customized for a previous kernel release, but this is beyond the scope of Exam 102.

In the absence of user responses, menuconfig and xconfig will create a default .config file, equivalent to the one created by oldconfig.

Example

To create the .config file for this example, the target processor is set as Pentium. Using make xconfig, the selection looks like the window shown in Figure 15-3.

Figure 15-3. The make xconfig processor-selection window

By setting the Processor family parameter to Pentium/K6/TSC and saving the configuration, the following revised configuration lines are written in .config:

# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
CONFIG_M586TSC=y
# CONFIG_M686 is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_TSC=y
CONFIG_MATH_EMULATION=y
CONFIG_MTRR=y
# CONFIG_SMP is not set

The complete .config file will contain approximately 800 lines. You should look through the other kernel options with one of the windowed selectors first to familiarize yourself with what is available before making your selections.

Now that .config is created, one small change is made to Makefile to differentiate our new custom kernel from the generic one. Examining /usr/src/linux/Makefile, the first four lines look like this:

VERSION = 2
PATCHLEVEL = 2
SUBLEVEL = 5
EXTRAVERSION = -15

You can see that the kernel version is 2.2.5 and that an additional version number is available. In this case, the generic kernel had the extra version suffix of -15, yielding a complete kernel version number 2.2.5-15. This EXTRAVERSION parameter can be used to indicate just about anything. In this example it denotes the 15th build of kernel 2.2.5, but -pentium is added to the end for our custom version. Edit Makefile and change EXTRAVERSION as follows:

EXTRAVERSION = -15-pentium

This change completes the configuration for this example.

15.2.2.2 Compiling the kernel

Once the .config and Makefile files are customized, the new kernel can be compiled by running the following commands:

The bzImage and modules portions of the kernel-compilation process will take the most time. Overall, the time required to build a kernel depends on your system's capabilities.

After completing this series of make processes, compilation is complete. The new kernel image is now located in /usr/src/linux/arch/i386/boot/bzImage.

15.2.2.3 Installing the new kernel and configuring LILO

Now that the new kernel has been compiled, the system can be configured to boot it:

It's not uncommon to forget the execution of lilo. If you do forget, lilo won't know about the new kernel you've installed despite the fact that it's listed in the lilo.conf file. This is because lilo.conf is not consulted at boot time.

If everything has gone according to plan, it's time to reboot and attempt to load the new kernel.

As you review the README file that comes with the kernel source, you may see suggestions for overwriting your existing kernel, perhaps with a generic name such as vmlinuz, and reusing your existing LILO configuration unaltered (i.e., without changing lilo.conf ). Unless you're absolutely sure about what you are doing, overwriting a known-good kernel is a bad idea. Instead, keep the working kernel around as a fallback position in case there's a problem with your new one.

15.2.2.4 Examine the new modules

Now that the new kernel is installed, you should take a look at /lib/modules, which now has a new directory for the new kernel:

# ls -1 /lib/modules
2.2.14
2.2.5-15
2.2.5-15-pentium
2.2.5-15smp
2.3.45

On the Exam Remember the series of make steps required to build the kernel: config (or menuconfig or xconfig), dep, clean, bzImage, modules, and modules-install. Be aware of where the kernel source code is installed. Also, note that you need to copy the kernel image file (bzImage) to the root filesystem and that you must rerun lilo before you can boot it. By all means, practice compiling and installing a kernel at least once before taking Exam 102.