On August 10, 2010 04:25:07 am Simon McVittie wrote: > 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.
Ya, my thoughts exactly, it is easy to check for and provides the most potential benefit. > 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). I saw it as a bit of a toss up whether to file against isc-dhcp-client or the lib's package--either seemed just as likely to end up getting reassigned, and changing the location of the lib should be the quicker/easier/safer fix (regardless of whether that is the technically the most correct fix or not)... more so now that I've had a chance to look at the isc-dhcp-client source package and see that it would most likely be necessary to muck around with code itself (new code during a freeze, eh). > > 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... lhttp://www.ioremap.net/projects/osf Presumably OS Fingerprinting based filter actions are useful early on. <shrug> > > 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. Thanks. - Bruce -- 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/201008100842.14592.bms...@shaw.ca