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. Once 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/linux-2.6 directory:
# scripts/patch-kernel /usr/src/linux-2.6.6 /usr/src/linux-2.6.6/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 will 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 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 might 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.
Was this article helpful?