[blfs-dev] initramfs

Bruce Dubbs bruce.dubbs at gmail.com
Mon Feb 20 18:02:24 PST 2012


I've been studying the initramfs structure for inclusion in BLFS, mostly 
by looking at the dracut scripts.  This is what happens:

The initfamfs is a complete set of directories that you would find on a 
normal root filesystem.  It is bundled into a single cpio archive and 
compressed with one of several compression algorithms.

At boot time, the boot loader loads the kernel and the initrd into 
memory and starts the kernel.  The kernel checks for the initramfs and 
if found it mounts it as / and runs /init.

The only real purpose of the initramfs is to mount the rootfs.  dracut 
uses a shell script for init.  The top level initramfs directory looks like:

2.0M    bin
4.0K    dev      (empty)
44K     etc
16K     init     (script)
6.9M    lib
0       lib64    (symlink)
4.0K    proc     (empty)
4.0K    root     (empty)
20K     run
624K    sbin
4.0K    shutdown (script)
4.0K    sys      (empty)
4.0K    sysroot  (empty)
4.0K    tmp      (empty)
11M     usr
8.0K    var

The only big directory is /lib and it has 2.8M of kbd files, but the 
file system can grow even larger with some options. For instance, it 
basically copies all the kernel modules too (but I have very few). 
dracut also includes several libraries and binaries that may not needed 
in the LFS environment.

Within the init script, several directories are mounted: /dev,
/run, /sys; udevd is started and /dev gets populated, and the rootfs
is mounted (can use LABEL= or UUID= on the kernel command line).
Then system directories are bind-mounted to the rootfs and udevd is 
halted.  The last thing that happens is that the util-linux program 
switch_root is called that umounts the initramfs and mounts the real 
rootfs.

For most distros, modules are the biggest reason to have an initramfs -- 
plus the fact that they want a one size fits all methodology.  In a way, 
this is the antithesis of LFS where we generally build a custom kernel 
and rarely need an initramfs.

In fact, I think there are only four reasons to have an initramfs in the 
LFS environment: loading the rootfs from a network, loading it from an 
LVM logical volume, having an encrypted rootfs where a password is 
required, or for the convenience of specifying the rootfs as a LABEL or 
UUID.  Anything else means that the kernel was not configured properly.

If I'm missing something here, please let me know.

The reason I'm presenting this here is to get some discussion on how to
present the initramfs to users.  Overall, it is quite complicated. 
There are many ways to present this, however adding encryption or 
loading the rootfs via a network connection seems well beyond BLFS.  I'm 
not sure the benefit of adding this to the book is worth the effort. 
The number of options is large and a very simple presentation may not 
satisfy many users.

What's the best way to proceed?

   -- Bruce



More information about the blfs-dev mailing list