Quoting Didier Kryn (k...@in2p3.fr): > 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. ;-> _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
