Systemd incompatible with mounted /usr
Posted Mar 4, 2011 12:43 UTC (Fri) by nix
In reply to: Systemd incompatible with mounted /usr
Parent article: Quotes of the week
I'm looking at that page and trying to figure out why anyone would want to run CUPS, PulseAudio, or gnome-color-manager when /usr wasn't mounted (i.e., in very early boot or emergency recovery mode). I can't think of a single reason :)
/ usually requires a similar amount of disk space as /usr does these days
Filesystem Size Used Avail Use% Mounted on
/dev/main/root 1008M 120M 838M 13% /
/dev/mapper/main-usr 197G 31G 157G 17% /usr
I suspect that this is only true if you have a massively modular kernel or half the world in /lib. It is most definitely comprehensively extremely not true for any system I have access to... other than Fedora and Ubuntu systems, and even for them, the relative space requirements are far from parity.
A look on a random Fedora 14 system shows 581Mb in /, more than half in kernel modules, and 4.26Gb on /usr. An eightfold difference, still pretty significant: a sixteenfold difference if it wasn't for the modular kernel.
harddisks are substantially bigger these days
Not all machines are personal desktops. (Assuming that all machines are desktops is a reasonable assumption for PulseAudio: it certainly is not for an init replacement). That Fedora install I just mentioned: its /usr would blow my firewall's total storage four times over. (It runs off an SD card. They are not large. Mind you, that's one machine where I didn't bother with a / versus /usr split: there was simply no point.)
It seems very odd to add this message to systemd if systemd is not at fault. If things exist on /, they shouldn't rely on things in /usr for some degree of function (sure, localization might break, but the program still works-in-emergencies without that.)
to post comments)