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...
signature.asc
Description: PGP signature