Quoting Didier Kryn (kryn@???):

> Le 28/11/2018 à 08:11, Rick Moen a écrit :
> >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).
>
> Debian supports diskless hosts mounting an NFS filesystem on /.

Of course yes. _But_, what I was commenting on was the dependency on
/usr for the NFS mounting utility in /sbin. That means -- KatolaZ's
point -- that /sbin/mount.nfs will not function in the absence of /usr.
My answer to KatolaZ amounted to: Yes, and that's a bug. I would, if I
needed that during early boot (e.g., during maintenance operation, thus
needing to be functional even if /usr cannot be mounted), then I would
file a bug against mount.nfs and, while awaiting attention to the bug,
compile a local replacement.

> When using initrd/initramfs, this kernel option is no longer
> necessary and I guess it is just simpler to rely on the modules
> provided by nfs-common. The motivation is the same as for device
> drivers and filesystems: boot a generic kernel, have all modules
> available during early boot to mount / (and /usr).

But notice that if /usr _is not_ (e.g., cannot be, for some reason)
mounted, then you are screwed: /sbin/mount.nfs breaks. KatolZ cited
that utility's dynamic library dependency on a lib in /usr/lib as a
reason why separate /usr is impractical (for systems needing NFS access
even if /usr is unavailable). I replied that, IMO, no, that's a reason
why /sbin/mount.nf thus constructed, has a build error. ;->