Step 2: Set the Options You Want

Your actions here will depend upon whether you decide to install a new kernel, upgrade your existing kernel source code, or patch your existing kernel source code.

Installing a New Kernel

If you decide to install a new kernel (rather than patch or upgrade your existing one), you must first clean the source code tree of any files left behind from previous kernel compilations with the make clean command. Then use the make mrproper command to erase all .config files from the top level of the source code directory tree so that you can start with a clean slate. The make oldconfig command is then used to build a fresh .config file from scratch. Thus, the commands you would enter in the top level of the kernel source tree to prepare it for a new compilation are as follows:

 #make clean #make mrproper make oldconfig

Upgrading or Patching the Kernel

If you decide to upgrade or patch your existing kernel, save a copy of your existing /usr/src/linux/.config file first. Select an archival directory that you'll remember, and use it to store your old .config files in case you ever need to go back to an old kernel configuration. For example, to save the current .config file from the top level of your kernel source tree to the /boot directory, you would use a command that looks like this:

 #cp .config /boot/config-<version>

Note

When upgrading to a newer version of the kernel, you can copy your old .config file to the top level of the new kernel source tree and then issue the make oldconfig command to upgrade your .config file to support the newer version of the kernel.

Upgrading a Kernel From a Distribution Vendor

If you are upgrading your existing kernel source code, and this kernel source code was supplied by your distribution vendor, you should locate the .config file that was used to originally build the kernel you are currently running on your system. The distribution vendor may have left this configuration file in the top level of their kernel source distribution tree, or they may have a separate directory where they place a variety of .config files for different hardware architectures.

When you find this configuration file, be sure to place it in the top-level directory of your kernel source tree into the file .config. If you are upgrading to a newer version of the kernel, you should then issue the command:

 #make oldconfig

This command will prompt you for any kernel options that have changed since the .config file was originally created by your distribution vendor, so it never hurts to run this command (even when you are not upgrading your kernel) to make sure you are not missing any of the options required to compile your kernel.

Note

In the top of the kernel source tree you'll also find a Makefile. You can edit this file and change the value of the EXTRAVERSION number that is specified near the top of the file. If you do this, you will be assigning a string of characters that will be added to the end of the kernel version number. Specifying an EXTRAVERSION number is optional, but it may help you avoid problems when your boot drive is a SCSI device (see the "SCSI Gotchas" section near the end of this chapter).

Set Your Kernel Options

You now need to set your kernel options regardless of whether you installed a new kernel, are upgrading your existing kernel source code, or are patching your existing kernel source code.

You select the options you want to enable in your kernel from a text console screen by running the command:

 #make menuconfig

One of the most important options you can select from within the make menuconfig utility is whether or not your kernel compiles as a monolithic or a modular kernel. When you specify the option to compile the kernel as a modular kernel (see "A Note About Modular Kernels" for details), a large portion of the compiled kernel code is stored into files in the /lib/modules directory on the hard drive, and it is only used when it is needed. If you select the option to compile the kernel as a monolithic kernel (you disable modular support in the kernel), then all of the kernel code will be compiled into a single file.

Knowing which of the other kernel options to enable or disable could be the subject of another book as thick as this one, so we won't go into much detail here. However, if you are using a 2.4 kernel, you may want to start by selecting nearly all of the kernel options available and building a modular kernel. This older kernel code is likely to compile (thanks to the efforts of thousands of people finding and fixing problems), and this modular kernel will only load the kernel code (the modules) necessary to make the system run. Newer kernels, on the other hand, may require a more judicious selection of options to avoid kernel compilation problems.

Note

The best place to find information about the various kernel options is to look at the inline kernel help screens available with the make menuconfig command. These help screens usually also contain the name of the module that will be built when you compile a modular kernel.

A NOTE ABOUT MODULAR KERNELS

Modular kernels require more effort to implement when using a SCSI boot disk (see "SCSI Gotchas" later in this chapter). However, they are more efficient because they load or run only the kernel modules required, as they are needed. For example, the CD-ROM driver will be unloaded from memory when the CD-ROM drive has not been used for a while. Modular kernels allow you to compile a large number of modules for a variety of hardware configurations (several different NIC drivers, for example) and build a one-size-fits-all, generic kernel.

To build a modular kernel, you simply select Enable Loadable Module Support on the Loadable Module Support menu when you run the make menuconfig utility. As a general rule, you should always enable loadable module support^[3] so you can then decide as you select each kernel option whether it will be compiled into the kernel, by placing an asterisk (*) next to it, or compiled as a module, by placing an M next to it.

To continue our example of using the kernel source code supplied on the CD-ROM, enter the following lines from the top of the kernel source tree:

 #cp /mnt/cdrom/chapter3/sample-config .config #umount /mnt/cdrom #make oldconfig #make menuconfig^[4]

Note

The .config file placed into the top of the kernel source tree is hidden from the normal ls command. You must use ls -a to see it.

The sample-config file used in the previous command will build a modular kernel, but you can change it to create a monolithic kernel by disabling loadable module support. To do so, deselect it on the Loadable Module Support submenu. Be sure to enter the Processor Type and Features submenu and select the correct type of processor for your system, because even a modular kernel only compiles for one type of processor (or family of processors). See the contents of the file /proc/cpuinfo to find out which CPU the kernel thinks your system is using. Also, you normally should always select SMP support even if your system has only one CPU.

Note

When building a monolithic kernel, you can reduce the size of the kernel by deselecting the kernel options not required for your hardware configuration. If you are currently running a modular kernel, you can see which modules are currently loaded on your system by using the lsmod command. Also see the output of the following commands to learn more about your current configuration:

 #lspci -v | less #dmesg | less #cat /proc/cpuinfo #uname -m

Once you have saved your kernel configuration file changes, you are ready to begin compiling your new kernel.

^[3]Packages such as VMware require loadable module support.

^[4]If the make menuconfig command complains about a clock skew problem, check to make sure your system time is correct, and use the hwclock command to force your hardware clock to match your system time. See the hwclock manual page for more information.