Systemd incompatible with mounted /usr

Posted Mar 4, 2011 12:43 UTC (Fri) by nix (subscriber, #2304)
In reply to: Systemd incompatible with mounted /usr by jospoortvliet
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

What?

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.)

Systemd incompatible with mounted /usr

Posted Mar 4, 2011 15:02 UTC (Fri) by mezcalero (subscriber, #45103) [Link] (2 responses)

Well, I am not sure I can be more explicit than in the wiki page. But here's another try to explain this to you in simple words:

1) applications install udev rules

2) these are executed at early boot when the hw is detected

3) these rules fail, since /usr is not around

4) later on the apps won't see the devices properly, or can't see some of their features since the rules didn't get executed, and the udev devices lack the properties that should normally have been set had the rules been executed properly.

Systemd incompatible with mounted /usr

Posted Mar 4, 2011 16:06 UTC (Fri) by nix (subscriber, #2304) [Link]

Yep, that's exactly what I thought. All the applications which might fail because usr/ is not around are various udev extras, principally usb_db and pci_db. The default rules use these for something to do with Dell Bluetooth devices and to dig vendor descriptions out of the USB/PCI database. In fact, looking at the udev 164 source code, it looks like the stuff derived from the USB/PCI database lands in device properties then is never used for anything...

... ah. I see. PulseAudio uses it, nice example of an unadvertised coupling between programs, that. What does it use it for?

... to populate ZeroConf / Bonjour data, and to set vendor name properties on sources and sinks. Is that *all*? You're emitting a scary warning and triggering flamewars over *that*? Small wonder I never noticed it wasn't working. I hope you're planning to use it for something else in future, or this has really been a tempest in a teapot.

(I note that mapping USB/PCI IDs to vendors is something perfectly doable at runtime, when the system is likely to be up and /usr will be mounted: there's no need to do it at coldplug time. It's not like the USB or PCI databases are root-readable-only or anything like that, and the underlying IDs are stuck in the udev database regardless. However, it might require enhancements to libudev to do that, which is more coupling than the existing 'run usb_id/pci_id' approach.)

Systemd incompatible with mounted /usr

Posted Mar 21, 2011 17:29 UTC (Mon) by gvy (guest, #11981) [Link]

Here in ALT Linux, there's "early udev" in initramfs which is supplied with limited rules enough to bring up rootfs, and it's only used to populate initial /dev then stopped.

"Real" init can start proper udev with full blown rules later, and I can testify that *not* starting it -- or, again, starting to further populate /dev and then stopping it -- did make it possible for ALTSP5 thin client to fit into 16M RAM on a terminal (thus being useful).

Sure /usr is integral to / on a diskless thin client but hope that a use case like that might help to understand that there is awful lot more of uses for init(8) and udev(8) out there than can be imagined in a hurry.

As for initrd machinery, one is invited to have a look at http://en.altlinux.org/Make-initrd (original page in Russian at http://www.altlinux.org/Make-initrd).

PS: thanks for ifplugd :)