linux/ImprovingInitrds written at 02:33:05; Add Comment
Improving initial ramdisks
To summarize my earlier entry, the problem with initrds is that they are both fragile and opaque. To improve them, one needs to tackle both issues.
The easy way to tackle the fragility is to make initrds both more comprehensive and more dynamic. Since one way initrds break is by not including necessary kernel modules, simply include nearly everything by default (you can exclude modules that are clearly not needed for booting, like sound drivers); the extra disk space and boot-time memory space needed is likely to be insignificant on any modern system. To make things more dynamic, put hardware discovery and the related module loading into the initrd itself, at least as a fallback measure.
The trade off for the initrd dynamically exploring your hardware is that there are good reasons to defer as much hardware initialization as possible until you are running on the real system. Thus the initrd should know the normal path to the default root filesystem and only put its dynamic discovery into action if this failed, since your other alternative at that point is to just give up. I suspect that the normal path is best passed in as a kernel command line variable, so that you can change it without having to modify the initrd.
(A further helpful step would be to put a basic rescue environment into the initrd, one comprehensive enough that you could see what hardware and filesystems that the kernel sees, and tell it to set something as the real root and continue the boot.)
To solve the opacity problem is harder. Opacity is created because initrds are ultimately very free form, so to make them more transparent (in a way that tools can deal with) we need to make them more structured. This ultimately means getting people to agree on a fairly rigid structure for initrds, or at least common structural elements such as a fixed configuration file that gives basic information about the initrd.
Initrds will probably never be truly transparent, since they're ultimately blobs instead of spread out in the filesystem, but with structure it would be possible to write tools that inspect, explain, and check initrds, which would help a lot. Such a structure will always need escape clauses, but they should be rare and their presence should be easy to spot, so at least the normal tools can immediately flag an initrd as 'has special magic'.
(Department of attribution: this entry was inspired by thinking about this.)
* * *
Atom feeds are available; see the bottom of most pages.