initramfs - why not?

Bryan Kadzban bryan at
Mon Oct 31 18:27:08 PST 2005

Zachary Kotlarek wrote:
> with an initrd I'd need to maintain a whole set of binaries and 
> libraries in a file systems that doesn't get used except for the 
> first 5 seconds after boot. While  there are certainly things you can
> do with an initrd I've never seen  the benefits as outweighing the 
> hassle of creating and maintaining  the filesystem.

Well, initramfs, not initrd.  They are different:

1) I believe an initramfs is mounted earlier than an initrd would be
2) an initramfs would do more than just load required modules
3) there is no FS on the initramfs image (it's just a cpio-format file)

There may be more differences, but I can't think of them ATM.

It would be fairly easy to use whatever executables are on the system at
the time the kernel gets compiled.  Yes, they are copies, not symlinks,
but they would update every time the kernel gets recompiled.  (Not that
replacing the system glibc is always a good idea anyway, but whatever.
Other stuff that got upgraded would be updated in the initramfs.)

And it wouldn't be in a separate file like an initrd is; it would be
built right into the kernel binary.  It wouldn't use appreciably more
RAM after it was done doing its thing, though, because the last thing it
would do before chrooting into the final system and exec'ing /sbin/init
would be to delete all the files it holds (except udev's logged events,
which would be deleted after being replayed).  The system would be left
with one root directory, and one dentry for the target directory of the
chroot -- the directory containing the real root FS.  The kernel binary
would be too big for a floppy boot, but 2.6 doesn't support directly
booting from a floppy anymore either.

I'm not sure how there would be any maintenance, I guess.

The process of creating the image is hard to figure out (or at least, it
was hard for me to figure out), but that's what the book would be

Maybe I should try to write a hint instead.  ;-)
-------------- 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