On Wed, 28 Nov 2018 15:26:59 +0000, Roger wrote in message
<38625727-08b2-2816-85b0-8f57d679618c@???>:

> On 28/11/2018 11:36, Rick Moen wrote:
> > Quoting Didier Kryn (kryn@???):
> >
> >> IIUC, your argument boils down to "depending on /usr for early
> >> boot is a *bug*", while Roger told us why it has become a
> >> *feature* (~:
> >
> > My view, which I expressed in detail prior to Roger joining the
> > thread, is that it's vital to the most vital function of the root
> > filesystem's maintenance software directories
> > (/sbin, /bin, /lib, /lib64) that their binaries function _even_
> > if /usr is not (or at the moment cannot be) mounted -- because the
> > most vital function of those subtrees is backup, restore, repair,
> > maintenance (functions that might be required to
> > recover/fix /usr).
>
> Prior to wheezy, this was considered vital and was explicitly
> required and enforced. From wheezy onward, this requirement was
> deliberately and intentionally dropped.
>
> If you want to backup, restore, or repair your system, you can still
> do so. But you have to do so with /usr present either as part of the
> rootfs or mounted as a separate filesystem.
>
> This isn't a bug, or even a feature. It's a deliberate design
> decision which affects the functioning of the system as a whole. I
> understand your concerns, and I even sympathise with them, but the
> decision to do this was taken over six years ago after extensive
> discussion,

..links to the important parts of those discussions would be nice
and very helpful.

> and it's been implemented and released six and four years ago,
> respectively.


...appearantly with trumpian eptitude, running Karl's usr.pl on my
"life boat" install of devuan_ascii_2.0.0_amd64_desktop-live.iso,
I found 20 programs in /bin or /sbin in 12 packages that might need
a fix.

..I put Karl's usr.pl in /sbin and ran it first bare, then counted
with: usr.pl |grep ^/ |wc -l
and: dpkg -S $(usr.pl |grep ^/ ) |cut -d":" -f1 |sort |uniq |wc -l

..fixing 2 or 3 packages a year, is very doable. ;o)


..now, do we return to the pre-merge policies 6 and 4 years ago?
Yes, as a first step, I believe we should, while we revisit boot
policy history and sites like:
http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/etc.html
where I recommend scrolling down to gems like: "/etc/rcS.d
The scripts in this directory are executed once when booting the
system, even when booting directly into single user mode.
The files are all symbolic links, the real files are located
in /etc/init.d/. For a more general discussion of this technique,
see /etc/init.d/README.", and then back up to: "/etc/init.d

Order of scripts run in /etc/rc?.d
==================================

0. Overview. " etc, which is quite different from Debian's version.


..me, I'd like to see /boot/initrd.img-recovery-$(uname -r) in the
grub menu recovery stanzas guarantee boot into runlevel S or 1, so
broken systems can be fixed, and lessons can be learned from those
fixes.

..to make those system maintenance lessons useful etc, my proposed
/boot/initrd.img-recovery-$(uname -r) should carry at least the same
tools I expect to find in runlevel S or 1, or drop me home there, in
runlevel S or 1.


--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.