Kernel Patching

Go back to Tutorial

Incremental upgrades of the Linux kernel are distributed as patches. For example, if you have version 1.1.45, and you notice that there’s a `patch46.gz’ out there for it, it means you can upgrade to version 1.1.46 through application of the patch. You might want to make a backup of the source tree first (`make clean’ and then `cd /usr/src; tar zcvf old-tree.tar.gz linux’ will make a compressed tar archive for you.). A “patch” is a file that describes the differences between two versions of a file. The program diff compares the original file and the new file line-by-line and prints the differences to standard out in a specific format. The program patch can read the output of diff and apply those changes to another copy of the original file.

So, continuing with the example above, let’s suppose that you have `patch46.gz’ in /usr/src. cd to /usr/src and do a `zcat patch46.gz | patch -p0′ (or `patch -p0 < patch46′ if the patch isn’t compressed). You’ll see things whizz by (or flutter by, if your system is that slow) telling you that it is trying to apply hunks, and whether it succeeds or not. Usually, this action goes by too quickly for you to read, and you’re not too sure whether it worked or not, so you might want to use the -s flag to patch, which tells patch to only report error messages (you don’t get as much of the “hey, my computer is actually doing something for a change!” feeling, but you may prefer this..). To look for parts which might not have gone smoothly, cd to /usr/src/linux and look for files with a .rej extension. Some versions of patch (older versions which may have been compiled with on an inferior filesystem) leave the rejects with a # extension. You can use `find’ to look for you;

find . -name ‘*.rej’ -print

prints all files who live in the current directory or any subdirectories with a .rej extension to the standard output.

If everything went right, do a `make clean’, `config’, and `dep’ as described in sections 3 and 4.

There are quite a few options to the patch command. As mentioned above, patch -s will suppress all messages except the errors. If you keep your kernel source in some other place than /usr/src/linux, patch -p1 (in that directory) will patch things cleanly. Other patch options are well-documented in the manual page.

If something goes wrong

This section refers mostly to quite old kernels. The most frequent problem that used to arise was when a patch modified a file called `config.in’ and it didn’t look quite right, because you changed the options to suit your machine. This has been taken care of, but one still might encounter it with an older release. To fix it, look at the config.in.rej file, and see what remains of the original patch. The changes will typically be marked with `+’ and `-‘ at the beginning of the line. Look at the lines surrounding it, and remember if they were set to `y’ or `n’. Now, edit config.in, and change `y’ to `n’ and `n’ to `y’ when appropriate. Do a

patch -p0 < config.in.rej

and if it reports that it succeeded (no fails), then you can continue on with a configuration and compilation. The config.in.rej file will remain, but you can get delete it.

If you encounter further problems, you might have installed a patch out of order. If patch says `previously applied patch detected: Assume -R?’, you are probably trying to apply a patch which is below your current version number; if you answer `y’, it will attempt to degrade your source, and will most likely fail; thus, you will need to get a whole new source tree (which might not have been such a bad idea in the first place).

To back out (unapply) a patch, use `patch -R’ on the original patch.

The best thing to do when patches really turn out wrong is to start over again with a clean, out-of-the-box source tree (for example, from one of the linux-x.y.z.tar.gz files), and start again.

Getting rid of the .orig files

After just a few patches, the .orig files will start to pile up. For example, one 1.1.51 tree I had was once last cleaned out at 1.1.48. Removing the .orig files saved over a half a meg.

find . -name ‘*.orig’ -exec rm -f {} ‘;’

will take care of it for you. Versions of patch which use # for rejects use a tilde instead of .orig.

There are better ways to get rid of the .orig files, which depend on GNU xargs:

find . -name ‘*.orig’ | xargs rm

or the “quite secure but a little more verbose” method:

find . -name ‘*.orig’ -print0 | xargs –null rm –

Go back to Tutorial