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 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.).
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.
(Note: 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.
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 --
There are 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, fix the source or the patch, install a new source tree, or a combination of the above. This can become very frustrating, so if you do not want to modify the source (with the possibility of a very bad outcome), back out the nonstandard patches before applying Linus', or just install a new tree. Then, you can see if the nonstandard patches still work. If they don't, you are either stuck with an old kernel, playing with the patch or source to get it to work, or waiting (possibly begging) for a new version of the patch to come out.
How common are the patches not in the standard distribution? You will probably hear of them. I used to use the noblink patch for my virtual consoles because I hate blinking cursors (This patch is (or at least was) frequently updated for new kernel releases.). With most newer device drivers being developed as loadable modules, though, the frequecy of ``nonstandard'' patches is decreasing significantly.