Re: why are there /bin and /usr/bin...
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.
Reply to: