Do initrds have any use at all apart from:

• Distribution kernels where the packager has no idea what hardware the kernel will need to run on
• Kernels intended to work on a large variety of machines without modification (really just another variant of the above use)
• Unusual setups like running your root filesystem inside a filesystem that needs commands to be run to set it up

I personally fucking hate initrds. The process to generate them seems so fiddly, it is fraught with potential pitfalls, and that’s exactly the kind of lottery I do not need when we’re talking about rebooting machines I rely on.

Unfortunately I was stupid enough to set up becks with its root filesystem on LVM. It now needs an initrd to boot, because you can’t activate the LVM logical volumes without running some userspace commands. It needs a userspace to run them in, in order to get its root filesystem up and running.

The thing is, I don’t even understand why anyone would really need to put their root filesystem in something like LVM. The root is just too important. All my other machines have a RAID-1 root that is rather small (1 or 2 GiB), then the majority of the rest of the subdirectories off root are in LVM LVs run off RAID-5 or RAID-10. /boot is a very small (maybe 128MiB) RAID-1 ext2 filesystem.

That allows me plenty of flexibility without any need for an initrd, so compiling a custom kernel with MD and LVM statically compiled-in is one of the first things I do on a newly-built Linux box.

One day I will rebuild becks and when I do it’ll probably end up as Debian or Ubuntu — and no initrd. A disturbing trend I’ve noticed however is that various people are talking about making it so that you need an initrd more and more of the time. For example, the maintainer of MD on Linux says that he doesn’t endorse the automatic assembly of the RAID arrays and suggests either building it on the kernel commandline or using an initrd. That’s fine as long as we’ll always be able to assemble them with the kernel commandline.