Running Linux, 5th Edition - Matthias Kalle Dalheimer [342]
Unpacking the sources
First, unpack the source tar file from /usr/src using commands such as:
rutabaga# cd /usr/src
rutabaga# mv linux linux.old
rutabaga#tar xzf v2.6.0.tar.gz
This saves your old kernel source tree as /usr/src/linux.old and creates /usr/src/linux containing the new sources. Note that the tar file containing the sources includes the linux subdirectory.
You should keep your current kernel sources in the directory /usr/src/linux because there are two symbolic links--/usr/include/linux and /usr/include/asm--that point into the current kernel source tree to provide certain header files when compiling programs. (If you are planning on doing any software development, you should always have your kernel sources available so that programs using these include files can be compiled.) If you want to keep several kernel source trees around, be sure that /usr/src/linux points to the most recent one.
Applying patches
If you are applying any patch files, use the patch program. Let's say that you have the files patch1.gz through patch4.gz, which are gzipped. These patches should be applied from the kernel sources main directory. That doesn't mean the patch files themselves should be located there, but rather that patch should be executed from, for example, /usr/src/linux. For each patch file, use the command:
gunzip -c patchfile | patch -p1
from /usr/src. The -p1 option tells patch it shouldn't strip any part of the filenames contained within the patch file except for the first one.
You must apply each patch in numerical order by patch level. This is very important. Note that using a wildcard such as patch* will not work because the * wildcard uses ASCII order, not numeric order. (Otherwise, if you are applying a larger number of patches, patch1 might be followed by patch10 and patch11, as opposed to patch2 and patch3.) It is best to run the previous command for each patch file in succession, by hand. This way you can ensure you're doing things in the right order.
You shouldn't encounter problems when patching your source tree in this way unless you try to apply patches out of order or apply a patch more than once. Check the patch manual page if you do encounter trouble. If all else fails, remove the new kernel source tree and start over from the original tar file.
To double-check that the patches were applied successfully, use the commands:
find /usr/src/linux -follow -name "*.rej" -print
find /usr/src/linux -follow -name "*#" -print
This lists any files that are "rejected" portions of the patch process. If any such files exist, they contain sections of the patch file that could not be applied for some reason. Look into these, and if there's any doubt, start over from scratch. You cannot expect your kernel to compile or work correctly unless the patch process completes successfully and without rejections.
A handy script for patching the kernel is available and can be found in scripts/patch-kernel. But as always, you should know what you are doing before using automated tools — even more so when it comes to the very core of the operating system, the kernel.
Building the Kernel
There are six steps to building the kernel, and they should be quite painless. All these steps are described in more detail in the following pages.
Make sure that all the required tools and utilities are installed and at the appropriate versions. See the file Documentation/Changes in the kernel source for the list of requirements.
Run make config, which asks you various questions about which drivers you wish to include. You could also use the more comfortable variants make menuconfig, or make xconfig (when you are running KDE), or make gconfig (when you are running GNOME).
If you have previously built a kernel and then applied patches to a new version, you can run make oldconfig to use your old configuration but be prompted