Dracut looks to replace the initramfs patchwork

Creating initramfs images, for use by the kernel at "early boot" time, is a rather messy business. It is made more so by the fact that each individual distribution has its own tools to build the image, as well as its own set of tools inside it. At the 2008 Kernel Summit, Dave Jones spent some time discussing the problem along with his idea to start over by creating a cross-distribution initramfs. That has led to the Dracut project, which was announced by Jeremy Katz in December, and a new mailing list, aptly named "initramfs", in which to discuss it.

An initramfs is a cpio archive of the initial filesystem that gets loaded into memory when the kernel is loaded. That filesystem needs to contain all of the drivers and tools needed to mount the real root filesystem. It isn't strictly necessary to have an initramfs, a minimal /dev along with the required drivers built into the kernel is another alternative. Distributions, though, all use an initramfs and, over time, each has come up with their own way to handle this process. Jones, Katz, and others would like to see something more standardized, that gets pushed upstream into the mainline kernel so that distributions can stop fussing with the problem.

There are a number of advantages to that approach. Building an initramfs from the kernel sources would eliminate problems that users who build their own kernels sometimes run into. If a distribution's initramfs scheme falls behind the pace of kernel development in some fashion, users can find themselves unable to build a kernel+initramfs combination that will work. There is also hope that dracut will help speed up the boot process by using udev, as Katz puts it:

Because initramfs is so integral to the early boot process—and so difficult to debug if problems arise—there is a concern about starting over. It is not surprising, then, that there is some resistance to throwing out years of hard-earned knowledge that is embodied in the various distributions' initramfs handling, leading Maximilian Attems to ask:

It is a question that is frequently asked, but one that Jones has a ready answer for:

So, the Red Hat folks, at least, are proceeding with dracut. Jones recently posted a status report on his blog that outlined what is working and what still needs to be done. Though it currently is "Fedora-centric, with a few hardcoded assumptions in there, so it'll likely fall over on other distros", fixing that is clearly high on the to-do list. The status report is an effort to get people up-to-speed so that other distributions can start trying it out. In addition, he plans to start trying it on various distributions himself.

In its current form, dracut is rather minimal. It has a script named dracut that will generate a gzipped cpio file for the initramfs image, as well as an init shell script that ends up in that image. Jones says that init "achieves quite a lot in its 119 lines": setting up device nodes, starting udev, waiting for the root device to show up and mounting it, mounting /proc and /sys, and more. If anything goes wrong during that process, init will drop to a shell that will allow diagnosis of the problem. So far, it only supports the simpler cases for the location of the root filesystem:

There is only one remaining barrier to getting rid of the unlamented nash, and that is a utility to do a switch_root (i.e. switch to a new root directory and start an init from there). The plan is to write a standalone utility that would be added to the util-linux package. The environment provided by the initramfs would include util-linux, bash, and use glibc, which doesn't sit well with some embedded folks. They generally prefer a statically linked busybox environment. Kay Sievers outlines the reasons for a standard environment:

There is plenty to do to make dracut into a real tool for creating initramfs images—at least ones that work on more than just Fedora—more root filesystem types need to be handled, hibernation signatures need to be recognized and handled, the udev rules need to be cleaned up, kdump images need to be supported, etc. But the overriding question is: will other distributions start working on dracut as well? If and when Jones (or others) get things at least limping along on Debian/Ubuntu and/or SUSE, will those distributions start getting on board? So far, there is not a lot of evidence of anyone other than Red Hat working on dracut.

But, the plan is to eventually submit dracut upstream to the mainline kernel, so that make initramfs works in a standard kernel tree. It would seem that many kernel hackers see the need for standardizing initramfs and eventually moving it into the kernel, as Ted Ts'o notes:

No one is very happy about losing their particular version of the tools to build an initramfs—if only because of familiarity—but a standardized solution is something whose time has come. Probably any of the existing tools could have been used as a starting point, but for political reasons, it makes sense to start anew. There is a fair amount of cruft that has built up in the existing tools as well, which folks are unlikely to miss, so there are also technical reasons to start over. It should come as no surprise that a project started by Red Hat might be somewhat Fedora-centric in its early form, but the clear intent is to make it distribution-agnostic. It would seem the right time for other distributions and constituencies (embedded for example) to get involved to help shape dracut into something useful for all.