A kernel is a complex piece of software that manages the processes and process interactions that take place within an operating system. As a user, you rarely, if ever, interact directly with it. Instead, you work with the applications that the kernel manages.
The Linux kernel is Linux. It is the result of years of cooperative (and sometimes contentious) work by numerous people around the world. There is only one common kernel source tree, but each major Linux distribution massages and patches its version slightly to add features, performance, or options. Each Linux distribution, including Fedora, comes with its own precompiled kernel as well as the kernel source code, providing you with absolute authority over the Linux operating system. In this chapter, we will examine the kernel and learn what it does for us and for the operating system.
In this chapter, you also learn how to obtain the kernel sources, as well as how and when to patch the kernel. The chapter leads you through an expert’s tour of the kernel architecture and teaches you essential steps in kernel configuration, how to build and install modules, and how to compile drivers in Fedora. This chapter also teaches you important aspects of working with GRUB, the default Fedora boot loader. Finally, the chapter’s troubleshooting information will help you understand what to do when something goes wrong with your Linux kernel installation or compilation process. As disconcerting as these problems can seem, this chapter shows you some easy fixes for many kernel problems.
Most users find that the precompiled Fedora kernel suits their needs. At some point, you might need to recompile the kernel to support a specific piece of hardware or add a new feature to the operating system. If you have heard horror stories about the difficulties of recompiling the Linux kernel, you can relax; this chapter gives you all the information you need to understand when recompiling is necessary and how to painlessly work through the process.
The Linux kernel is the management part of the operating system that many people call “Linux.” Although many think of the entire distribution as Linux, the only piece that can correctly be called Linux is the kernel. Fedora, like many Linux distributions, includes a kernel packaged with add-on software that interacts with the kernel so that the user can interface with the system in a meaningful manner.
The system utilities and user programs enable computers to become valuable tools to a user.
The source code for the Linux kernel is kept in a group of directories called the kernel source tree. The structure of the kernel source tree is important because the process of compiling (building) the kernel is automated; it is controlled by scripts interpreted by the make application. These scripts, known as Makefiles, expect to find the pieces of the kernel code in specific places or they will not work. You will learn how to use make to compile a kernel later in this chapter.
It is not necessary for the Linux kernel source code to be installed on your system for the system to run or for you to accomplish typical tasks such as email, web browsing, or word processing. It is necessary that the kernel sources be installed, however, if you want to compile a new kernel. In the next section, we will show you how to install the kernel source files and how to set up the special symbolic link required. That link is /usr/src/kernels/<yourkernelversion>, and it is how we will refer to the directory of the kernel source tree as we examine the contents of the kernel source tree.
The /usr/src/kernels/<yourkernelversion> directory contains the .config and the Makefile files among others. The .config file is the configuration of your Linux kernel as it was compiled. There is no .config file by default; you must select one from the /configs subdirectory. There you will find configuration files for each flavor of the kernel Fedora provides; simply copy the one appropriate for your system to the default directory and rename it .config.
We have already discussed the contents of the /configs subdirectory, so let us examine the other directories found under /usr/src/kernels/<yourkernelversion>. The most useful for us is the Documentation directory. In it and its subdirectories, you will find almost all the documentation concerning every part of the kernel. The 00-INDEX file (each Documentation subdirectory also contains a 00-INDEX file as well) contains a list of the files in the main directory and a brief explanation of what they are. Many files are written solely for kernel programmers and application writers, but a few are useful to the intermediate or advanced Linux user when attempting to learn about kernel and device driver issues. Some of the more interesting and useful documents are
devices.txt—. A list of all possible Linux devices that are represented in the/devdirectory, giving major and minor numbers and a short description. If you have ever gotten an error message that mentionschar-major-xxx, this file is where that list is kept. Devices are mentioned in Chapter 38, “Managing the File System.”ide.txt—. If your system uses IDE hard drives, this file discusses how the kernel interacts with them and lists the various kernel commands that can be used to solve IDE-related hardware problems, manually set data transfer modes, and otherwise manually manage your IDE drives. Most of this management is automatic, but if you want to understand how the kernel interacts with IDE devices, this file explains it.initrd.txt—. Chapter 38 also discusses the initial RAM disk. This file provides much more in-depth knowledge of initial RAM disks, giving details on the loopback file system used to create and mount them and explaining how the kernel interacts with them.kernel-parameters.txt—. This file is a list of most of the arguments that you can pass at boot time to configure kernel or hardware settings, but it does not appear too useful at first glance because it is just a list. However, knowing that a parameter exists and might relate to something you are looking for can assist you in tracking down more information because now you have terms to enter into an Internet search engine such as http://www.google.com/linux.sysrq.txt—. If you have ever wondered what that SysRq key on your keyboard is used for, this file has the answer. Briefly, it is a key combination hardwired into the kernel that can help you recover from a system lockup. Fedora disables this function by default for security reasons. You can re-enable it by entering the command# echo "1" > /proc/sys/kernel/sysrqand disable it by echoing a value of0instead of1.
In the other directories found in Documentation, you will find similar text files that deal with the kernel modules for CD-ROM drivers, file system drivers, gameport and joystick drivers, video drivers (not graphics card drivers—those belong to X11R6 and not to the kernel), network drivers, and all the other drivers and systems found in the Linux operating system. Again, these documents are usually written for programmers, but they can provide useful information to the intermediate and advanced Linux user as well.
The directory named scripts contains many of the scripts that make uses. It really does not contain anything of interest to anyone who is not a programmer or a kernel developer (also known as a kernel hacker).
After a kernel is built, all the compiled files will wind up in the arch directory and its subdirectories. Although you can manually move them to their final location, we will show you later in this chapter how the make scripts will do it for you. In the early days of Linux, this post-compilation file relocation was all done by hand; you should be grateful for make.
Note
The make utility is a very complex program. Complete documentation on the structure of Makefiles, as well as the arguments that it can accept, can be found at http://www.gnu.org/software/make/manual/make.html.
The remainder of the directories contain the source code for the kernel and the kernel drivers. When you install the kernel sources, these files are placed there automatically. When you patch kernel sources, these files are altered automatically. When you compile the kernel, these files are accessed automatically. Although you never need to touch the source code files, they can be useful. The kernel source files are nothing more than text files with special formatting, which means that we can look at them and read the programmers’ comments. Sometimes, a programmer will write an application, but cannot (or often will not) write the documentation. The comments he puts in the source code are often the only documentation that exists for the code.
Small testing programs are even hidden in the comments of some of the code, along with comments and references to other information. Because the source code is written in a language that can be read as easily—almost—as English, a nonprogrammer might be able to get an idea of what the application or driver is actually doing (see Chapter 33, “C/C++ Programming Tools for Fedora”). This information might be of use to an intermediate-to-advanced Linux user when he is confronted by kernel- and driver-related problems.
Note
The interaction and control of hardware is handled by a small piece of the kernel called a device driver. The driver tells the computer how to interact with a modem, a SCSI card, a keyboard, a mouse, and so on in response to a user prompt. Without the device driver, the kernel does not know how to interact with the associated device.
In the early days of Linux, kernels were a single block of code containing all the instructions for the processor, the motherboard, and the other hardware. If you changed hardware, you were required to recompile the kernel code to include what you needed and discard what you did not. Including extra, unneeded code carried a penalty since the kernel became larger and occupied more memory. On older systems that had only 4MB–8MB of memory, wasting precious memory for unnecessary code was considered unacceptable. Kernel compiling was something of a black art as early Linux users attempted to wring the most performance from their computers. These kernels compiled as a single block of code are called monolithic kernels.
As the kernel code grew larger and the number of devices that could be added to a computer increased, the requirement to recompile became onerous. A new method of building the kernel was developed to make the task of compiling easier. The part of the kernel’s source code that composed the code for the device drivers could be optionally compiled as a module that could be loaded and unloaded into the kernel as required. This is known as the modular approach to building the kernel. Now, all the kernel code could be compiled at once—with most of the code compiled into these modules. Only the required modules would be loaded; the kernel could be kept smaller, and adding hardware was much simpler.
The typical Fedora kernel has some drivers compiled as part of the kernel itself (called inline drivers) and others compiled as modules. Only device drivers compiled inline are available to the kernel during the boot process; modular drivers are available only after the system has been booted.
Note
As a common example, drivers for SCSI disk drives must be available to the kernel if you intend to boot from SCSI disks. If the kernel is not compiled with those drivers inline, the system will not boot because it will not be able to access the disks.
A way around this problem for modular kernels is to use an initial RAM disk (initrd) discussed later in “Creating an Initial RAM Disk Image.” The initrd loads a small kernel and the appropriate device driver, which then can access the device to load the actual kernel you want to run.
Some code can only be one or the other (for technical reasons unimportant to the average user), but most code can be compiled either as modular or inline. Depending on the application, some system administrators prefer one way over the other, but with fast modern processors and abundant system memory, the performance differences are of little concern to all but the most ardent Linux hackers.
When compiling a kernel, the step in which you make the selection of modular or inline is part of the make config step that we will detail later in this chapter. Unless you have a specific reason to do otherwise, we suggest that you select the modular option when given a choice. The process of managing modules is addressed in the next section because you will be managing them more frequently than you will be compiling a kernel.
When using a modular kernel, special tools are required to manage the modules. Modules must be loaded and unloaded, and it would be nice if that were done as automatically as possible. We also need to be able to pass necessary parameters to modules when we load them—things such as memory addresses and interrupts. (That information varies from module to module, so you will need to look at the documentation for your modules to determine what, if any, information needs to be passed to it.) In this section, we will cover the tools provided to manage modules and then look at a few examples of using them.
Linux provides the following module management tools for our use. All these commands (and modprobe.conf) have man pages:
lsmod—. This command lists the loaded modules. It is useful to pipe this through thelesscommand because the listing is usually more than one page long.insmod—. This command loads the specified module into the running kernel. If a module name is given without a full path, the default location for the running kernel,/lib/modules/*/, will be searched. Several options are offered for this command—the most useful is-f, which forces the module to be loaded.rmmod—. This command unloads (removes) the specified module from the running kernel. More than one module at a time can be specified.modprobe—. A more sophisticated version ofinsmodandrmmod, it uses the dependency file created bydepmodand automatically handles loading, or with the-roption, removing modules. There is no force option, however. A useful option to modprobe is-t, which causesmodprobeto cycle through a set of drivers until it finds one that matches your system. If you were unsure of what module would work for your network card, you would use this command:# modprobe -t net
The term
netis used because that is the name of the directory (/lib/modules/*/kernel/net)where all the network drivers are kept. It tries each one in turn until it loads one successfully.
modinfo—. This queries a module’s object file and provides a list of the module name, author, license, and any other information that is there. It often is not very useful.depmod—. This program creates a dependency file for kernel modules. Some modules need to have other modules loaded first; that is, they depend on the other modules. (A lot of the kernel code is like this because it eliminates redundancy in the code base.) During the boot process, one of the startup files contains the commanddepmod -aand it is run every time you boot to re-create the file/lib/modules/*/modules.dep. If you make changes to the/etc/modprobe.conffile, rundepmod -amanually. Thedepmodcommand, its list of dependencies, and the/etc/modprobe.conffile enable kernel modules to be automatically loaded as needed./etc/modprobe.conf—. This is not a command, but a file that controls howmodprobeanddepmodbehave; it contains kernel module variables. Although the command syntax can be quite complex, most actual needs are very simple. The most common use is to alias a module and then pass it some parameters. For example, in the following code, we alias a device name (fromdevices.txt) to a more descriptive word and then pass some information to an associated module. Thei2c-devdevice is used to read the CPU temperature and fan speed on our system. These lines for/etc/modprobe.confwere suggested for our use by the program’s documentation. We added them with a text editor.alias char-major-89 i2c-dev options eeprom ignore=2,0x50,2,0x51,2,0x52
A partial listing of lsmod is shown here, piped through the less command, allowing us to view it a page at a time:
# lsmod | less Module Size Used by parport_pc 19392 1 Module Size Used by parport_pc 19392 1 lp 8236 0 parport 29640 2 parport_pc,lp autofs4 10624 0 sunrpc 101064 1
The list is actually much longer, but here we see that the input module is being used by the joydev (joystick device) module, but the joystick module is not being used. This computer has a joystick port that was auto-detected, but no joystick is connected. A scanner module is also loaded, but because the USB scanner is unplugged, the module is not being used. You would use the lsmod command to determine whether a module was loaded and what other modules were using it. If you examine the full list, you would see modules for all the devices attached to your computer.
To remove a module, joydev in this example, use
# rmmod joydev
or
# modprobe -r joydev
A look at the output of lsmod would now show that it is no longer loaded. If we removed input as well, we could then use modprobe to load both input and joydev (one depends on the other, remember) with a simple
# modprobe joydev
If Fedora were to balk at loading a module (because it had been compiled using a different kernel version from what we are currently running; for example, the NVIDIA graphics card module), we could force it to load like this:
# insmod -f nvidia
We would ignore the complaints (error messages) in this case if the kernel generated any.
In Chapter 10, “Multimedia Applications,” we talked about loading a scanner module; in the example there, we manually loaded the scanner module and passed it the vendor ID. The scanner was not included in the lookup list because it is not supported by the GPL scanner programs; as a result, the scanner module was not automatically detected and loaded. However, the scanner will work with a closed-source application after the module is loaded. Automatic module management is nice when it works, but sometimes it is necessary to work with modules directly.
Fedora systems use a modified version of the plain vanilla Linux kernel (a modified version is referred to as a patched kernel) with additional drivers and other special features compiled into it.
Fedora has quite an intensive testing period for all distribution kernels and regularly distributes updated versions. The supplied Fedora kernel is compiled with as many modules as possible to provide as much flexibility as possible. A running kernel can be further tuned with the sysctl program, which enables direct access to a running kernel and permits some kernel parameters to be changed. As a result of this extensive testing, configurability, and modularity, the precompiled Fedora kernel does everything most users need it to do. Most users only need to recompile the kernel to
Accommodate an esoteric piece of new hardware
Conduct a system update when Fedora has not yet provided precompiled kernels
Experiment with the system capabilities
Fedora supplies several precompiled versions of the kernel for Athlon and Pentium processors, for single- and multi-processor motherboards, and for enterprise-class systems (higher security; uses 4GB of memory). These kernel versions are provided in RPM format. Installing them is as easy as
# rpm -Uvh new_kernel.rpm
The kernel (but not the source) RPM files include installation scripts that automatically alter your bootloader configuration, making the new kernel the default. If you do not want that to happen, just manually edit the /etc/lilo.conf or /boot/grub/grub.conf files and change them back.
The Linux kernel is in a constant state of development. As new features are added, bugs are fixed and new technology is incorporated into the code base, it becomes necessary to provide stable releases of the kernel for use in a production environment. It is also important to have separate releases that contain the newest code for developers to test. To keep track of the kernels, version numbers are assigned to them. Programmers enjoy using sequential version numbers that have abstract meaning. Is version 8 twice as advanced as version 4 of the same application? Is version 1 of one application less developed than version 3 of another? The version numbers cannot be used for this kind of qualitative or quantitative comparison. It is entirely possible that higher version numbers can have fewer features and more bugs than older versions. The numbers exist solely to differentiate and organize sequential revisions of software.
For the latest development version of the kernel at the time of writing, for example, the kernel version number is 2.6.10-1.
The kernel version can be broken down into four sections:
major version—. This is the major version number, now at2.minor version—. This is the minor version number, now at6.sublevel number—. This number indicates the current iteration of the kernel; here it is number10.extraversion level—. This is the number representing a collection of patches and additions made to the kernel by the Red Hat engineers to make the kernel work for them (and you). Each collection is numbered, and the number is indicated here in the kernel name. From our preceding example, it is1.
Typing uname -r at the command prompt displays your current kernel version.
# uname -r
2.6.10-1
Even-numbered minor versions are stable kernels, whereas odd-numbered minor versions are development releases. Version 2.6.x is the stable production kernel, whereas version 2.5.x is the development Linux kernel. When a new version of the development kernel is started, it will be labeled 2.7.x.
For production machines, you should always use the kernels with even minor numbers. The odd minor numbers introduce new features, so you might want to use those on a test machine if you need features they provide.
The Linux kernel has always been freely available to anyone who wants it. If you just want to recompile the existing kernel, install the kernel-sources RPM from the CD. To get the very latest vanilla version, open an FTP connection to ftp.kernel.org using your favorite FTP client and log in as anonymous. Because you are interested in the 2.6 kernel, change directories to /pub/linux/kernel/v2.6. The latest stable kernel as of this writing is 2.6.15.
Note
ftp.kernel.org receives more than its share of requests for download. It is considered a courtesy to use a mirror site to reduce the traffic that ftp.kernel.org bears. http://www.kernel.org/mirrors/ has a list of all mirrors around the world. Find one close to your geographic location and substitute that address for ftp.kernel.org.
A number of different entries are on the FTP archive site for each kernel version, but because you are interested in only the full kernel, it is only necessary to get the full package of source code. There are two of these packages:
linux-2.6.15.tar.gz linux-2.6.15.bz2
Although these are the same kernel packages, they are built using different compression utilities: The .gz extension is the gzip package, found on almost every Linux system available. The .bz2 extension is the newer bzip2 utility, which has better compression than gzip. Both packages have the same content, so download the one compressed with the program you use.
After it is downloaded, move the package to a directory other than /usr/src and unpack it. If you downloaded the .gz package, the unpacking command is tar -xzvf linux-2.6.15.tar.gz. Otherwise, the bzip2 unpack command is tar -xjvf linux-2.6.15.tar.bz2. When it is unpacked, the package creates a new directory, linux-2.6.15. Copy it to /usr/src/kernels or move it there. Then create a symbolic link of linux-2.6 to linux-2.6.15 (otherwise, some scripts will not work). Here is how to create the symbolic link:
# rm /usr/src/kernels/linux-2.6 # ln -s /usr/src/kernels/linux-2.6.15 /usr/src/kernels/linux-2.6
By creating a symbolic link to /usr/src/linux-2.6, it is possible to allow multiple kernel versions to be compiled and tailored for different functions: You just change the symbolic link to the kernel directory you want to work on.
It is possible to patch a kernel to the newest Linux kernel version as opposed to downloading the entire source code. This choice can be beneficial for those who are not using a high-speed broadband connection. (A typical compressed kernel source file is nearly 30MB for a download time of about 10 minutes on a 512Kb DSL connection; adjust accordingly for your connection.) Whether you are patching existing sources or downloading the full source, the end results will be identical.
Patching the kernel is not a mindless task. It requires the user to retrieve all patches from her current version to the version she wants to upgrade to. For example, if you are currently running 2.6.1 (and have those sources) and want to upgrade to 2.6.8, you must retrieve the 2.6.2, and 2.6.3 patch sets, and so on. After they are downloaded, these patches must be applied in succession to upgrade to 2.6.8. This is more tedious than downloading the entire source, but useful for those who keep up with kernel hacking and want to perform incremental upgrades to keep their Linux kernel as up-to-date as possible.
To patch up to several versions in a single operation, you can use the patch-kernel script located in the kernel source directory for the kernel version you currently use. This script applies all necessary version patches to bring your kernel up to the latest version.
The format for using the patch-kernel script looks like this:
patch-kernel source_dir patch_dir stopversion
The source directory defaults to /usr/src/linux if none is given, and the patch_dir defaults to the current working directory if one is not supplied.
For example, assume that you have a 2.6.6 kernel code tree that needs to be patched to the 2.6.8 version. The 2.6.7 and 2.6.8 patch files have been downloaded from ftp.kernel.org and are placed in the /patch directory in the source tree. You issue the following command in the /usr/src/kernels/linux-2.6 directory:
# scripts/patch-kernel /usr/src/kernels/linux-2.6.15 /usr/src/kernels/linux-2.6.15/patch
Each successive patch file is applied, eventually creating a 2.6.8 code tree. If any errors occur during this operation, files named xxx# or xxx.rej are created, where xxx is the version of patch that failed. You have to resolve these failed patches manually by examining the errors and looking at the source code and the patch. An inexperienced person will not have any success with this because you must understand C programming and kernel programming to know what is broken and how to fix it. Because this was a stock 2.6.6 code tree, the patches were all successfully applied without errors. If you are attempting to apply a nonstandard third-party patch, the patch will likely fail.
When you have successfully patched the kernel, you are ready to begin compiling this code tree as if we started with a fresh, stock 2.6.8 kernel tree.
If you want to update the kernel from new source code you have downloaded or you have applied a patch to add new functionality or hardware support, you will have to compile and install a new kernel to actually use that new functionality. Compiling the kernel involves translating the kernel’s contents from human-readable code to binary form. Installing the kernel involves putting all the compiled files where they belong in /boot and /lib and making changes to the bootloader.
The process of compiling the kernel is almost completely automated by the make utility, as is the process of installing. By providing the necessary arguments and following the steps covered next, you can recompile and install a custom kernel for your use.
Here is a checklist of steps to compile and configure the kernel:
Verify a working bootdisk for the old kernel to be able to reboot your system in case something goes wrong with the new kernel.
Caution
Before making any changes to your current, working kernel, make sure that you have a backup copy on a floppy disk. This will allow you to boot into your system with a known working kernel in case something goes wrong during configuration. The command to do this is as follows:
# mkbootdisk --device /dev/fd0 'uname -r'
This assumes that your floppy drive is
/dev/fd0. (Here is a good shell script tip: The'character tells the shell to execute what is within'first and then returns that output as part of the input of themkbootdiskcommand.) On this machine, the result is# mkbootdisk --device /dev/fd0 2.6.7-1
This command will not be echoed to your screen, but it is what the system will execute.
Apply all patches, if any, so that you have the features you desire. See the previous section for details.
Back up the
.configfile, if it exists, so that you can recover from the inevitable mistake. Use the followingcpcommand:# cp .config .config.bak
Note
If you are recompiling the Fedora default kernel, the
/usr/src/kernels/linux-2.6/configsdirectory contains several versions of configuration files for different purposes.Fedora provides a full set of
.configfiles in the subdirectory configs, all named for the type of system they were compiled for. For example,kernel-2.6.7-i686-smp.configis a configuration file for a multiprocessor Pentium-class computer. If you want to use one of these default configurations as the basis for a custom kernel, simply copy the appropriate file to/usr/src/kernels/linux-2.6and rename it.config.Run the
make mrproperdirective to prepare the kernel source tree, cleaning out any old files or binaries.Restore the
.configfile that the commandmake mrproperdeleted, and edit the Makefile to change theEXTRAVERSIONnumber.Modify the kernel configuration file using
make config,make menuconfig, ormake xconfig—we recommend the latter, but read the text following these numbered instructions for more details.Run
make depto create the code dependencies used later in the compilation process.Tip
If you have a multiprocessor machine, you can use both processors to speed the make process by inserting
-jxafter themakecommand, where as a rule of thumb,xis one more than the number of processors you have. You might try a larger number and even try this on a single-processor machine (we have used-j8successfully on an SMP machine); it only loads up your CPU. For example,# make -j3 bzImage
All the
makeprocesses exceptmake depwork well with this method of parallel compiling.Run
make cleanto prepare the sources for the actual compilation of the kernel.Run
make bzImageto create a binary image of the kernel.Note
Several choices of directives exist, although the most common ones are as follows:
zImage—. This directive compiles the kernel, creating an uncompressed file calledzImage.bzImage—. This directive creates a compressed kernel image necessary for some systems that require the kernel image to be under a certain size for the BIOS to be able to parse them; otherwise, the new kernel will not boot. It is the most commonly used choice. However, the Fedora kernel compiled withbzImageis still too large to fit on a floppy, so a smaller version with some modules and features removed is used for the boot floppies. Fedora recommends that you boot from the rescue CD-ROM.bzDisk—. This directive does the same thing asbzImage, but it copies the new kernel image to a floppy disk for testing purposes. This is helpful for testing new kernels without writing kernel files to your hard drive. Make sure that you have a floppy disk in the drive because you will not be prompted for one.Run
make modulesto compile any modules your new kernel needs.Run
make modules_installto install the modules in/lib/modulesand create dependency files.Run
make installto automatically copy the kernel to/boot, create any other files it needs, and modify the bootloader to boot the new kernel by default.Using your favorite text editor, verify the changes made to
/etc/lilo.confor/boot/grub/grub.conf; fix if necessary and rerun/sbin/liloif needed.Reboot and test the new kernel.
Repeat the process if necessary, choosing a configuration interface.
Over time, the process for configuring the Linux kernel has changed. Originally, you configured the kernel by responding to a series of prompts for each configuration parameter (this is the make config utility described shortly). Although you can still configure Linux this way, most users find this type of configuration confusing and inconvenient; moving back through the prompts to correct errors, for instance, is impossible.
The make config utility is a command-line tool. The utility presents a question regarding kernel configuration options. The user responds with a Y, N, M, or ? (it is not case sensitive). Choosing M configures the option to be compiled as a module. A response of ? displays context help for that specific option, if available. (If you choose ? and no help is available, you can turn to the vast Internet resources to find information.) We recommend that you avoid the make config utility, shown in Figure 40.1.
If you prefer to use a command-line interface, you can use make menuconfig to configure the Linux kernel. menuconfig provides a graphical wrapper around a text interface. Although it is not as raw as make config, menuconfig is not a fancy graphical interface either; you cannot use a mouse, but must navigate through it using keyboard commands. The same information presented in make config is presented by make menuconfig, but as you can see in Figure 40.2, it looks a little nicer. Now, at least, you can move back and forth in the selection process in case you change your mind or have made a mistake.
In make menuconfig, you use the arrow keys to move the selector up and down and the spacebar to toggle a selection. The Tab key moves the focus at the bottom of the screen to either Select, Exit, or Help.
If a graphical desktop is not available, menuconfig is the best you can do. However, both menuconfig and xconfig (see later discussion) offer an improvement over editing the .config file directly. If you want to configure the kernel through a true graphical interface—with mouse support and clickable buttons—make xconfig is the best configuration utility option. To use this utility, you must have the X Window System running. The application xconfig is really nothing but a Tcl/Tk graphics widget set providing borders, menus, dialog boxes, and the like. Its interface is used to wrap around data files that are parsed at execution time. Figure 40.3 shows the main menu of xconfig for the 2.6.7 kernel.
After loading this utility, you use it by clicking on each of the buttons that list the configuration options. Each button you click opens another window that has the detail configuration options for that subsection. Three buttons are at the bottom of each window: Main Menu, Next, and Prev(ious). Clicking the Main Menu button closes the current window and displays the main window. Clicking Next takes you to the next configuration section. When configuring a kernel from scratch, click the button labeled Code Maturity Level Options, and then continue to click the Next button in each subsection window to proceed through all the kernel configuration choices. When you have selected all options, the main menu is again displayed. The buttons on the lower right of the main menu are for saving and loading configurations. Their functions are self-explanatory. If you just want to have a look, go exploring! Nothing will be changed if you elect not to save it.
If you are upgrading kernels from a previous release, it is not necessary to go though the entire configuration from scratch. Instead, you can use the make oldconfig directive; it uses the same text interface that make config uses, and it is noninteractive. It just prompts for changes for any new code.
For simplicity’s sake, during this brisk walkthrough, we assume that you are using make xconfig. Prior to this point, we also assume that you have completed the first five steps in our kernel compilation checklist shown previously.
As you learned in the preceding section, you configure the kernel using make xconfig by making choices in several configuration subsection windows. Each subsection window contains specific kernel options. With hundreds of choices, the kernel is daunting to configure. We cannot really offer you detailed descriptions of which options to choose because your configuration will not match your own system and setup.
Table 40.1 provides a brief description of each subsection’s options so that you can get an idea of what you might encounter. We recommend that you copy your kernel’s .config file to /usr/src/kernels/linux-2.6 and run make xconfig from there. Explore all the options. As long as you do not save the file, absolutely nothing will be changed on your system.
Table 40.1. Kernel Subsections for Configuration
Name | Description |
|---|---|
Code maturity level options | Enables development code to be compiled into the kernel even if it has been marked as obsolete or as testing code only. This option should only be used by kernel developers or testers because of the possible unusable state of the code during development. |
General setup | Contains several different options covering how the kernel talks to the BIOS, whether it should support PCI or PCMCIA, whether it should use APM or ACPI, and what kind of Linux binary formats will be supported. Contains several options for supporting kernel structures necessary to run binaries compiled for other systems directly without recompiling the program. |
Loadable module support | Determines whether the kernel enables drivers and other nonessential code to be compiled as loadable modules that can be loaded and unloaded at runtime. This option keeps the basic kernel small so that it can run and respond more quickly; in that regard, choosing this option is generally a good idea. |
Processor type and features | Several options dealing with the architecture that will be running the kernel. |
Power management options | Options dealing with ACPI and APM power management features. |
Bus options | Configuration options for the PCMCIA bus found in laptops and PCI hotplug devices. |
Memory Technology | Options for supporting flash memory devices, such as EEPROMS. |
Devices (MTD) | Generally, these devices are used in embedded systems. |
Parallel port support | Several options for configuring how the kernel will support parallel port communications. |
Plug and Play configuration | Options for supporting Plug and Play PCI, ISA, and plug-and-play BIOS support. Generally, it is a good idea to support plug-and-play for PCI and ISA devices. |
Block devices | Section dealing with devices that communicate with the kernel in blocks of characters instead of streams. This includes IDE and ATAPI devices connected via parallel ports, as well as enabling network devices to communicate as block devices. |
ATA/IDE/MFM/RLL support | Large collection of options to configure the kernel to communicate using different types of data communication protocols to talk to mass storage devices, such as hard drives. Note that this section does not cover SCSI. |
SCSI support | Options for configuring the kernel to support Small Computer Systems Interface. This subsection covers drivers for specific cards, chipsets, and tunable parameters for the SCSI protocol. |
Old CD-ROM drivers (not SCSI, not IDE) | Configuration options to support obscure, older CD-ROM devices that do not conform to the SCSI or IDE standards. These are typically older CD-ROM drivers that are usually a proprietary type of SCSI. |
Multi-device support (RAID and LVM) | Options for enabling the kernel to support RAID devices in software emulation and the different levels of RAID. Also contains options for support of a logical volume manager. |
Fusion MPT device support | Configures support for LSI’s Logic Fusion Message Passing Technology. This technology is for high performance SCSI and local area network interfaces. |
IEEE1394 (FireWire) support | Experimental support for FireWire devices. |
I20 device support | Options for supporting the Intelligent Input/Output architecture. This architecture enables the hardware driver to be split from the operating system driver, thus enabling a multitude of hardware devices to be compatible with an operating system in one implementation. |
Networking options | Several options for the configuration of networking in the kernel. The options are for the types of supported protocols and configurable options of those protocols. |
Amateur radio support | Options for configuring support of devices that support the AX25 protocol. |
IrDA (infrared) support | Options for configuring support of the Infrared Data Association suite of protocols and devices that use these protocols. |
Bluetooth support | Support for the Bluetooth wireless protocol. Includes options to support the Bluetooth protocols and hardware devices. |
ISDN subsystem | Options to support Integrated Services Digital Networks protocols and devices. ISDN is a method of connection to a large area network digitally over conditioned telephone lines, largely found to connect users to ISPs. |
Telephony support | Support for devices that enable the use of regular telephone lines to support VOIP applications. This section does not handle the configuration of modems. |
Input core support | Options for configuring universal serial bus (USB) human interface devices (HIDs). These include keyboards, mice, and joysticks. |
Character devices | Configuration options for devices that communicate to the server in sequential characters. This is a large subsection containing the drivers for several motherboard chipsets. |
Multimedia devices | Drivers for hardware implementations of video and sound devices such as video capture boards, TV cards, and AM/FM radio adapter cards. |
Graphics support | Configures VGA text console, video mode selection, and support for frame buffer cards. |
Sound | Large subsection to configure supported sound card drivers and chipset support for the kernel. |
USB support | Universal Serial Bus configuration options. Includes configuration for USB devices, as well as vendor-specific versions of USB. |
File systems | Configuration options for supported file system types. Refer to Chapter 38 for a description of the file systems supported by the kernel. |
Additional device driver support | Third-party patches. |
Profiling support | Profiling kernel behavior information to aid in debugging and development. |
Kernel hacking | Determines whether the kernel will contain advanced debugging options. Most users will not want to include this option in their production kernels because it increases the kernel size and slows performance by adding extra routines. |
Security options | Determines whether NSA Security Enhanced Linux (SELinux) is enabled. |
Cryptographic options | Support for cryptography hardware (Fedora patches not found in the vanilla kernel sources). |
Library routines | Contains zlib compression support. |
After you select all the options you want, you can save the configuration file and continue with step 7 in the kernel compiling checklist shown earlier.
If you require special device drivers to be loaded in order to mount the root file system (for SCSI drives, network cards or exotic file systems, for example), you must create an initial RAM disk image named /boot/initrd.img. For most users, it is not necessary to create this file, but if you are not certain, it really does not hurt. We covered the initrd.img in Chapter 38. To create an initrd.img file, use the shell script /sbin/mkinitrd.
The format for the command is the following:
/sbin/mkinitrd file_name kernel_version
where file_name is the name of the image file you want created.
mkinitrd looks at /etc/fstab, /etc/modprobe.conf, and /etc/ raidtab to obtain the information it needs to determine which modules should be loaded during boot. For our system, we use
# mkinitrd initrd-2.6.7-1.img 2.6.7-1
Several things might go wrong during a kernel compile and installation, and several clues will point to the true problem. You will see error messages printed to the screen, and some error messages will be printed to the file /var/log/messages, which can be examined with a text editor. If you have followed our directions for patching the kernel, you will have to examine a special error log as well. Do not worry about errors because many problems are easily fixed with some research on your part. Some errors may be unfixable, however, depending on your skill level and the availability of technical information.
Although it is rare that the kernel will not compile, there is always a chance that something has slipped though the regression testing. Let’s take a look at an example of a problem that might crop up during the compile.
It is possible that the kernel compile will crash and not complete successfully, especially if you attempt to use experimental patches, add untested features, or build newer and perhaps unstable modules on an older system. For example, the kernel compile will fail on an older stock Red Hat 7.2 installation using the 2.4.9 kernel when selecting the NTFS file system, either as a loadable module or inline, as shown here:
gcc -D__KERNEL__ -I/usr/src/kernels/linux-2.4.9/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=athlon -DMODULE -DMODVERSIONS -include /usr/src/kernels/linux-2.4.9/include/linux/modversions.h -DNTFS_VERSION="1.1.16" Â -c -o unistr.o unistr.c unistr.c: In function 'ntfs_collate_names': unistr.c:99: warning: implicit declaration of function 'min' unistr.c:99: parse error before 'unsigned' unistr.c:99: parse error before ')' unistr.c:97: warning: 'c1' might be used uninitialized in this function unistr.c: At top level: unistr.c:118: parse error before 'if' unistr.c:123: warning: type defaults to 'int' in declaration of 'c1' unistr.c:123: 'name1' undeclared here (not in a function) unistr.c:123: warning: data definition has no type or storage class unistr.c:124: parse error before 'if' make[2]: *** [unistr.o] Error 1 make[2]: Leaving directory '/usr/src/kernels/linux-2.4.9/fs/ntfs' make[1]: *** [_modsubdir_ntfs] Error 2 make[1]: Leaving directory '/usr/src/kernels/linux-2.4.9/fs' make: *** [_mod_fs] Error 2
At this juncture, you have two options:
Fix the errors and recompile
Remove the offending module or option and wait for the errors to be fixed by the kernel team
Most users will be unable to fix some errors because of the complexity of the kernel code, although you should not rule out this option. It is possible that someone else discovered the same error during testing of the kernel and developed a patch for the problem: Check the Linux kernel mailing list archive. If the problem is not mentioned there, a search on Google might turn up something.
The second option, removing the code, is the easiest and is what most people do in cases in which the offending code is not required. In the case of the NTFS module failing, it is almost expected because NTFS support is still considered experimental and subject to errors. This is primarily because the code for the file system is reverse-engineered instead of implemented via documented standards. Read-only support has gotten better in recent kernels; write support is still experimental.
Finally, should you want to take on the task of trying to fix the problem yourself, this is a great opportunity to get involved with the Linux kernel and make a contribution that could help many others.
If you are knowledgeable about coding and kernel matters, you might want to look in the MAINTAINERS file in the /usr/src/kernels/linux-2.6/ directory of the kernel source and find the maintainer of the code. The recommended course of action is to contact the maintainer and see if he is aware of the problems you are having. If nothing has been documented for the specific error, submitting the error to the kernel mailing list is an option. The guidelines for doing this are in the README file in the “If Something Goes Wrong” section under the base directory of the kernel source.
Runtime errors occur as the kernel is loading. Error messages are displayed on the screen or written to the /var/log/messages file. Bootloader problems display messages to the screen; no log file is produced. Kernel oops are errors in a running kernel, and error messages are written to the /var/log/messages file.
Excellent documentation on the Internet exists for troubleshooting just about every type of error that LILO, GRUB, or the kernel could give during boot. The best way to find this documentation is to go to your favorite search engine and type in the keywords of the error you received. You will need to adjust the keywords you use as you focus your search.
In this category, the most common problems deal with LILO configuration issues. Diagnosis and solutions to these problems can be found in the LILO mini-HOWTO found on the Linux Documentation project’s website at http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/LILO.html.
If you have GRUB problems, the GRUB manual is online at http://www.gnu.org/software/grub/manual/.
Tip
For best results, go to http://www.google.com/linux to find all things Linux on the Internet. Google has specifically created a Linux area of its database, which should allow faster access to information on Linux than any other search engine.
Usenet newsgroup postings are searchable at http://www.google.com/grphp.
Mail list discussions can be searched in the Mailing listARChives (MARC) at http://marc.theaimsgroup.com/.
http://www.kernel.org/—The Linux Kernel Archives. The source of all development discussion for the Linux kernel.
http://www.kerneltraffic.org/kernel-traffic/index.html—Linux Kernel Traffic. Summarized version and commentary of the Linux Kernel mailing list produced weekly.
http://www.gnu.org/—The Free Software Foundation. Source of manuals and software for programs used throughout the kernel compilation process. Tools such as make and gcc have their official documentation here.
http://slashdot.org/article.pl?sid=01/08/22/1453228&mode=thread—The famous AC Patches from Alan Cox, for whom they are named.
http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html—The Linux Kernel Rebuild Guide; configuration, compilation, and troubleshooting.
http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/KernelAnalysis-HOWTO.html—KernelAnalysis HOWTO. Describes the mysterious inner workings of the kernel.
http://www.tldp.org/HOWTO/Module-HOWTO/—Kernel Module HOWTO. Includes a good discussion about unresolved symbols.
http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Modules.html—The Linux Kernel Modules Installation HOWTO; an older document discussing recompiling kernel modules.
http://www.tldp.org/—The Linux Documentation Project. The Mecca of all Linux documentation. Excellent source of HOWTO documentation, as well as FAQs and online books, all about Linux.
http://www.minix.org/—The unofficial minix website. It contains a selection of links to information about minix and a link to the actual homepage. Although minix is still copyrighted, the owner has granted unlimited rights to everyone. See for yourself the operating system used to develop Linux.
http://jungla.dit.upm.es/~jmseyas/linux/kernel/hackers-docs.html—A web page with links to Linux kernel documentation, books, hacker tomes, and other helpful information for budding and experienced Linux kernel and kernel module developers. This list also will be found in the /usr/src/kernels/linux-2.6/Documentation/kernel-docs.txt file if you install the Fedora kernel sources.