initramfs - why not?

Zachary Kotlarek profplump at engineer.com
Mon Oct 31 23:47:41 PST 2005


On Oct 31, 2005, at 8:27 PM, Bryan Kadzban wrote:

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

I'd argue that the difference between an archive mounted as a  
directory tree and an actual file system is semantic at best.

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

You're right -- I didn't realize there was a difference. But none of  
differences you highlight really change my point. Even if there are  
no extra packages required for the initramfs there's still extra  
maintenance involved in keeping it up-to-date. There's still the  
initial work of setting up the initramfs directory tree with all the  
required programs and libraries, and packaging it into an archive and  
re-packing the kernel to include the archive. There's also extra work  
every time I update any package which is in the initramfs -- instead  
of just installing new binaries/libraries I now also have to re- 
assemble and re-build the initramfs and re-pack the kernel.

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

Am I missing some script that assembles the initramfs for me? I don't  
mean to be fesicious, but you are talking like there's a script in  
the kernel that assembles the initial initramfs, occasionally checks  
it against / for changes and automagically re-packs the archive and  
kernel when something is different, and I really haven't seen  
anything remotely like that. Did I just miss it somewhere? Am I  
misunderstanding what goes into the archive?

     Zach
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1664 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20051101/d007d32f/attachment.bin>


More information about the lfs-dev mailing list