How to install a custom scratchbuilt kernel. (long version)

Kernel Upgrade: (long version)

- If you install the full sources, put the kernel tarball in a

directory where you have permissions (eg. your home directory) and

unpack it:

gzip -cd linux-2.4.XX.tar.gz | tar xvf -

Replace "XX" with the version number of the latest kernel.

Do NOT use the /usr/src/linux area! This area has a (usually

incomplete) set of kernel headers that are used by the library header

files. They should match the library, and not get messed up by

whatever the kernel-du-jour happens to be.

- You can also upgrade between 2.4.xx releases by patching. Patches are

distributed in the traditional gzip and the new bzip2 format. To

install by patching, get all the newer patch files, enter the

directory in which you unpacked the kernel source and execute:

gzip -cd patchXX.gz | patch -p0

or

bzip2 -dc patchXX.bz2 | patch -p0

(repeat xx for all versions bigger than the version of your current

source tree, _in_order_) and you should be ok. You may want to remove

the backup files (xxx~ or xxx.orig), and make sure that there are no

failed patches (xxx# or xxx.rej). If there are, either you or me has

made a mistake.

Alternatively, the script patch-kernel can be used to automate this

process. It determines the current kernel version and applies any

patches found.

linux/scripts/patch-kernel linux

The first argument in the command above is the location of the

kernel source. Patches are applied from the current directory, but

an alternative directory can be specified as the second argument.

- Make sure you have no stale .o files and dependencies lying around:

cd linux

make mrproper

You should now have the sources correctly installed.

SOFTWARE REQUIREMENTS

Compiling and running the 2.4.xx kernels requires up-to-date

versions of various software packages. Consult

./Documentation/Changes for the minimum version numbers required

and how to get updates for these packages. Beware that using

excessively old versions of these packages can cause indirect

errors that are very difficult to track down, so don't assume that

you can just update packages when obvious problems arise during

build or operation.

CONFIGURING the kernel:

- Do a "make config" to configure the basic kernel. "make config" needs

bash to work: it will search for bash in $BASH, /bin/bash and /bin/sh

(in that order), so one of those must be correct for it to work.

Do not skip this step even if you are only upgrading one minor

version. New configuration options are added in each release, and

odd problems will turn up if the configuration files are not set up

as expected. If you want to carry your existing configuration to a

new version with minimal work, use "make oldconfig", which will

only ask you for the answers to new questions.

- Alternate configuration commands are:

"make menuconfig" Text based color menus, radiolists & dialogs.

"make xconfig" X windows based configuration tool.

"make oldconfig" Default all questions based on the contents of

your existing ./.config file.

NOTES on "make config":

- having unnecessary drivers will make the kernel bigger, and can

under some circumstances lead to problems: probing for a

nonexistent controller card may confuse your other controllers

- compiling the kernel with "Processor type" set higher than 386

will result in a kernel that does NOT work on a 386. The

kernel will detect this on bootup, and give up.

- A kernel with math-emulation compiled in will still use the

coprocessor if one is present: the math emulation will just

never get used in that case. The kernel will be slightly larger,

but will work on different machines regardless of whether they

have a math coprocessor or not.

- the "kernel hacking" configuration details usually result in a

bigger or slower kernel (or both), and can even make the kernel

less stable by configuring some routines to actively try to

break bad code to find kernel problem