Quoting KatolaZ (katolaz@???):

> # ldd /sbin/mount.nfs | grep "/usr"
>         libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f82f53ac000)
>         libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f82f52cf000)
>         libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f82f529b000)
>         libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f82f4fd1000)

If I were relying on NFS during early boot, I'd file a bug against package
nfs-common, and also, meanwhile, compile a local-package substitute with
either static binaries or ones linked to libs in /lib (and provide those).

> # ldd /sbin/lvscan | grep "/usr"
>         liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fde00702000)

>
> # ldd /sbin/lvs | grep "/usr"

         liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fd3b7fa1000)

Ditto package lvm2. (Which FWIW I've avaoided needing.)

> # ldd /sbin/sysctl | grep "/usr"
>         liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f3ab7b18000)

Um, I know of no reason why /sbin/sysctl would be urgently needed in a
minimal system prior to availability of /usr for purposes of backup,
restore, system repair, etc. I've never needed to futz with /proc/sys/*
entries while running in maintenance mode, but, if one did need to do
so, doing the task using 'echo' is more than sufficient.

> # ldd /sbin/gdisk | grep "/usr"
>         libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7ddf10f000)

I haven't yet needed gdisk (& cgdisk, sgdisk, fixparts), having so far
successfully avoided GPT. The obvious alternative to gdisk is GNU
parted (package parted), and FWIW it suffers a similar build boo-boo,
requiring library libtic.so.5 (terminfo) from inside /usr/lib.

Tsk-tsk. ;->

> # ldd /bin/kill | grep "/usr"
>         liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f9f6aa4a000)

>

> # ldd /bin/ps | grep "/usr"
>         liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fd7f6ebc000)

Yeah, those two are really annoying. FWIW, my server system has older
versions of those two utilities that do _not_ have that (IMO) build
error. Local packages will be an immediate resort, when/if I hit that.

> # ldd /bin/efibootmgr | grep "/usr"
>         libefivar.so.1 => /usr/lib/x86_64-linux-gnu/libefivar.so.1 (0x00007f7ed22bd000)
>     libefiboot.so.1 => /usr/lib/x86_64-linux-gnu/libefiboot.so.1 (0x00007f7ed20b0000)

As with GPT, I've managed so far to step sideways and successfully evade
the Second System Effect poster child that is EFI.

I'm also unconvinced that efibootmgr is essential to a 'recovery'
minimal maintenance system, anyway. My readings suggest that I would
want to have a 'EFI stub kernel' configuration where you place an
(unsigned) kernel binary image in the EFI System Partition and rely on
the EFI firmware to boot that kernel and mount the root fs directly
without needing a bootloader. Coverage at, among other places:
https://wiki.gentoo.org/wiki/EFI_stub_kernel

(As usual, I'm saying this is an example of what would Work for Me[tm].
What might suit others or some entire abstract group of people is a
different discussion.)

> Most of the utilities you would need to debug a problem in mounting a
> /usr over NFS, or a failing lvm volume, or a scrambled efi partition
> (some of the use cases somebody mentioned before) need stuff in
> /usr.

This has not been my experience for my own use case (granting your point
about /bin/kill and /bin/ps as provided in packaged versions I am not
yet running). If I encounter that, I will consider that situation to
involve critical bugs that I would resolve through the package
maintainer if possible, or via a locally built alternative if not.