Rolling your own
There's nothing like rolling your own kernel, compiled your way, to eliminate diagnostic variables. Please realise that the main reason for the prevalence of highly modular kernels and initial RAMdisks is so that distributions can install and run with a single installation set onto the widest possible range of hardware. As a result, such setups aren't guaranteed to work on your hardware, and are pretty much guaranteed to be sub-optimal even where they do.
What the distributions are trying to get away from is the traditional Slackware installation routine, where you select a boot floppy image and a root floppy image from among dozens of such combinations, picking a pair that's appropriate for your hardware. That still works. In fact, it works extremely well. But it doesn't sell to the masses. Thus the profusion of modules and initrds.
After any successful installation, I still, to this day, like compiling a kernel that has all its required hardware drivers, filesystem drivers, and optional features compiled directly into a monolithic kernel that doesn't even support module-loading at all. But short of that, you can alternatively compile a kernel that support modules, and has at its disposal a big tree of modules, but has support for key hardware and filesystems compiled directly in.
The latter can be a lifesaver, e.g., if you suddenly do something that screws up your kernel's ability to load and unload modules, or clobber /lib/modules/[foo], or some bonehead manoeuvre like that. Having crucial drivers compiled directly into the kernel means they're available no matter what, as long as the kernel gets loaded and is running at all.
Rick Moen
rick@linuxmafia.com
If you lived here, you'd be $HOME already.