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

[Mike Edenfield]

> From: Alan Mackenzie [mailto:acm@×××.de]
>
> Hi, Alan.
>
> On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote:
> > On Tue, 27 Mar 2012 21:24:22 +0000
> > Alan Mackenzie <acm@×××.de> wrote:
>
> > > That is precisely what the question was NOT about.  The idea was to
> > > copy (not move) booting software to /sbin instead of an initramfs -
> > > the exact same programs, modulo noise - to have the SW in /sbin
> > > necessary to mount /usr.
>
> > Two words:
>
> > shared libraries
>
> > Copying binaries is not enough. You have to find and copy every shared
> > library those binaries use. Plus all the data and other files they
> > might need.
>
> > This is non-trivial.
>
> <silently screams>.  It's equally non-trivial for initramfs, yet nobody
> seems to be raising this objection for that.
>
> Why is nobody else on this thread willing to take up its main point, the
> exact equivalence between the known, ugly, initramfs solution and the as
> yet half-baked idea of putting the same binaries into /sbin?

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. That notwithstanding:

The binaries on the initramfs are not always the same as the ones installed
in the system; frequently they are statically linked versions, or
stripped-down versions, or otherwise unsuitable for being used after the
full system is booted. (Dracut, for example, forces you to add
USE=static-libs to a lot of the packages it wants to put into your initramfs
image.) Putting those binaries into the execution path of the system is a
bad idea because you don't always them to run once the system has booted --
I want the full set of udev rules, not the bare handful that my initramfs
has on it.

You could fix this by arranging for them to be put somewhere outside the
normal path, where they can be found by the init system at boot-time but
then ignored once /usr was up. This would also mean managing two copies of
these packages on your system, which means the package manager would need to
ensure that both static and dynamic versions, or full and minimal version,
or whatever else, were built and installed in the correct locations. And
this is ignoring the possible side-effects of reordering the boot scripts to
unilaterally try to mount /usr very early; I don't know what, if any, those
would be but someone would need to figure those out. The initramfs solution
doesn't change the order of boot scripts, so people who are not using one
see no change.

Again, this is all *possible*. It is one option for solving the
missing-/usr-at-boot problem, it is just not the option that has taken hold
in the community. The people who are writing the software consider an
initramfs a more elegant, cleaner, *less* ugly solution that what you are
proposing, in the context of a general-purpose solution suitable for the
most number of users. As they are the ones doing all the work, they get to
make that call. The fact that most of us seem to agree with, or at least not
actively disagree with, that opinion is just an added bonus.

Your solution would be equally as successful at solving the problem, once
someone put in the effort to actually make it work, make it repeatable, make
it stable, and document/automate it for others to use. All of those steps
have /already happened/ for an initramfs, so until someone comes up with a
concrete reason why initramfs will not work, there is absolutely no
motivation to waste time on anything else.

--Mike