Le 28/11/2018 à 11:25, Rick Moen a écrit :
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. ;->
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* (~:
It would certainly be possible to move all applications and dynamic
libraries needed for early boot from the /usr tree to /bin, /sbin and
/lib, but Debian has made a different choice. In the case of NFS, I
agree that the only thing to do would be to move the dynamic library to
/lib. Instead, it seems /lib has become a holly directory where only the
libc and the dynamic linker are allowed to live.
Didier
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
