BOF notes

• Lots of people are requesting dmfakeraid, but Adam doesn't like it.
• We should definitely manage to get dmcrypt in
• Something about depmode
• Figure out something about klibc and glibc
• Runtime assembly of initramfs

Faster, compacter initramfs

• Preorder initramfs scripts

  • Currently (dapper) all the scripts in the initramfs scripts directories are ordered runtime at boot. Why isn't this ordering done at mkinitramfs time? I haven't done any measurements yet, but I guess this could speed things up a little. initramfs' are designed in a way that allows run-time assembly by the boot loader. Because of this, there's no way to promise that the information gathered at compile time is accurate for boot time. There are two concerns here: The time it takes to get through initramfs, and the size of the initramfs (constrained for boot partitions, loading time over the wire, etc.) The time it takes to get through initramfs is about as quick as one could hope for. The depmod is immeasurably fast. Ordering scripts is a series of operation in RAM. The major blocking points are usually device detection which needs to be done anyway (USB Boot, SCSI Boot, etc.). In terms of slimming down the size of the initramfs, the best option is to make MODULES=dep work. This will include only the kernel modules and other things (lvm, evms) required for booting in the initramfs.

    Thanks. But why is it designed to allow run-time assembly? I have looked at the run_scripts function and all it does is reordering the scripts according to their hard-coded PREREQs. I realize this goes fast anyway, all being in RAM, so it's not a critical issue. Dry-running this manually seems to take 0.2 seconds for each script directory here...

    Lucid has moved the ordering of scripts and depmod to mkinitramfs.