Книга: Fedora™ Unleashed, 2008 edition
Patching the Kernel
Patching the Kernel
It is possible to patch a kernel to the newest Linux kernel version, as opposed to down loading 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 down loading 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 her current version to the version to which she wants to upgrade. 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 is likely to 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 2.6.8
kernel tree.
Using the patch
Command
If you have a special, nonstandard patch to apply — such as a third-party patch for a commercial product, for example — you can use the patch
command rather than the special patch-kernel script that is normally used for kernel source updates. Here are some quick steps and an alternative method of creating patched code and leaving the original code alone:
1. Create a directory in your home directory and name it something meaningful, like mylinux
.
2. Copy the pristine Linux source code there with cp -ravd /usr/src/kernels/linux-2.6/* ~/mylinux
.
3. Copy the patch file to that same directory with cp patch_filename -/mylinux
.
4. Change to the ~/mylinux
directory with cd ~/mylinux
.
5. Apply the patch with patch -p1 < patch_filename > mypatch.log 2>&1
. (This last bit of code saves the message output to a file so that you can look at it later.)
6. If the patch applies successfully, you are finished and have not endangered any of the pristine source code. In case the newly patched code does not work, you do not have to reinstall the original, pristine source code.
7. Copy your new code to /usr/src/kernels
and make that special symbolic link described elsewhere in the chapter.
- 4.4.4 The Dispatcher
- About the author
- Chapter 7. The state machine
- Appendix E. Other resources and links
- Example NAT machine in theory
- The final stage of our NAT machine
- Kernel setup
- Compiling the user-land applications
- The conntrack entries
- Untracked connections and the raw table
- Basics of the iptables command
- Other debugging tools