On Tue, 10 Aug 2010 at 03:15:35 -0600, Bruce Sass wrote: > AFAICT, the reason is so that a minimal but functional system is > guaranteed to exist so long as a local HDD with a root filesystem is > available
The fact that you can use it for troubleshooting/repairs is a nice (and desirable) side-effect, but the actual requirement is that you have enough binaries, libraries etc. to mount your /usr filesystem. The situation you have (NFS /usr) is meant to be supported, if I understand correctly, but as you've observed, it's not heavily tested. In theory, I believe NFS /var is also supported, but that's likely to be even less well-tested. > If that is a good reason, perhaps even The reason, for having both /bin > and /usr/bin, etc., then doesn't it follow that all files required by > executables residing in /bin and /sbin should also be available so long > as a local HDD with a root filesystem is available (otherwise those > executables are either broken or crippled)? There need to be enough libraries in /lib for the binaries in /bin and /sbin to run and carry out core functionality, including anything that's normally done before /usr is mounted. Beyond that, I think it's OK if binaries there work sub-optimally, as long as they work. (For instance, if /bin/vi is vim, it's OK if it can't do syntax highlighting until /usr is mounted, as long as it can edit text.) It might be worth having a Lintian check for the situation you describe, since missing libraries will generally prevent the executable from starting up at all, whereas missing bits of /usr/share or /var might not be so important. If you're filing bugs for this, they should be against the thing that doesn't work (e.g. isc-dhcp-client), not the library it requires (I see Kurt has reassigned your isc-dhcp-client bug already). > iputils-ping: /bin/ping6 Looks likely to be a bug, but probably of 'normal' severity; it doesn't affect most people, and you don't need ping in order to boot (although it's a good troubleshooting tool). > isc-dhcp-client: /sbin/dhclient If you're using DHCP and NFS /usr on the same machine , you're braver than me :-) but yes, if that's the situation you have, then the DHCP client is in the critical path for booting. > discover: /sbin/discover It may be worth checking why discover is on the root filesystem at all? > util-linux: /sbin/fsck.cramfs > libz.so.1 => /usr/lib/libz.so.1 (0x46d5e000) Ubuntu has moved zlib to /lib for some other reason, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591013 requests that Debian do the same. > util-linux: /sbin/mkfs.cramfs > libz.so.1 => /usr/lib/libz.so.1 (0x46d5e000) The FHS says mkfs.* have to be on the root filesystem. I'm not entirely clear why this is. > iptables: /sbin/nfnl_osf > libnfnetlink.so.0 => /usr/lib/libnfnetlink.so.0 (0x46d15000) Looks like a bug, but nfnl_osf has no man page, so I have no idea what it does or whether/why it needs to be in /sbin... > udisks: /sbin/umount.udisks > libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x4b1bb000) > libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x47277000) > libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x470f8000) This needs to be in /sbin because umount looks for /sbin/umount.$FILESYSTEM and udisks acts like a pseudo-filesystem, but I don't think unmounting things that were mounted with udisks in the absence of /usr really needs to be a supported use case, so I'd say this is 'minor' severity. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100810102507.ga18...@reptile.pseudorandom.co.uk