Chapter 22. Kernel and Module Management
In This Chapter
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 Ubuntu, comes with its own precompiled kernel as well as the kernel source code, providing you with absolute authority over the Linux operating system. This chapter covers the kernel and what it does for us and for the operating system.
In this chapter, you also learn how to obtain the kernel sources and how and when to patch the kernel. This 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 Ubuntu. This chapter also teaches you important aspects of working with GRUB2, the default Ubuntu 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.
Almost all users find that a precompiled Ubuntu kernel suits their needs (and there are several to choose from). 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, although the Ubuntu kernel team works very hard to backport or enable any feature possible (as a module), so it is highly unlikely you will ever have a need to do this. They are also approachable and will gladly discuss specific needs and features. Sometimes features are not enabled just because no one has ever asked for or needed them. Occasionally, things are not enabled because of a conflict with another feature. The Ubuntu Kernel Team can help you discover what is going on in those cases (but don’t abuse their kindness and availability, they already work quite hard and for long hours).
Really, the main reason today for people compiling their own kernel is because they want to learn to be a kernel developer. 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 how to painlessly work through the process if you are interested in learning a new skill. This is a complex and detail-oriented task, but it is within the grasp of most technical users, even if it is completely unnecessary.
Caution
Building and using a custom kernel will make it difficult to get support for your system. Although it is a learning experience to compile your own kernel, you will not be allowed to file bugs in Ubuntu on the custom-built kernel (if you do, they will be rejected without further explanation) and if you have a commercial support contract with Ubuntu/Canonical, this will void the contract.
The Linux Kernel
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. Ubuntu, 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 Linux Source Tree
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; if they don’t find them, they will not work. You 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, you learn how to install the kernel source files and how to set up the special symbolic link required. That link is /usr/src/linux-4.1.3, and it is how you will refer to the directory of the kernel source tree as we examine the contents of the kernel source tree.
Note
The pace of change in the Linux kernel has accelerated, much like the rest of our lives. In this chapter, we chose to use the version numbers for a recent LTS release of Ubuntu. The version numbers on your system may be different, but the processes and concepts will remain the same.
The /usr/src/linux-4.1.3 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 Ubuntu 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’s examine the other directories found under /usr/src/linux-4.1.3. 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 file 00-INDEX (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 as follows:
devices.txt—A list of all possible Linux devices that are represented in the /dev directory, giving major and minor numbers and a short description. If you have ever gotten an error message that mentions char-major-xxx, this file is where that list is kept.
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 you can use 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—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 Google.
sysrq.txt—If you have ever wondered what that key on your keyboard marked SysRq 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. Ubuntu disables this function by default for security reasons. You can reenable it at a root prompt by entering the command # echo "1" > /proc/sys/kernel/sysrq, and disable it by echoing a value of 0 rather than 1.
In the other directories found in Documentation, you find similar text files that deal with the kernel modules for CD-ROM drivers, file system drivers, game port 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 also provide useful information to the intermediate and advanced Linux user.
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 wind up in the arch directory and its subdirectories. Although you can manually move them to their final location, you learn 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 complex program. You can find complete documentation on the structure of make files, as well as the arguments that it can accept, at www.gnu.org/software/make/manual/make.html.
The remaining directories in /usr/src/linux-4.1.3 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 you can look at them and read the programmer comments. Sometimes, a programmer writes an application but cannot (or often does not) write the documentation. The comments the programmer 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 38, “Using Programming Tools for Ubuntu” for an idea of how that could happen). This information might be of use to an intermediate to advanced Linux user when the user 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.
Types of Kernels
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 because the kernel became larger and occupied more memory. On older systems that had only 4MB to 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 Ubuntu 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.
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 does not boot because it cannot access the disks.
A way around this problem for modular kernels is to use an initial RAM disk (initrd), discussed later in the “Creating an Initial RAM Disk Image” section. 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 be only 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 detailed later in this chapter. Unless you have a specific reason to do otherwise, select the modular option when given a choice. Because you will be managing kernels more frequently than compiling kernels, the process of managing modules is addressed in the next section.
Managing Modules
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 need to look at the documentation for your modules to determine what, if any, information needs to be passed to it.) This section covers 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 the less command 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/*/, is 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 of insmod and rmmod, it uses the dependency file created by depmod and automatically handles loading, or with the -r option, removing modules. There is no force option, however. A useful option to modprobe is -t, which causes modprobe to cycle through a set of drivers until it finds one that matches your system. If you are unsure of what module will work for your network card, use this command:
matthew@seymour:~$ sudo modprobe -t net
The term net is 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 command depmod -a, and it is run every time you boot to re-create the file /lib/modules/*/modules.dep. If you make changes to the file /etc/modprobe.conf, run depmod -a manually. The depmod command, its list of dependencies, and the /etc/modprobe.conf file enable kernel modules to be automatically loaded as needed.
/etc/modprobe.conf—This is not a command, but a file that controls how modprobe and depmod behave; it contains kernel module variables. Although the command syntax can be quite complex, most actual needs are 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 (from devices.txt) to a more descriptive word and then pass some information to an associated module. The i2c-dev device is used to read the CPU temperature and fan speed on our system. These lines for /etc/modprobe.conf were 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, enabling us to view it a page at a time:
matthew@seymour:~$ sudo lsmod | less
Module Size Used by
parport_pc 19392 1
Module Size Used by
parport_pc 19392 1
lp 8236 0
joydev 17377 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 autodetected, 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 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 will see modules for all the devices attached to your computer.
To remove a module, joydev in this example, use the following:
matthew@seymour:~$ sudo rmmod joydev
or
matthew@seymour:~$ sudo modprobe -r joydev
The output of lsmod now shows that it is no longer loaded. If we were to remove input, as well, we could then use modprobe to load both input and joydev (one depends on the other, remember) with a simple command, as follows:
matthew@seymour:~$ sudo modprobe joydev
If Ubuntu balks at loading a module (because it was compiled using a different kernel version from what you are currently running; for example, the NVIDIA graphics card module), you could force it to load like this:
matthew@seymour:~$ sudo insmod -f nvidia
You ignore the complaints (error messages) in this case if the kernel generates any.
When to Recompile
Ubuntu 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.
Ubuntu has quite an intensive testing period for all distribution kernels and regularly distributes updated versions. The supplied Ubuntu 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 Ubuntu kernel does everything most users need it to do. Most users only need to recompile the kernel to do the following:
Accommodate an esoteric piece of new hardware
Conduct a system update when Ubuntu has not yet provided precompiled kernels
Experiment with the system capabilities
Ubuntu supplies precompiled versions of the kernel for 32- and 64-bit processors. For each architecture, they compile a generic kernel that works well for most uses, a server kernel that is optimized for server use, a preempt kernel designed for use in low latency servers, and an rt kernel for times when instant response is more important than balanced use (such as in professional audio/visual recording and editing). There is also a special kernel, called virtual, available for use in virtual machines. These are all available from the Ubuntu software repositories.
Also available are a series of packages called linux-backports-modules-, each with a specific set of kernel modules backported from newer mainline kernels into current version Ubuntu kernels. If you need an updated driver for a piece of hardware, look at the backported modules first.
Kernel Versions
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 stable version of the kernel at the time of writing, for example, the kernel version number from the Linux developers is 4.1.3. As this is being written, Ubuntu plans to ship 15.10 with either a 4.1 kernel with Ubuntu-specific patches applied. It will receive consistent updates throughout the release’s life cycle.
The kernel version can be broken down into four sections:
Major version—This is the major version number, now at 4.
Minor version—This is the minor version number, now at 1 (again, version in most recent Ubuntu LTS release).
Sublevel number—This number indicates the current iteration of the kernel; here it is number 3.
Extraversion level—This is the number representing a collection of patches and additions made to the kernel by the Ubuntu engineers to make the kernel work for them (and you). Each collection is numbered, and the number is indicated here in the kernel name. There is not one in our preceding example. In the example below, it is 0.
Type uname -r at the command prompt to display your current kernel version, shown here with example output:
matthew@seymour:~$ uname -r4.1.3.0-generic
Obtaining the Kernel Sources
The Linux kernel has always been freely available to anyone who wants it. If you just want to recompile the existing kernel, install the linux-source package from the Ubuntu repositories. To get the very latest vanilla version, which is the commonly used term for the kernel version direct from the main kernel developers and which has not yet been patched or changed by any distribution-specific kernel team, open an FTP connection to ftp.kernel.org using your favorite FTP client and log in as anonymous. The latest stable kernel when this section was first written was 4.1.3, so we use it in the following examples.
Because you are interested in the 4.1 kernel, change directories to /pub/linux/kernel/v4.1.
Note
The ftp.kernel.org site 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. The website 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 only in the full kernel, it is necessary to get the full package of source code (for example, linux-4.1.3.bz2).
The .bz2 extension is applied by the bzip2 utility, which has better compression than gzip.
After it is downloaded, move the package to a directory other than /usr/src and unpack it. The bzip2 unpack command is tar -xjvf linux-4.1.3.tar.bz2. After it is unpacked, the package creates a new directory, linux-4.1.3. Copy it to /usr/src or move it there. Then, create a symbolic link of linux-4.1 to linux-4.1.3. (Otherwise, some scripts will not work.) Here is how to create the symbolic link:
matthew@seymour:~$ sudo rm /usr/src/linux-4.1
matthew@seymour:~$ sudo ln -s /usr/src/linux-4.1.3 /usr/src/linux-4.1
By creating a symbolic link to /usr/src/linux-4.1, 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.
Caution
The correct symbolic link is critical to the operation of make. Always have the symbolic link point to the version of the kernel sources you are working with.
Patching the Kernel
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. Whether you are patching existing sources or downloading the full source, the end results are identical.
Patching the kernel is not a mindless task. It requires the user to retrieve all patches from the current version to the version the user wants to upgrade to. For example, if you are currently running 4.1.1 (and have those sources) and want to upgrade to 4.1.3, you must retrieve the 4.1.2 and 4.1.3 patch sets, and so on. After you download these patches, you must apply them in succession to upgrade to 4.1.3. This is more tedious than downloading the entire source, but it’s 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 4.1.1 kernel code tree that needs to be patched to the 4.1.3 version. The 4.1.2 and 4.1.3 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/linux-4.1 directory:
matthew@seymour:~$ sudo scripts/patch-kernel /usr/src/linux-4.1.1 /usr/src/
linux-4.1.1/patch
Each successive patch file is applied, eventually creating a 4.1.3 code tree. If any errors occur during this operation, files named xxx# or xxx.rej are created, where xxx is the version of the 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 need to understand C programming and kernel programming to know what is broken and how to fix it. Because this was a stock 4.1.1 code tree, the patches were all successfully applied without errors. If you are attempting to apply a nonstandard third-party patch, the patch might fail.
When you have successfully patched the kernel, you are ready to begin compiling this code tree as if you started with a fresh, stock 4.1.3 kernel tree.
Compiling the Kernel
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 must 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 boot loader.
The process of compiling the kernel is almost completely automated by the make utility like 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 are the steps to compile and configure the kernel:
1. Do not delete your current kernel, so that you will have a backup that you can use to boot if there is a problem with the one you compile.
2. Apply all patches, if any, so that you have the features you desire. See the previous section for details.
3. Back up the .config file, if it exists, so that you can recover from the inevitable mistake. Use the following cp command:
matthew@seymour:~$ sudo cp .config .config.bak
Note
If you are recompiling the Ubuntu default kernel, the /usr/src/linux-4.1/configs directory contains several versions of configuration files for different purposes.
Ubuntu provides a full set of .config files in the subdirectory configs, all named for the type of system they were compiled for. If you want to use one of these default configurations as the basis for a custom kernel, just copy the appropriate file to /usr/src/linux-3.4 and rename it .config.
4. Run the make mrproper directive to prepare the kernel source tree, cleaning out any old files or binaries.
5. Restore the .config file that the command make mrproper deleted and edit the makefile to change the EXTRAVERSION number.
Note
If you want to keep any current version of the kernel that was compiled with the same code tree, manually edit the makefile with your favorite text editor and add some unique string to the EXTRAVERSION variable.
You can use any description you prefer.
6. Modify the kernel configuration file using make config, make menuconfig, or make xconfig; we recommend the last one.
7. Run make dep to 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 -jx after the make command, where as a rule of thumb, x is 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 -j8 successfully on an SMP machine); it will only load up your CPU. For example:
matthew@seymour:~$ sudo make –j3 bzImage
All the make processes except make dep work well with this method of parallel compiling.
8. Run make clean to prepare the sources for the actual compilation of the kernel.
9. Run make bzImage to create a binary image of the kernel.
Several choices of directives exist; the most common ones are the following:
zImage—This directive compiles the kernel, creating an uncompressed file called zImage.
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 Ubuntu kernel compiled with bzImage is still too large to fit on a floppy, so a smaller version with some modules and features removed is used for the boot floppies. Ubuntu recommends that you boot from the rescue CD-ROM.
bzDisk—This directive does the same thing as bzImage, 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.
10. Run make modules to compile any modules your new kernel needs.
11. Run make modules_install to install the modules in /lib/modules and create dependency files.
12. Run make install to automatically copy the kernel to /boot, create any other files it needs, and modify the boot loader to boot the new kernel by default.
13. Using your favorite text editor, verify the changes made to /etc/lilo.conf or /boot/grub/grub.conf; fix if necessary and rerun /sbin/lilo if needed.
14. Reboot and test the new kernel.
15. 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 about 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 options, 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.
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 it looks a little nicer. Now, at least you can move back and forth in the selection process if you change your mind or make 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 the following explanation of each) 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.
After loading this utility, you use it by clicking each of the buttons that list the configu-ration options. Each button you click opens another window that has the detail con-figuration 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 through the entire configuration from scratch. Instead, you can use the directive make oldconfig; it uses the same text interface that make config uses, and it is noninteractive. It just prompts for changes for any new code.
Using xconfig to Configure the Kernel
For simplicity’s sake, during this brisk walkthrough, this discussion assumes that you are using make xconfig and that prior to this point you have completed the first five steps in the 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 our configuration will not match your own system and setup.
Table 22.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/linux-4.1 and run make xconfig from there. Explore all the options. So long as you do not save the file, absolutely nothing is changed on your system.
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.
Creating an Initial RAM Disk Image
If you require special device drivers to be loaded 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. To create an initrd.img file, use the shell script /sbin/mkinitrd.
The format for the command is the following, where file_name is the name of the image file you want to create:
/sbin/mkinitrd file_name kernel_version
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 the following:
matthew@seymour:~$ sudo mkinitrd initrd-4.1.3.img 3.4.6-1
When Something Goes Wrong
Several things might go wrong during a kernel compile and install, and several clues point to the true problem. You see error messages printed to the screen, and some error messages are printed to the file /var/log/messages, which you can examine with a text editor. If you have followed the directions for patching the kernel, you need to examine a special error log, as well. Do not worry about most 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.
Errors During Compile
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 crashes and does 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.
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/linux-4.1/ directory of the kernel source and find the maintainer of the code. The recommended course of action is to contact the maintainer to see if the maintainer 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 base directory of the kernel source under the section IF SOMETHING GOES WRONG.
Runtime Errors, Boot Loader Problems, and Kernel Oops
Runtime errors occur as the kernel is loading. Error messages are displayed on the screen or written to the /var/log/messages file. Boot loader 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 GRUB2 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. Adjust the keywords you use as you focus your search.
If you have GRUB problems, the GRUB manual is online at www.gnu.org/software/grub/manual/, and further information is available at https://help.ubuntu.com/community/Grub2.
Tip
For best results, go to 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.
References
www.kernel.org/—Linux Kernel Archives. The source of all development discussion for the Linux kernel.
www.gnu.org/—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.
https://wiki.ubuntu.com/Kernel—The starting point for anything you want to know about both Ubuntu and its use of the Linux kernel.
https://wiki.ubuntu.com/Kernel/FAQ—The Ubuntu Kernel Team answers the most commonly asked questions about Ubuntu’s use of Linux kernels.
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.
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 OS used to develop Linux.