KS2008: Bootstrap code

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 problems which 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 there.

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.