LPI Linux Certification in a Nutshell (In a Nutshell (OReilly))

13.2. Objective 2: Reconfigure, Build, and Install a Custom Kernel and Kernel 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.

13.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.

13.2.1.1. Kernel versions

Nearly all software projects, even small ones, use a numerical version 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.6.13 (don't let the low major release number fool youthere 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 used to 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) were considered stable.

Odd-numbered releases

Kernels with odd-numbered minor release versions (2.1, 2.3, 2.5, and so on) were in development and were primarily used by kernel developers. Currently, however, development continues on 2.6 and there is no 2.7.

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, 2.4.18, 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.

13.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 was provided in Chapter 4.

Of course, you also need the kernel source code. The stock kernel source can be found at ftp://ftp.kernel.org/pub/linux/kernel. In addition, most distributions come with a kernel source package (usually named kernel-source or something similarly descriptive).

The kernel's source code can be found in /usr/src/linux-kernel-version on most systems. For example, here is the /usr/src directory for a system with several kernel versions:

# ls -l /usr/src 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

13.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 kernel for a Pentium system with IDE disks to replace a generic kernel that came with the distribution. (A system that boots from a SCSI disk and has the SCSI driver compiled as a module requires the use of an initrd [initial RAM disk], which is not covered here.)

Assume that the development environmentincluding compiler, make, kernel source code, and kernel headersis installed. The root user will be used to create and install the kernel, although any user can compile a kernel; however, like most tasks on a Linux system, it is best to avoid doing things as root.

13.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)

• Want that feature 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 .config, which is a plain text file that lists the options as shell variables set to y, m, or n in accordance with your response for each item.

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. The options presented in each case are the same, as is the outcome.

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. 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 cursor keys 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 (although most do), you must select another method. The make menuconfig window is illustrated in Figure 13-1 in an xterm.

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 13-2 shows the top-level make xconfig window.

Figure 13-2. The make xconfig menu display

Syntax

make oldconfig

Description

make oldconfig creates a new kernel configuration using .config as a base. User interaction is required only for options that were not previously configured (such as new options). This is convenient if you have patched your kernel with code that adds a new configuration option and want to be prompted only for configuration choices related to the new configuration option.

In the absence of user responses, menuconfig and xconfig will create a default .config file.

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 13-3.

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

By setting the Processor family parameter to Pentium/K6/TSC and saving the configuration, you cause the following revised configuration lines to be 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 the file Makefile in the top level of the kernel source tree to differentiate our new custom kernel from the generic one. 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.

13.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:

1. make dep

   In this step, source files (.c) are examined for dependencies on header files. A file called .depend is created in each directory containing source files to hold the resulting list, with a line for each compiled object file (.o). The .depend files are automatically included in subsequent make operations to be sure that changes in header files are compiled into new objects. Since kernel code isn't being developed here, no header file changes are needed. Nevertheless, make dep is an essential first step in the compilation process.

2. make clean

   The "clean" operation removes old output files that may exist from previous kernel builds. These include core files, system map files, and others. They must be removed to compile a new, clean kernel.

3. make bzImage

   The bzImage file is the ultimate goal: a bootable kernel image file, compressed using the gzip utility. It is created in this step along with some additional support files needed for boot time. (It is important to remember that the b in bzImage does not refer to being compressed with bzip2. The bzImage kernel format allows for a larger image than the old zImage format, so bzImage just means big zImage.)

4. make modules

   Device drivers and other items that were configured as modules are compiled in this step.

5. make modules_install

   All of the modules compiled during make modules are installed under /lib/modules/kernel-version in this step. A directory is created there for each kernel version, including various extra versions.

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 arch/i386/boot/bzImage in the kernel source tree.

13.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:

1. The first step is to put a copy of our new bzImage on the boot partition so it can be booted by LILO. The copy is named just as it was named during compilation, including the extra version:

   # cp -p arch/i386/boot/bzImage /boot/vmlinuz-2.2.5-15-pentium

2. Now, a listing of kernels should show at least your default kernel and your new one, vmlinuz-2.2.5-15-pentium:

   # ls -1 /boot/vmlinuz* /boot/vmlinuz /boot/vmlinuz-2.2.14 /boot/vmlinuz-2.2.5-15 /boot/vmlinuz-2.2.5-15-pentium /boot/vmlinuz-2.2.5-15smp /boot/vmlinuz-2.3.45

3. Next, add a new image section to the bottom of /etc/lilo.conf:

   image=/boot/vmlinuz-2.2.5-15-pentium label=linux-pentium root=/dev/sda1 read-only

4. If you're using LILO for your boot loader, you must execute lilo (the map installer) to see the new kernel:

   # lilo Added linux-smp * Added linux-up Added latest Added linux-pentium

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 you're using GRUB for your boot loader, editing its configuration file is sufficient. No extra steps are required.

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

13.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