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 majordomo@vger to get subscribed).

Dracut status is a post from: codemonkey.org.uk

Related posts:

1. An annoying kernel packaging bug. The kernel rpm package creates an initramfs file that gets...
2. Spot the shell bug. This is bugging me. I’m missing something obvious here, and...
3. boot/init miniconf at plumbers next week. I’m MC’ing the boot/init miniconf next week at the Linux...

1.6. Boot tracer

The purpose of this tracer is to helps developers to optimize boot times: it records the timings of the initcalls. Its aim is to be parsed by the scripts/bootgraph.pl tool to produce graphics about boot inefficiencies, giving a visual representation of the delays during initcalls. Users need to enable CONFIG_BOOT_TRACER, boot with the “initcall_debug” and “printk.time=1″ parameters, and run “dmesg | perl scripts/bootgraph.pl > output.svg” to generate the final data.

Very interesting.

Here’s what it looks like when I ran it on my eeepc ..

boot tracing output.

Looks pretty. Though something isn’t quite right.
If you look at the dmesg output, there are over 400 initcalls. Even if we ignore all the uninteresting ones that return in 0 usecs, there’s still over 300 in the log. What gives?
The script stops parsing once the kernel hands off to the early userspace scripts in initramfs. So everything from the ‘Write protecting the kernel’ message at 8 seconds into the bootup is ignored. (Sidenote: The fact that we’re taking 8 seconds just to get to this stage _sucks_, more on that another time). So all the later modules that get loaded aren’t part of this picture.

My perl is a little rusty so I didn’t spot how it does it, but it seems there’s a threshold at which it ignores the initcalls that return quickly. Of those reported in the graph, the ‘fastest’ was ehci_hcd_init at 126837. acpi_init was almost in the same ballpark at 106445, but didn’t get picked up.

Whilst these big hitters are no doubt damaging to the boot time, it’s important to note the cumulative effect of all those five-figure initcalls.

Boot tracing. is a post from: codemonkey.org.uk

Related posts:

1. boot/init miniconf at plumbers next week. I’m MC’ing the boot/init miniconf next week at the Linux...