Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
Systemd incompatible with mounted /usr
Posted Mar 4, 2011 12:43 UTC (Fri) by nix (subscriber, #2304)
/ 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
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
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.)
Posted Mar 4, 2011 15:02 UTC (Fri) by mezcalero (subscriber, #45103)
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.
Posted Mar 4, 2011 16:06 UTC (Fri) by nix (subscriber, #2304)
... 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.)
Posted Mar 21, 2011 17:29 UTC (Mon) by gvy (guest, #11981)
"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 :)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds