[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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: