Keep your kernel optimized for quick booting and long-term stability
Linux will run on an enormous variety of computer hardware. There is support for all manner of hardware, from critical components (such as hard disk drives and RAM) to more exotic devices (such as USB scanners and video capture boards). The kernel that ships with most Linux distributions aims to be complete (and safe) at the expense of possibly being less efficient than it could be, by including support for as many devices as possible.
As your machine boots, take a look at the messages the kernel produces. You may find it probing for all sorts of hardware (particularly SCSI controllers and Ethernet cards) that you don't actually have installed. If your distribution hides the kernel boot messages, try the dmesg command (probably piped through less) to see what kernel messages were generated at boot.
To make your kernel boot quickly and at the same time eliminate the possibility that an unnecessary device driver might be causing problems with your installed hardware, you should trim down the drivers that the kernel attempts to load to fit your hardware.
There are two schools of thought on managing kernel drivers. Some people prefer to build a kernel with all of the functionality they need built into it, without using loadable kernel modules. Others prefer to build a more lightweight kernel and load the drivers they need when the system boots. Of course, both methods have their advantages and disadvantages.
For example, the monolithic kernel (without loadable modules) is guaranteed to boot, even if something happens to the drivers under /lib/modules. Some admins even prefer to build a kernel with no loadable module support at all, to discourage the possibility of Trojan horse device drivers being loaded by a random miscreant down the road. On the other hand, if a new piece of hardware is added to the system, then you will need to rebuild your kernel to accommodate it.
If you use loadable modules, then you have enormous flexibility in
how you load device drivers. You can alter the order that drivers
load and even pass parameters to various modules as you load the
driver, all without rebooting. The downside is that good copies of
the modules must exist under /lib/modules, or
else the system can't load its drivers. When you
build a new
you'll need to remember to run a
modules_install, and to keep your kernel module utilities
(like modprobe and lsmod)
up to date. Building a kernel with loadable modules can also help if
your monolithic kernel is too large to boot (by loading extra device
drivers after the kernel boots and the filesystems are mounted).
Regardless of the method that you choose for your system, you'll need to build a kernel with the minimal functionality that is required to boot. This includes drivers for the IDE, SCSI, or other bus (maybe floppy disk or even network card?) that your machine boots from. You will also need support for the filesystem that your root partition is installed on (likely ext2, ext3, or reiserfs). Make sure that you build a kernel with support for the amount of RAM that your machine has installed (see [Hack #21]). Select a processor that matches your hardware to be sure that all appropriate optimizations are turned on. Be sure to build an SMP kernel if you have more than one processor.
To build a customized kernel, unpack the kernel sources somewhere
that has enough room (say, in
/usr/local/src/linux). Run a
menuconfig (or, if you're running X,
make xconfig). Select your drivers carefully
(hitting Y for built-in drivers, and M for loadable modules.)
Remember that you're building a kernel for a server
and don't include extraneous drivers. Does your
server really need sound support, even if it is built into your
motherboard? What about USB? Unless you have a specific use for a
particular piece of hardware that is directly related to its job as a
server, don't bother installing a driver for it. You
should also consider disabling unused hardware in the BIOS, wherever
possible, to conserve system resources and reduce the possibility of
hardware resource conflicts.
After you're finished selecting which bits of the
kernel to build, it will save your configuration to a file called
at the top of the kernel
source tree. Save this file for later, because it will make upgrading
your kernel much easier down the road (by copying it to the top of
the new kernel tree, and running
Now build the new kernel (and modules, if applicable), install it,
and give it a try. Be sure to try out all of your devices after
installing a new kernel, and watch your boot messages carefully.
Track down any unexpected warnings or errors now, before they cause
trouble at some future date.
Finally, if you're doing kernel work remotely,
don't forget to build in support for your network
devices! There's nothing quite like the pain of
realizing that the network drivers aren't built just
after you issue a
now. Hopefully that console is accessible by someone on
call (who will discretely boot your old kernel for you, without
telling too many of your friends).
Building a kernel well-tailored to your hardware can be challenging, but is necessary to make your server run as efficiently as it can. Don't be discouraged if it takes a couple of tries to build the perfect Linux kernel, the effort is well worth it.
Running Linux, Fourth Edition (O'Reilly)