initramfs - why not?

Bryan Kadzban bryan at
Mon Oct 31 15:59:19 PST 2005

I just upgraded my kernel to 2.6.14, and I remember discussions about
that version, udeveventrecorder, initramfs, and getting rid of coldplug
-- and the whole hotplug package -- happening several times now.

What I'm wondering is, for anyone that doesn't think an initramfs is
good, why do you think that?  The way I see it, it's another part of a
Linux system (more specifically, the kernel) that we haven't really
touched on before because it wasn't needed.  With a move like replacing
coldplug, it might become necessary, which I guess I see as just another
opportunity to teach readers more about Linux -- in this case, what
happens in "early userspace", before init gets started.  (But I'm still
not entirely sure whether it *is* needed or not, or whether it's even
what upstream recommends anymore.  If not, then I wouldn't put an
initramfs in just to teach about it; IMO the system should be used for
something if it's there.)

(From what I remember of the various options that Alexander has proposed
in the past, the initramfs seems to be the cleanest anyway.  Why walk
sysfs, like udevstart does in v6.1, when you can just save the events as
the various built-in drivers create their kobjects?  Same with loading
modules -- why try to regenerate the lost events, when you can just save
the originals?)

I do remember some objections about requiring cpio to be installed on
the host -- but an initramfs doesn't.  True, one option is to have cpio
installed on the host, then making a cpio.gz archive, then pointing the
kernel at that while configuring it.  But another option is to have the
usr/gen_init_cpio binary from the kernel create the cpio archive for us,
and that doesn't (maybe "doesn't always") require the cpio binary.  We
can either have a directory which the gen_init_cpio binary will create a
cpio archive from (this may require cpio, I haven't tested it), or we
can write a control file, which gen_init_cpio will interpret (I've done
this on a system without cpio, and it works).  The file's format is
given by running usr/gen_init_cpio --help from the top level directory
of the kernel source tree.

The kernel documentation (early-userspace/README) recommends using
klibc, but that's not strictly required either.  As long as you don't do
name lookups in the other binaries (or otherwise require the nss stuff),
glibc will work fine. Yes, it'll be about 700K bigger, but what's 700K
of RAM that's used by files that will be deleted soon anyway?  Not much,

We could even have an LFS-specific initramfs "package" that extracts
into a directory containing everything -- the control file (containing
references to LFS's bash, glibc, some basic devices, the udev files that
are needed, and a couple other executables), the /init shell script, and
that would be about it -- and give a sort of overview of the way it
works on the page where we use it compiling the kernel.

The initramfs itself is certainly something that I'd have loved to learn
about from the LFS book (figuring out how to put one together, how it
does what it does, etc.).  I admit, I may be different than most people
that way, but I don't know.  (I'm also not sure I got everything I need
in my initramfs, but that's what this upcoming reboot is for.  ;-) )

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the lfs-dev mailing list