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, Mike.
>
> On Wed, Mar 28, 2012 at 12:24:14AM -0400, Mike Edenfield wrote:
> > > 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:
>
> > > 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.
>
> I'll articulate a few.  (i) The initramfs involves having two copies of
lots of
> software around.  (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.  (iv) The initramfs requires a
> potentially long script to make it work.

> My idea was for /sbin to vanish from $PATH just as soon as the boot had
> been completed; PATH gets set anyway on the initialisation of something or
> other, so this would happen automatically, just like the initramfs
disappears
> when the switch_root is done.

The criticisms you made about an initramfs are valid, and your basic point
is correct: the ugliness of having a "shadow /sbin" is no worse than the
ugliness of an initramfs. 

I admit that much of my criticism here is not of the idea but of trying to
come up with a working implementation. The major benefit of an initramfs
solution is that it fits into the existing Linux boot process with minimal
impact: all of the ugliness you pointed out vanishes as soon as it has
completed its work, and the existing /sbin/init startup code is launched
exactly as it would be without an initramfs. Your process would require
either changing that existing /sbin/init process, or changing the steps the
kernel takes on startup, in ways that I can't articulate because I haven't
gone through the exercise of making it work. Taking /sbin out of the path,
though works for me. As I understand it, /sbin *used* to be for "static
binaries", and only later did it retroactively become "system binaries",
which is silly. That's what DAC is for. The only benefit of a separate /bin
and /sbin is to have different binaries with the same name in both places,
which is just begging for trouble. Your approach actually seems to be
bringing /sbin back to its roots. :)

I can think of a few useful options, though; perhaps what you're calling
/sbin is actually /boot/bin; like now, /boot is rarely mounted once the live
system comes up. Perhaps the kernel is configured to look for and run a
/boot/bin/init before it tries to mount it's rootfs. You are basically
replicating the initramfs solution, just on the boot partition, as this is
almost exactly what happens now.

Alternatively, perhaps /sbin/init can get smarter; much of this problems
with getting /usr mounted at the right time stems from difficulties in
expressing the required order and dependency information in the init
scripts. If /sbin/init could be explicitly told "this is the 'mount my /usr'
script" and knew to run it or not, based on the existence of a /usr mount
point, that could happen very early in the boot process.

> > [ more criticism, a lot of which I accept. ]
>
> 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 one possible solution; I think there are several places where the
kernel could potentially be made "smarter" about what is going on in the
userland environment; for example, if udev always received block device
events first, *it* could be tasked with mounting /usr when it saw that
/dev/sda3 was available and in /etc/fstab, then it could happily run
alsaconf or bluetoothd or whatever else when those devices popped up. I also
admit I don't really understand autofs too much, but it seems like
automounter support should be able to do something like this as well.

Keep in mind, though, that the point of an initramfs is not to get /usr
mounted. It's to get / mounted; if your rootfs happens to be on some
hardware, network, or logical block device that needs special handling
before it can be used, you need *somewhere* to put those utilities that the
kernel can find them. The fact that you can also use an initramfs for all of
these other pre-init steps is just added benefit.

--Mike