conathan at gmail.com
Tue Feb 21 01:04:50 PST 2012
On Tue, Feb 21, 2012 at 12:41 AM, Qrux <qrux.qed at gmail.com> wrote:
> 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".
For the most part, We have been doing a great job at providing the
directions to install a program, and leaving the configuration/use to
other documents. This alone, (Building a initramfs) would be a great
option for our readers.
In this one case though, I like the idea of documenting how it works,
and how lfs can use it. I don't imagine that once written, it will
need much maintenance other then version updates.
UUID/Label, would be my primary use of a initramfs if I were to
install it. As a general use, removable media where the device is
not guaranteed to remain static comes to mind. (my own fstab, I have
began using UUID's)
modules, I personally would want to exclude this so I can upgrade
kernel/initramfs separately on my own build/projects. I feel that for
the BLFS book though, that most people would want to include kernel
modules, and if we are only presenting one option, I would vote for
the "include modules" option.
As long as the initramfs is there, and someone has a use for it, that
is half the battle. blfs-support will advise us what people are
looking to do with it once added.
one last stray thought (one I think I would argue against, but it's an
option), we do have the hints project for such expanded hints.
Nathan Coulson (conathan)
Location: British Columbia, Canada
Timezone: PST (-8)
More information about the blfs-dev