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