#2850 closed enhancement (fixed)
Udev-167
| Reported by: | Matthew Burgess | Owned by: | Matthew Burgess |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Book | Version: | SVN |
| Severity: | normal | Keywords: | |
| Cc: |
Description
New version. Release announcement at http://www.spinics.net/lists/hotplug/msg04736.html. The major change here is the move of the Udev database from /dev/.udev to a new root-level directory, /run. Rationale for that can be found at http://lwn.net/Articles/436012/. Note that this isn't a hard requirement yet, Udev will fallback to using /dev/.udev if /run isn't around.
Change History (6)
comment:1 by , 14 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:2 by , 14 years ago
comment:3 by , 14 years ago
I think "huge pain" is a little overkill. I've been mindful of FHS for a long time, specifically $remotefs (the current netfs script in BLFS) for /usr. I had never considered /var being a remote mount. A symlink in the rootfs /var/run => ../run should be sufficient for pid file handling as long as the /var partition also contains the same link and /var is not supported as a remote mount. A note should be added to the book for this case however. As far as sysklogd, it is not started until after sysinit anyway which is already after $localfs (our current mountfs script), and lock files would not be needed until after $localfs is started either. I think we are already covered with the exception of the /var/run symlink (and that too is probably not needed on most systems until after $localfs anyway).
comment:4 by , 14 years ago
I think it's a huge pain to redesign the init system to be fully dynamic, is what I was trying to say -- perhaps unsuccessfully. :-)
If udev removes the support for "settle" entirely (which I fully expect at some point in the future here, given their previous behavior), there will no longer be a way to handle /var or /usr on a separate partition (never mind a separate machine :-) ) without a fully-dynamic init that listens to udev as well. Our 100-line rc script will be impossible to make work.
(You'd need to have most of your init scripts depend on whatever mounts /usr, and most of the rest to depend on whatever mounts /var. Those two scripts will need to depend on the partition showing up, which depends on udev handling that uevent, which is why it needs to notify init.)
Of course, if we can still call settle ourselves, this isn't an issue. But I still think the mindset is scary. :-)
comment:5 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Fixed in r9498. Bruce has taken on the introduction of /run.
Bug in this version. If you pass --disable-extras to ./configure (as we do, since we don't have all the infrastructure in place yet to build gudev, udev-acl, or some of the other insanity in the extras/ tree), nothing under the extras/ tree gets built or installed. This is clearly not the intent of the --disable-extras flag (according to the help anyway).
Fix is here:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=9bb54267a1483e8f3b2de352c7be433f625e5606
which is a straight rollback, or just wait for -168.
(On a side note, messages like this one scare me, a *lot*. The particular change there isn't bad, since we don't run systemd, but the mindset is going to be painful for us in the future, unless we come up with a way to put together a fully dynamic init system to handle /var or /usr on a separate partition. Which is a huge pain. :-( )