Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs?

[Michael Mol]

On Thu, Mar 29, 2012 at 2:11 PM, Neil Bothwick <neil@××××××××××.uk> wrote:
> On Thu, 29 Mar 2012 13:13:40 -0400, Michael Mol wrote:
>
>> On Thu, Mar 29, 2012 at 12:35 PM, Neil Bothwick <neil@××××××××××.uk>
>> wrote:
>
>> >> 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.
>>
>> And anything they might conceivably link to. Not everything supports
>> static linking.
>
> Those four all have static version, there are no libraries in my
> initramfs.

Which is good.

>
>> Don't forget boot-time X-based animation, too. That's an
>> extraordinarily common feature of mainstream desktop distributions.
>> And there will be other things, I'm sure.
>
> I don't get involved with those, but I'd hope something intended to be
> run so early would have minimal dependencies, if any.

There's a pretty firm distinction between what things get used for,
and what they're intended for. The udev developers presumably were
reacting to this when they decided to support an "anything goes"
policy regarding plugscript behavior.

And while I'm generally the kind of person to find unintended (but
perfectly compatible with their spec) uses for things, I don't figure
on being one to do so in my init sequence. That said, someone else
will. That's been a long tradition in open source software and hacker
culture.

In short, depending on things only being used when they're intended to
be used, in the circumstances they're intended to be used in, is
sticking one's head into the sand. Workarounds will always arise to
break such expectations and assumptions.

>
>> >> (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.
>>
>> That's exactly what Alan just noted in (ii), but perhaps portage
>> handles (iii) in the case of LVM.
>
> Exactly, there are static and dynamic files, all handled by portage.
>
>> >> (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
>>
>> Things look much simpler when you abstract away the details. You still
>> have to manage lvm, mdraid and whatever else is necessary for mounting
>> things. That's where 'potentially long' came from, I expect.
>>
>> >> I think that qualifies the initramfs solution as ugly.
>> >
>> > Only if you build the initramfs with USE="fud".
>>
>> FUD: "Fear, uncertainty and doubt"
>>
>> In short, three things which are important to rationally examine and
>> deal with on a case-by-case basis.
>
> Yes, ideally before you start spreading them instead of vague handwaving
> about initramfs being ugly and using "lots of files" (four only counts at
> lots when applied to wives).

Fine. NFS clients. Samba clients. Crypto. SSHFS. NTFS-3g. Security
auditing. Virtualization tools. Perl, python or whatever is necessary
to handle some case which required scripting. X. Graphics loading
libraries. Cupsd, because some graphics library required by a
bootsplash expressed a dependency on cairo, which expressed a
dependency on something else, which expressed a dependency on cups.

Perhaps crypto required a crypto daemon to be loaded, which required a
smartcard, or required auth from a serial port or network connection.
Perhaps an accurate clock is needed. Or perhaps a network policy
demands that a machine be authorized to boot, so an LDAP client is
required.

It's easy to imagine entirely plausible circumstances which would
bloat initramfs size and maintenance. At some point in time, these
various things would normally be the simplest and most straightforward
way to reach a quick end to some problem or another for some poor guy
stuck in a private hell. And this initramfs crap increases the amount
of work he has to do to solve his unique case.

-- 
:wq