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.
« The aesthetics of syntactic sugar
Why I hate Solaris 10's service facility right now »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Sep 27 01:21:56 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.