Task 2.6: Configure and Compile a Kernel
Kernel configuration is an important system administration task because it enables you to add support for new hardware and to optimize the kernel for your hardware and your needs. A properly tuned kernel can help a system run at its most efficient.
You've heard that the latest Linux kernel provides faster and more reliable support for your Ethernet hardware than is available with the Linux kernel you're running. To take advantage of this improvement, you want to compile a new kernel.
Scope of Task
This task involves configuring a kernel using its configuration tools, compiling the kernel, installing kernel modules, and copying the kernel to a location from which it can be booted. Actually booting and using the new kernel requires modifying your boot loader configuration, which is described in Phase 5.
This task will take from one to three hours to complete, depending on how carefully you study your kernel options and the speed of your computer. Once you're familiar with kernel options, you should be able to change one or two options in just a few minutes, but compiling the kernel will still take several minutes to over an hour.
To begin, you should download the kernel source code. As I write, the latest version is 220.127.116.11, and it is available from http://www.kernel.org. You can use this version or a more recent version, at your discretion. The kernel comes as a bzipped tarball, which ends in a .tar.bz2 filename extension, or as a gzipped tarball, with a .tar.gz filename extension. The former is the more compact file and so is what I describe using.
Before you can configure or compile the kernel, you must uncompress it in a convenient directory. The traditional location for the kernel is in /usr/src/linux. This directory is usually a symbolic link to a directory that includes the kernel version number (such as /usr/src/ linux-2.6.17; the final number is usually omitted). If you want to configure and compile your kernel as an ordinary user, which is best from a safety point of view, you may want to extract the tarball in your home directory and then create a symbolic link to that directory in /usr/src, first deleting any existing symbolic link:
$ tar xvfj linux-18.104.22.168.tar.bz2 $ su Password: # cd /usr/src # rm linux # ln -s /home/yourname/linux-2.6.17 linux
Of course, you should change yourname in the final command to the name of your home directory. At this point, your kernel is ready for configuration.
Kernel configuration can seem quite intimidating to the uninitiated, and making mistakes can result in an unbootable kernel. If you're careful not to overwrite your old kernel, though, and to keep its entry active in your boot loader, compiling a new kernel need not be particularly dangerous, aside from the usual cautions whenever you use root privileges.
Creating a custom kernel involves five steps: configuring the kernel, compiling the kernel, installing kernel modules, installing the kernel, and configuring your boot loader. The procedure described here covers the first four of these steps. Boot loader configuration is covered in Phase 5.
Configuring the Kernel
The most tedious part of kernel preparation, and the part that's most likely to lead to confusion and head-scratching, is that of configuring the kernel. In this process, you'll select the drivers, features, and other kernel options that you want to use. To begin the process, type the following commands in an xterm window:
$ cd /usr/src/linux $ make xconfig
The result, after a delay of several seconds to a minute or two, is a window similar to the one shown in Figure 2.5. This is the main kernel configuration window, and it's broken into three sections: a set of kernel configuration areas on the left; a set of specific configuration options, and sometimes sub-areas, on the top right; and a pane that holds explanations of specific options on the bottom right.
In the GUI configuration tool, you can add or remove support for an option by clicking the box to its left. Some options have arrows to the left, indicating sub-options, which may be hidden or expanded. Sometimes clicking the sub-option arrow produces an entire menu of new options.
Many kernel features can be compiled directly into the main kernel file, denoted by a check mark (as in the IEEE1284 Transfer Modes option in Figure 2.5), or as a kernel module, denoted by a dot (as in the PC-Style Hardware option in Figure 2.5). Compiling a feature directly into the main kernel file increases the size of this file and means that the option will always be available, including when the system first boots. This may be desirable if you're customizing a kernel for a single system, and it's recommended for boot hardware such as hard disk controllers. Compiling a feature as a module means that it need not be loaded if the hardware isn't present on the computer or at a particular time. This is handy if you're compiling a kernel that will be used for multiple computers or if you just want to keep the size of the kernel to a minimum. Some features can only be compiled directly into the kernel, or they only affect other options and so appear as check-mark options. A few features enable you to select from one of a set of options, such as CPU types.
FIGURE 2.5 The Linux kernel provides many configuration options to optimize performance.
Unfortunately, a complete description of all the kernel options would more than fill this entire book. I recommend you do a quick pass through the kernel to get a feel for the options you're given. If you've copied a working .config file for your computer or from your distribution and then typed make oldconfig, that configuration should make a good starting point for further tweaks via make xconfig or make menuconfig. Pay particular attention, though, to options relating to boot devices. In particular, you should compile in support for your ATA disk controller or SCSI host adapter, as well as for whatever filesystems you use on your hard disk. If you compile these options as modules, the kernel won't have them for accessing the disk, which will bring the boot process to a grinding halt. (Distributions use boot RAM disks to get around this problem, but for a custom kernel, it's easier to compile the drivers directly into the main kernel file.)
As a general rule, you can compile support for hardware that you don't use to boot the kernel and read the initial configuration files—such as Ethernet cards, parallel ports, and sound cards—as kernel modules. Doing so will help keep the kernel file small, which is generally desirable. It also means that you need to be less certain of the hardware you've got installed— if you're not sure what Ethernet card you're using, you can compile support for anything that sounds promising without worrying about bloating your kernel.
Look for options you can safely omit. For instance, if you know you don't have any video capture cards, you can omit those drivers, saving compile time and reducing kernel size. If in doubt, read the description for an option and follow its advice.
Going through all the options is likely to take at least half an hour, and probably an hour or two if you're not already familiar with kernel configuration. When you're done, exit from the kernel configuration tool. You'll be asked if you want to save the configuration; respond Save Changes.
Compiling the Kernel
Compiling the kernel is remarkably simple; it can be done with one command:
Although this command looks simple, it starts a process that can be quite time-consuming. Depending on the speed of your CPU and the number of kernel options you've chosen to compile, this process can take anywhere from a few minutes to over an hour. During this time, you'll see a series of messages appear summarizing the kernel files that are being compiled. You may also see occasional warnings; don't worry about those. If you see an error message and compilation stops, though, it could be you've selected incompatible options or run into a bug. Unfortunately, such problems are tricky to resolve without extensive knowledge of the relevant subsystems. If the message seems to relate to a feature you don't need, though, you could try disabling it. Sometimes compiling an option into the main kernel file rather than as a module will work around a problem.
Installing Kernel Modules
Once the kernel has finished compiling, you'll see a message to that effect. You can then install kernel modules. This step requires root privileges:
# make modules_install
This command installs the kernel modules in the /lib/modules/version directory tree, where version is the kernel version number. This process shouldn't take very long; no compilation is involved, just file copies. After you type this command, use ls to verify that an appropriate directory has appeared in /lib/modules.
Installing the Kernel
The final step described in this task is kernel installation—copying the kernel file to the /boot directory. You can do this as root with a single cp command:
# cp /usr/src/linux/arch/i386/boot/bzImage /boot/bzImage-22.214.171.124
This example command assumes you're using a 32-bit x86 system and that you're installing a 126.96.36.199 kernel. If you're using a non-x86 platform, the source directory will be different. Specifically, i386will be something else, and bzImage may be another name. You can install the kernel under any name you like; bzImage-188.8.131.52is a convenient and descriptive name for a kernel of this version number.
Traditionally, Linux kernels are called vmlinux, vmlinuz, or bzImage, with the last of these being the most common for locally compiled kernels on x86 and related platforms.
In addition to the kernel file itself, you may want to copy the System.map file, which appears in the /usr/src/linuxdirectory, to the /bootdirectory. As with the kernel file, you may want to rename it to include the kernel version number. Once this is done, you can replace the /boot/System.map symbolic link with one that points to the new file you've just copied. The System.map file is not strictly necessary for system operation. It holds the addresses within the kernel of symbols—variable names and so on. This information is necessary for some debugging operations, so some tools that report details of system crashes and other problems may not work correctly without this file.
Incidentally, both of these files are copied to /bootsimply because this is the most common location for compiled kernels and related files. Some distributions place their kernels in the root (/) directory, but even with these distributions, I recommend using /boot for your own kernels in order to keep the root directory uncluttered.
Criteria for Completion
To complete this task, you should have successfully configured and compiled your kernel, installed the kernel modules, and copied the kernel file to the /bootdirectory. Unfortunately, actually testing your kernel's viability will require you to learn how to manage a boot loader, which is a topic that's covered in Phase 5.
Use the following table of contents to navigate to chapter excerpts, or click here to view Chapter 2 in its entirety.
|ABOUT THE BOOK:|
|Hit the ground running with the street-smart training you'll find in Linux Administrator Street Smarts: A Real World Guide to Linux Certification Skills. Using a "year in the life" approach, it gives you an inside look at Linux administration, with key information organized around the actual day-to-day tasks, scenarios, and challenges you'll face in the field. This valuable training tool is loaded with hands-on, step-by-step exercises covering all phases of Linux administration. Purchase the book from Wiley Publishing|
|ABOUT THE AUTHOR:|
|Roderick W. Smith left a career in academia to pursue his passion for computers. He is particularly interested in Linux and Open Source Software, and has written several books.|
This was first published in February 2007