Dracut status

I figured I’d drop a quick ‘howto’ to get up and running with dracut, the shiny new initramfs creation tool. Right now, it’s still very Fedora-centric, with a few hardcoded assumptions in there, so it’ll likely fall over on other distros, but most of those are silly things like pathnames, which I’m sure we’ll eventually come to some agreement over.

So to begin with, clone the git repo from git://fedorapeople.org/~katzj/dracut.git (This will move soon, as Jeremy asked me to take over the lead on dracut, but until there’s additional changes, go there).

After a brief cloning, you’ll be left with a dracut directory containing a bunch of interesting files..

‘dracut’ is the shell script that will actually generate an initramfs image. It sources the ‘dracut-functions’ script to do some of the trickier things like working out module dependancies. This script will eventually get called by the kernel during its build process as part of ‘make initramfs’.

dracut.spec is an RPM spec file, handy for testing on Fedora systems until we get the kernel bits hooked up.

‘init’ is the actual init script that ends up in the initramfs.
It achieves quite a lot in its 119 lines.

  • Sets up device nodes

  • starts up udev
  • figures out from the command line what kind of root device we’re expecting
  • waits for it to show up in /dev, and mounts it
  • mounts /proc and /sys
  • If anything goes wrong at all during mounting of the root filesystem, it drops you to a shell.
  • If plymouth is present, it starts it, so it can show splash screens, or prompt for an encrypted disk password etc.
  • Right now it’s also loading the default selinux policy, though there seems to be agreement that the right place for this to happen is in the real rootfs, in /sbin/init.

There’s a makefile that will install things in the right places if you’re on a Fedora system. (libexec, ugh). If you don’t do this, you can still run dracut directly from the checked out tree, by passing it the option -l

rules.d contains two udev rules. One which scans for LVM volumes when it gets a notification that a new block device has been added to the system, and another which handles encrypted block devices should one show up. Both of these rules are not shining examples of how this should be done, and could use improving.

‘switch_root’ is the sole surviving piece of ‘nash’. Its job is fairly simple. Switch to new root directory and start init from that new root. Right now, we’re calling the nash tool from the existing mkinitrd implementation. The code for the replacement of this currently lives at http://pjones.fedorapeople.org/mkstart/usr/lib/mkstart/switchroot.c It is hoped that this will get included as a util-linux utility soon, so that nash can finally be put to rest.

Finally there’s all the usual things you’d expect to see in a project, COPYING, HACKING, README and a healthy looking TODO.

The interesting parts (the shell scripts) are currently only just over 600 lines, making it a fairly easy to understand project. Removing some of the redhat’isms is definitely one of the things that needs to happen before it can be headed upstream. I hope to get around to trying it out on some other distros later this week.

So with the overview out of the way.. Run the generator directly, with a target filename as a parameter. (Remember to specify -l unless you’ve done ‘make install’), and you should get a compressed cpio archive created in the name you chose.

Currently, dracut supports root on raw disks (/dev/sda), lvm (/dev/mapper…), and mounting root by label or uuid.
If you have a more esoteric rootfs setup, such as root-on-nfs, right now it’ll fail horribly.

That’s the quick braindump that should be enough to get people playing with it. There is a very low traffic mailing list initramfs at vger.kernel.org, (send ‘subscribe initramfs’ to [email protected] to get subscribed).

2 thoughts on “Dracut status”

  1. I need to look into Dracut. I wrote the initramfs-tools that are currently used by Debian and Ubuntu, and at a quick glance, dracut appears to be a reimplementation of it. I’m curious what problems you’re solving that aren’t already solved by initramfs-tools? (I don’t mean that as an attack – just that if it’s solving the same problems, it may as well just get reused).

    One initial concern I have is at the use of bash rather than some smaller posix shell. The initramfs’ on Ubuntu get quite large as it is loading all the modules needed to boot. =(

Comments are closed.