Initramfs is a useful tool; it allows a filesystem (in cpio format) to be
tacked on to the end of the kernel executable image. When the kernel
boots, it unpacks the filesystem into RAM and mounts it as the initial root
filesystem. Therein will be found enough bootstrap code to get the system
properly initialized and running from the real root filesystem. It is
possible to boot a system without an initramfs, but essentially all
distributors make use of this facility.
Dave Jones, the Fedora kernel maintainer, made the claim that the initramfs
code is one of the most boring parts of any distribution. Even so, all
distributors still roll their own initramfs code. It is a pain, and it
doesn't make any sense. So Dave looked into what's going on in this code
to see if the situation could be made any better.
The Red Hat initramfs image, used in Fedora, is the product of many years'
worth of heritage and workarounds. Whenever the developers have run into
an early bootstrap problem, they have thrown another hack into the
initramfs code to make things work again. This code is ugly, but nobody
wants to switch to anybody else's version. They fear that a different
initramfs will lack all those hard-earned workarounds, and, besides,
everybody feels that their particular solution is the best.
So what does the initramfs code do? Its job is to load any necessary
storage drivers, then wait for the storage devices to settle. The swap
system needs to be enabled. If the swap partition contains a hibernation
signature, a resume from disk operation is begun. Otherwise the initramfs
code must find the root filesystem (an operation which may require setting
up the device mapper or getting networking going), mount it, then switch
over to the real operating system. Red Hat's version has to support a wide
variety of root filesystems, and contains a lot of crufty code.
The situation is pretty much the same with the other distributors. Where
things differ, it often has to do with differing kernel configurations,
and, in particular, differences of opinion over whether specific code
should be built into the kernel or built as a module.
Differences between initramfs setups can create some annoying problems.
Sometimes these differences are enough to cause some kernel configurations
to fail on one distribution. It would make life easier for everybody if a
more uniform set of tools were used for early system initialization. This
code could be part of the kernel tree, and it could change, when needed, in
response to kernel changes. In the end, things would just work.
There's a few details that would have to be dealt with. Some distributions
use the in-kernel hibernation (suspend-to-disk) code, while others are
using TuxOnIce. It seems like maybe
it's time for everybody to standardize on one hibernation solution. While
most distributions have long since switched over to the parallel ATA
drivers, some are still using the older IDE subsystem. Not everybody
supports root filesystems on iSCSI devices. And so on. But these are
should be amenable to a solution.
Dave is going to start by adding a "make mkinitrd" option to the kernel
build system; it will create a version of the Fedora mkinitrd for now.
Others will be encouraged to join in and help make it work for everybody.
Beyond that, Dave suggested that the developers could start to build a set
of reference boot scripts in the kernel. Once again, this is an area where
distributors tend to roll their own code; they could benefit from bits of
code showing the best way to initialize parts of the system. Al Viro
pointed out that there will be problems coming from the fact that different
distributors use different shells in their early boot code. That led to an
extended discussion of the evils of nash and the celebrations which will
ensue upon its eagerly-awaited demise.
There was some brief discussion of klibc - a small version of the C library
intended for use in initramfs code. That project has been stalled for some
time due to lack of interest; it could probably be restarted without too
much trouble. The problem is that, despite all their wishes, distributions
often end up having to use glibc in their initramfs filesystems. The
biggest driver here appears to be internationalization, which is not
properly handled by the various stripped-down libc implementations out
Getting back to the concept of a uniform set of initramfs tools, Linus
suggested that the process could start with some baby steps. The kernel
could include some bits of code which are automatically added into whatever
initramfs image the distributor provides. There are challenges to making
that work too, of course. The best way, perhaps, is just to dump
everybody's initramfs and start over with a new, clean version. That
project may get underway before too long.
to post comments)