Section 4 - Patching the kernel

# 5 Section 4 - Patching the kernel

Contents of this section

## 5.1 4.0. Applying a patch

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 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.

## 5.2 4.1. If something goes wrong

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.

## 5.3 4.2. Getting rid of the .orig files

After just a few patches, the `.orig` files will start to pile up. For example, the 1.1.51 tree I have now 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`.

## 5.4 4.3. Other patches

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 am still using 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` (maybe I should put new diffs for it on some ftp site..).

Next Chapter, Previous Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter