On Tue 14 November 2017 10:42:48 John Hughes wrote:
> Of course SVR4.2 could be ported to an ARM SoC -- you'd just put /stand
> on the internal NAND. (/stand was the SVR4.2 name for what Linux called
> /boot).

Let me put it straight for you:

/noot doesn't get you anywhere to bring up a system. Of course you know that,
so lets assume you agree we need the whole stuff bin, sbin, lib, var, etc, etc,
on your rootfs too.
Now with systemd and all that ensues, your claim is there must be /usr/* on
rootfs as well.
Thats where's the problem starts now: on some SoCs/platforms there might be
only a few MB of NAND and no other storage (particularly none that is always
available without additional mounting of filesystems and storage technologies
needing drivers not monolithic in kernel). Obviously a systemd | usr_on_/
system would not fit onto that tiny NAND, while a 'classical orthodox' system
is supposed to work just fine *without* /usr/ at least in a singleuser mode
which may well be all you want for your tiny embedded system like they are
more and more popular and all but obsolete relics like you claimed.

To put it utterly clear and unambiguous: systemd explicitly ignores the needs
of tiny embedded systems, Poettering been very clear on that. And distros
follow this path by introducing policies like mandatory /usr/ on rootfs and
successively phasing out support for other init systems. Requiring embedded-
system-developers to sort out and "unmerge" the /usr/?bin vs /?bin and */lib/
stuff is backward in thinking. It's those who need stuff form /usr/* in early
boot / init who are in charge to find better ways to solve their (pretty
bizarre) problems than to just mandate all /usr/ being available after just
rootfs got mounted. It's *not* about when and how to keep or mount /usr/, it's
about init system and early boot (or a minimal system) is supposed to *not
need /usr/* at all - at least in a first approximation, usecase specific minor
modifications might apply.


/j