The problem with initial ramdisks
September 27, 2008
Here's one of my Linux peculiarities: I don't like initrds. Not because they're inefficient or anything like that, but because they are another moving part in an already complicated boot process. Worse, they are generally a black box moving part; it is pretty difficult to peer inside an initrd to see what it is doing and to make sure that it is correct.
In fact, initrds are so hard to inspect and manipulate that almost no one does, not even distributions. Instead initrds are 'manipulated' by recreating them from scratch, and aren't generally inspected at all; if you have doubts about an initrd, you remake it. And building them is magic, so you have to trust that the magic was done right (and the magic is supplied by your distribution, as it's beyond most people's abilities to hand-build an initrd environment).
(Partly this is because initrds are so general and no reliable standards have emerged for how to organize them. This means that just looking at a file and directory listing is no real help; in order to know what's going on, you have to crack a particular initrd apart and read the scripts involved.)
But let's set aside my issues with the common implementations, because the big problem is that moving parts are inherently fragile, especially when they must exactly match up with other moving parts. An initrd is another point of failure; if its contents aren't exactly right, my system won't boot. (And there are a fair number of ways for the contents to wind up not exactly right.)
This might be worth it if I got something for this extra fragility, but I don't, at least so far. So I am left feeling a little bit grumpy about the whole issue, especially when distributions require initrds.
Written on 27 September 2008.
* * *
Atom feeds are available; see the bottom of most pages.