Re: support for merged /usr in Debian
On 05/01/16 15:55, Ian Jackson wrote:
> Abolishing the distinction between /usr and /
This seems to be a somewhat frequent point of confusion so, at the risk
of beating a dead horse:
"Merged /usr" is not about removing the distinction between /usr and /,
it's about removing the distinction between subdirectories of /usr and
the corresponding subdirectories of the root, namely /{bin,sbin,lib*}.
"lib*" means lib and lib64 in our case, and maybe lib32 (I forget
whether we have any architectures where that exists). On distributions
that have it, libexec is also in-scope for "merged /usr", but Debian
doesn't have libexec anyway.
Those subdirectories of the root are the ones that contain static
OS-provided files. They have more in common than they have differences:
for instance, if you want /usr/bin to be read-only except during
upgrades, then you almost certainly also want /usr/lib, /bin and /lib to
be read-only except during upgrades.
The parts of / that are *not* static OS-provided files and so do not
already have an equivalent in /usr (namely /etc, /var, /run, /home,
/srv, /opt...) are unaffected, and nobody is proposing /usr/etc or
/usr/var or whatever. That would defeat the objective of putting all the
static OS-provided files together, by mixing in files that are not static.
There are two approaches that have been tried in the past for removing
the distinction between /usr/{bin,...} and /{bin,...}, and only one of
them is under discussion here; I think everyone agrees the other is a
bad idea.
The approach Ian seems to be arguing against is the one Debian GNU/Hurd
tried to use for a while, where /usr is a symlink to /, and there are
real directories /bin, /lib, /share... which contain all the static
files. This approach is not good for various reasons, particularly the
one Ian pointed out: it becomes difficult to have a read/write /etc but
a read-only /{bin,...} because they would naturally live on the same
filesystem. This is not being proposed,
The approach used in Fedora etc., and in Debian if usrmerge is
installed, is to keep /usr a real directory, move all files into it, and
make /{bin,sbin,lib*} permanent compatibility symlinks onto /usr. That
does not interfere with having a rw / and a ro /usr; indeed, it makes it
more effective, because bash, libc6 etc. would also live on /usr and
hence be ro.
The main (only?) thing that is possible with the traditional concept of
split /usr, but *not* possible with merged /usr, is using / as some sort
of recovery system, and hoping that / is statistically less likely to be
damaged by a hardware or kernel error than /usr because it's so much
smaller. However, other factors mean that this is much less useful than
it was 10 years ago:
* distribution kernels usually (always?) use an initramfs, which is
smaller than /, does not need to be rw during normal operation
(unlike /), and by definition includes everything necessary to
mount / (and as of jessie, /usr), so it makes a somewhat better
recovery system than / itself;
* on modern storage media, the space requirements for a separate,
strictly read-only recovery image like grml are typically
insignificant, so there is less need to save space by having
/ or the initramfs carry out the dual roles of normal boot and
abnormal recovery;
* because we have traditionally demanded that / contains everything
that might conceivably be necessary to mount anyone's /usr, it is
actually far from minimal:
- full networking, because someone's /usr could be NFS
- wpa_supplicant, because you could conceivably mount that NFS
directory over wifi or something, if you like juggling chainsaws
- disk encryption, because someone's /usr could be encrypted
- FUSE, because someone's /usr could be ZFS-on-Linux
- libdbus, because someone might be booting with Upstart
(or the older systemd versions that used libdbus)
- fsck.*, mkfs.* and (u)mount.* helpers for all filesystems,
even those that would make no sense for /usr, because the
/sbin/mount "API" says they must be in /sbin
- bits of Bluetooth support, for some reason that I don't understand
I personally think those factors undermine the "/ as recovery" use-case
so far that the advantages of a merged /usr far outweigh it. If you
disagree, then that's a reason to not install usrmerge (and consider a
mandatory merged /usr to be a bad idea, but making merged /usr mandatory
is not what's being proposed here).
S
Reply to: