initramfs support

Dan Nicholson dbn.lists at
Mon Jun 18 17:42:19 PDT 2007

Nice to see this come to light. It's needed, not just for LVM, but for
the general problem of "I want to make a generic modular kernel".

I didn't seriously look yet, but just skimmed the scripts. Looks good
for a start. There are tons of features that could be added, but a
simple dedicated root is a good start.

On 6/18/07, Bryan Kadzban <bryan at> wrote:
> I have mkinitramfs getting dependencies for binaries from ldd, because
> hardcoding the glibc loader (and libs) would be wrong if it grabbed any
> 64-bit binaries from the running system.  Normal LFS doesn't install any
> 64-bit binaries, but I'm on a multilib CLFS, so to test it I had to grab
> whichever libs are required by the binaries.  And if multilib CLFS
> support isn't that hard, this package could probably be used by them also.

ldd is fine, IMO. One suggestion for the loop of finding libraries.
awk does everything you need in one shot:

$ ldd /sbin/modprobe | awk '/=> \//{print $3}'

> I have it copying all kernel modules into the initramfs, which ends up
> making it enormous if I run it after installing the nvidia module.  (The
> nvidia module is 9M.  Non-nvidia modules total up to about another 8-9M
> uncompressed on my system.  The compressed initramfs is about 8M.)  I
> could just copy modules that are expected to be required to get the root
> FS up, but then I'd have to rerun depmod, and that means I'd have to
> create a separate copy of the /lib/modules/$KVER tree.

This is what I'm using in my very unscientific experience (much of
which came from the Fedora mayflower script for their LiveCD):

                /lib/modules/${KERNEL}/kernel/drivers/ata \
                /lib/modules/${KERNEL}/kernel/drivers/ide \
                /lib/modules/${KERNEL}/kernel/drivers/scsi \
                /lib/modules/${KERNEL}/kernel/drivers/acpi \
                /lib/modules/${KERNEL}/kernel/fs \
                /lib/modules/${KERNEL}/kernel/input \
                /lib/modules/${KERNEL}/kernel/usb/input \
                -type f -printf '%f\n' 2>/dev/null \
                | sed 's/\.ko$//'`

And then you can use modprobe --show-depends to get all their
dependencies. Oh, that doesn't include the usb storage stuff, so
that's not complete. The input stuff is there so I can drop to a
shell, but you're not doing that.

Another thought is to allow something like /etc/sysconfig/boot to
allow people to specify the specific modules they want. For my system,
I have:

INIT_MODULES="ext3 sg sd_mod ata_piix ahci usbhid ehci_hcd"

> I have mkinitramfs strip out all the GROUP keys in udev rules, because
> group lookups don't work without glibc's NSS libraries (which aren't
> included).  But group membership of the devices doesn't matter, either,
> since everything in the initramfs runs as root, and these files don't
> get moved to the real system's /dev.

In my experience, you can leave out most of the rules since we'll run
udevd again in the real init and it will set up all our groups, etc.

> I used the livecd's /init as the basis for this initramfs's /init,
> though a few things changed because it uses different programs.  (For
> instance, the package contains klibc's run-init, mount, and umount
> programs, and klibc's mount doesn't take the -n option.)

klibc's mount also doesn't like the "defaults" option. This is a
problem for me because I embed fstab into the initramfs to assist in
guessing the root partition, and I often have "defaults" as the
options for my partitions. Resulting in this ugliness:;a=commitdiff;h=f7c36c8a00ee8a2b190df03b1749e0ee0f6d7517

> 1) Do we need this?  (I think we do, since the kernel people expect it
> to be available, at least.  It probably doesn't have to be installed in
> the book, but we probably need a note pointing the user to something if
> we don't put this in.)

Yes, but I'm inclined to punt for 6.3 until we can get quite a bit
more testing. Or at least be confident that we can put it in the book
and most people will be able to boot.

> 2) Might some other design work better?  (I want end users to be able to
> just say "mkinitramfs" and have everything work, if possible.  Heck, I'm
> a user of this, and that's all I want to do.  ;-)  A few options may be
> required, like the current version's -k/--kernel-ver option that builds
> against a different kernel, but I'd like to keep those minimal.  I still
> have to add -?/-h/--help though.  And a manpage.)
> 3) Any other comments/issues?

Allow the output file to be specified. Maybe I want to make a
temporary initramfs in my home directory. Or I want them in
/boot/initramfs/. Possibly require -f|--force if it will overwrite an
existing file.

I still believe we could easily add cpio to LFS, and it may be more
desirable than gen_init_cpio.

Oh, a bit more food for thought on existing initramfs solutions, this
is what Jürg is using on paldo. He says he hasn't needed to change it
in a long time.

Nice job, Bryan. Looking forward to more comments.


More information about the lfs-dev mailing list