5 Patching the kernel

Incremental upgrades of the 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 by applying the patch. You might want to make a backup of the source tree first (``make clean'' and then ``cd /usr/src; tar cvf - linux | gzip -c > old-tree.tar.gz'' will make a compressed tar archive for you.).

So, continuing with the example in the above, let's suppose that you've got ``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 computer is kind of slow) telling you that it's trying to apply hunks, and if it succeeds or not. Usually, it goes by too fast for you to read, so you're not too sure whether it worked or not. So, to look for things that 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'' will do the trick.

If everything has gone right, do a ``make clean,'' ``config,'' and ``dep'' as described in sections 2 and 3.

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

The most frequent problem that arises used to be 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's left. 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 says it succeeded (no fails), then you're okay. The config.in.rej file will remain, but you can get rid of it.

If you've got further problems, you might have installed a patch out of order. If patch says ``previously applied patch detected: Assume -R?,'' you are probably applying some patch that is below your current version number (This is not one of those recommended things to do.).

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

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

After just a few patches, the .orig files will start to pile up. For example, one 1.1.51 tree I had was last cleaned out at 1.1.48 (I think). Removing the .orig files saved over a half a meg. ``find . -name '*.orig' -exec rm -f {} ';' '' will take care of it for you. Some versions of patch use a tilde instead of .orig.

There are other (better?) ways to get rid of the .orig files. Most use ``xargs'' instead of ``-exec:'' ``find . -name '*.orig' | xargs rm'' or ``find . -name '*.orig' -print0 | xargs --null rm --'' (the latter is more secure.).

There's always other patches (I'll call them ``nonstandard'') than the ones Linus distributes. If you apply these, Linus' patches may not work correctly and you'll have to either back them out, or fix the source or the patch accordingly. That's generally an ugly thing to do for novices, so if you're not into screwing around with the source, back out the nonstandard patches before applying Linus'. Then, you can see if the nonstandard patches still work. If they don't, you're either stuck with running at the old patchlevel, playing with the patch to get it to work, or waiting for someone to come out with a version of the nonstandard patch for your new patchlevel.

How common are the ones not in the standard distribution? You will probably hear of them. I use Bill Paul's noblink patch to make the cursor on my virtual consoles because I hate blinking cursors. As far as I know, this particular patch was last updated for kernel version 1.0, but I still used it at 1.1.51 -- I have modified it quite a few times, because it often messes up Linus' patches to drivers/char/console.c.