7. What now?

7.1. Hold that kernel!

If you used --append-to-version you shouldn't need to worry about apt-get trying to "upgrade" your kernel. If you're paranoid (it is out to get you) you can make sure by doing this (as root):

bash:~# echo "kernel-image-2.4.18.030320 hold" | dpkg --set-selections

Of course substitute the real name of your kernel. To refer to a package that dpkg knows about (an installed package or one in an archive's list) use the package name rather than the full file name. Also, the "|" character is made by typing Shift-\. Check that the package really is on hold; if it is you should see:

bash:~# dpkg --get-selections | grep kernel-image
kernel-image-2.4.18.030320     hold

7.2. Removing the symlink

Next, you should get rid of the symlink you created in the /usr/src directory. There are several reasons for this:

1. The next time you download a kernel it might not be from a Debian archive. When you expand the source tarball it could overwrite your old source tree right through the old symlink. Bummer.

2. The next time you download the kernel source from the Debian archive, you might expand the source into its own tree without problems. But since you already have a symlink called "linux" in the src directory, you might go ahead and compile (forgetting of course that it's linked to your old source tree.)

3. When you download patches or other source code into a specific source tree, you don't want anything else messing with it. By removing the symlink you might prevent #1 from happening.

To remove the link do this:

bash:~# cd /usr/src
bash:/usr/src# rm linux

7.3. Backing up your kernel

While not required, it's a good idea is to back up your custom kernel .deb. Copy it to a secure undisclosed location.

Once your kernel has been packaged with its modules, you can install it on any machine that has the hardware you specified in your kernel configuration. You could even reinstall it on your current machine after reinstalling your system.

7.4. Making a new boot diskette

Create another boot diskette, this one for the kernel you just installed. Grab another floppy — it's not a good idea to overwrite your old boot disk; you haven't been using your new kernel long enough to be sure it works.

bash:/usr/src# cd /boot
bash:/boot# mkboot /boot/vmlinuz-2.4.18.030320

7.5. Removing old kernels

Now that you see how easy it is to build and install kernels, it won't be long before your /boot directory is crowded with kernels and configs and System.maps. Use dpkg to purge the ones you don't need:

bash:/boot# dpkg -P kernel-image-2.4.18.030309

If you get a message that "/lib/modules/2.4.18.030309 is not empty so wasn't removed", you probably have third-party modules installed there. They too can be removed by purging their packages. (See Third-party modules to find out how to make them with make-kpkg.)

bash:/boot# dpkg -P pcmcia-modules-2.4.18.030309

If the modules subdirectory still isn't empty, you probably have kernel modules that you didn't build with make-kpkg. You can remove the modules subdirectory once you're satisfied there's nothing there you need.

7.6. Building your next kernel

If you want to rebuild your kernel because you just bought a new sound card, or you want to enable a new feature you forgot to include the first time, all you need to do is reconfigure, do "fakeroot make-kpkg clean", and rebuild with a different value for --append-to-version. Your session should look something like this:

bash:~$ cd /usr/src
bash:/usr/src$ ln -s kernel-source-2.4.18 linux
bash:/usr/src$ cd linux
bash:/usr/src/linux$ make xconfig
		(reconfigure your kernel)
bash:/usr/src/linux$ fakeroot make-kpkg clean
		(lots of cleaning here)
bash:/usr/src/linux$ fakeroot make-kpkg --append-to-version=.030401 kernel_image
		(screens and screens of stuff)