[blfs-dev] initramfs

Qrux qrux.qed at gmail.com
Tue Feb 21 00:41:26 PST 2012

On Feb 20, 2012, at 6:02 PM, Bruce Dubbs wrote:

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

I agree that initramfs isn't necessarily good for LFS.

I wouldn't call kernel modules the "antithesis" to a "custom kernel".  Those are completely orthogonal concepts.  Sure, LFS can advise people to build their own kernel, and, b/c LFS doesn't use initrd/we, LFS can suggest that people static build all the parts they'll need.

But, that doesn't mean they *must*, or that it even makes sense.  Modules aren't just a "one-size-fits-all" way of building everything under the sun.  You may have modules that you don't need to load in all situations.  I think it's probably more apt to compare kernel modules to SSL engines.  You don't need them all, all the time.  But, you don't leave them out.  Kernel modules are similar to that.  If you don't load them, they just take up a bit of disk space.  If you statically compile them in, they're "loaded" no matter what.  So, as much as I think it makes sense to compile the "whole" OpenSSL package, it might make sense for people to compile everything they *might* ever need as modules.  And only statically link the parts that they need to boot.

Needless to say, whether you use modules is only partially related to initramfs.  For LFS, I think it makes sense to avoid it.  For BLFS...it's probably enough to suggest to people how to build it--and not cover every use-case.  

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

Device drivers for root devices (SCSI, iSCSI, AoE, FC, SAN, etc).

And, in the same vein as LABEL and UUID, udev can benefit from initramfs--because sometimes you need to call external programs to generate the correct name (I run into this issue on legacy 3ware SATA RAID cards, which need their custom management tool--or smartd--in order to create reasonable entries in /dev/disk/by-id).

> 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?

Seems like you could do a page on making an initramfs filesystem.  And, mention it's applicability to support booting with modules.

But, I think this is really starting to venture too far down the path of BLFS turning into a HOWTO for everything-linux-related...which probably creates even more time-pressure between LFS releases to keep BLFS "current"--which probably just results in more BLFS "lag".


More information about the blfs-dev mailing list