On Thu, 29 Mar 2012 15:56:28 +0000, Alan Mackenzie wrote:

> > Well, for one, the initramfs solution is not generally considered
> > "ugly" except by a select vocal few who object to it on vague,
> > unarticulated grounds.  
> 
> I'll articulate a few.  (i) The initramfs involves having two copies of
> lots of software around.

Lots? For most people busybox is enough! If you want encrypted
filesystems on LVM over RAID that rises to a total of four executables.

> (ii) What's more, these two copies are often
> different, one being built with static libraries, the other with dynamic
> ones.  (iii) This situation is not (as far as I know) yet handled by
> Portage, which means in building such software statically, you've got to
> save the dynamic version somewhere else whilst you're doing it.

That's wrong. For example, LVM builds dynamic executable plus the
lvm.static file for use in the initramfs.

> (iv)
> The initramfs requires a potentially long script to make it work.

Mount /proc, /sys and /dev.
Mount root
Unmount /proc, /sys and /dev.
switch_root

> I think that qualifies the initramfs solution as ugly.

Only if you build the initramfs with USE="fud".

> I think I have the elegant solution: that would be for the kernel to be
> able to mount several partitions at system initialisation rather than
> just the root partition.  With this, all the issues we've been
> discussing simply wouldn't arise.

That's an excellent idea.

> I accept that this solution will never happen.  Sadly.

It's already happened here. My kernel mounts / and /usr thanks to the
inbuilt initramfs


-- 
Neil Bothwick

I just bought a microwave fireplace... You can spend an evening in
front of it in only eight minutes...

Attachment: signature.asc
Description: PGP signature

Reply via email to