initramfs support

Bryan Kadzban bryan at
Mon Jun 18 16:13:17 PDT 2007

Hash: RIPEMD160

Not sure how many people read lfs-book, but Alexander brought up an
issue with LFS in bug #2033.  Upstream (by which I mean the kernel devs)
say that basically any system needs to have support for an initramfs for
several kernel-supported setups to work right.  The problem in question
there had to do with having a root FS on LVM, but there are other cases
where it's needed too.

I did some work over the weekend on a basic mkinitramfs script, so we'd
have a semi-supported way for users to create an initramfs (which can
then be modified if our default one doesn't support their setup).  I set
up an svn repo at
with the PoC mkinitramfs "package", and it's pretty much working for me
now.  (Notes on the SVN: It's hosted on an ADSL, so it's probably going
to be slow.  It's also using a self-signed cert, which has fingerprint
"41:26:41:7e:16:7f:ba:2d:62:7d:ef:4b:70:6c:4f:76:b7:6c:a1:1b".  It's
*also* read-only without credentials, and I'm the only one that has them
so far.)

Some notes on the design:

Licensing is GPLv2-only, because of gen_init_cpio.c.  The license of the
other tools in there should be GPLv2-compatible, I hope.

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.

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.

I have a default module blacklist set up to include just ivtv.  Any
module that requires firmware should be added to this list though;
otherwise, without the firmware, the module won't initialize properly.
(And I don't copy /lib/firmware to the initramfs.  Perhaps I should.)

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.

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.)

This package does *not* require cpio.  It contains a modified version of
the kernel tree's usr/gen_init_cpio.c that can take its input from
stdin, and it just echos the right strings to that program to generate
the archive.  This program is (like mount, umount, and run-init)
installed into /usr/share as data, since users probably shouldn't ever
need to run it manually.

(End of notes.)

I'd like to get this working with devmapper and dm-raid if possible
eventually (and other setups), though I can't test any of that.  But
before I do that, I'd like to get some comments from others.

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.)

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?
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the lfs-dev mailing list