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