So here's a quick summary of what's happening to the best of my recollection; some details, especially the early days, may be slightly or even grossly inaccurate, but the gist is good enough, I think.
There have always been kernel modules that simply can't autoload based on hardware detection, e.g. the tun module. Early udev kept a static copy of those nodes in /lib/udev/devices/ and they copied over to /dev by udev itself - basically, all distributions had to do was make sure any needed nodes were there. For whatever reason, it was determined that this wasn't ideal (note that I'm not arguing that it IS ideal - I'd simply argue that it was good enough and easy enough to understand), and the number of those nodes had decreased over time anyway, so in recent times, this has happened:
Quote:
commit 07cd4fc16806783d3b6b3008db222ac6a024805c
Author: Kay Sievers <kay@vrfy.org>
Date: Sun Apr 8 16:50:16 2012 +0200
udev: remove support for /lib/udev/devices/; tmpfiles should be used
|
Quote:
commit 8c11aac1d739f5e60822f65f5179d8c4cc212732
Author: Tom Gundersen <teg@jklm.no>
Date: Thu Apr 11 21:14:40 2013 +0200
tmpfiles: create static device nodes before udev is started
Since v183, the contents of /usr/lib/udev/devices is no longer copied to /dev
on boot, rather systemd-tmpfiles should be used instead. However, as
systemd-tmpfiles --create is only ran long after udevd has been started, it is
no longer possible to use udev rules to assign permissions to the static nodes.
This calls systemd-tmpfiles --create early, before udev is started, and
restricts the call to /dev, which is known to be mounted already.
In the future, this could also take over the creation of static device nodes
from systemd-udevd.
|
Quote:
commit 27eceb2e4ecbf2e31940b67cee682a6935f61e6c
Author: Tom Gundersen <teg@jklm.no>
Date: Mon Oct 27 17:55:03 2014 +0100
static-nodes: indicate that creation of static nodes should only happen at boot
udev will only manage static nodes that exist at the time udev is started, so
creating static nodes later on will likely not behave as expected. In
particular, recreating the static nodes at run-time will reset any permissions
udev may have applied to the nodes at boot.
See <https://bugzilla.redhat.com/show_bug.cgi?id=1147248> and the discussion
following <http://permalink.gmane.org/gmane.comp.sysutils.systemd.devel/23795>.
Note that this requires (the yet to be released) systemd v217 or a backport
of systemd patch 8c94052ee543c3598a3c7b0c46688150aa2c6168.
|
kmod is nice enough to tell us what nodes should be statically created:
Code:
root@liberty:~# kmod static-nodes --format=devname
microcode cpu/microcode c10:184
autofs4 autofs c10:235
fuse fuse c10:229
cuse cuse c10:203
btrfs btrfs-control c10:234
loop loop-control c10:237
tun net/tun c10:200
ppp_generic ppp c108:0
uinput uinput c10:223
vfio vfio/vfio c10:196
hci_vhci vhci c10:137
uhid uhid c10:239
vhost_net vhost-net c10:238
snd_timer snd/timer c116:33
snd_seq snd/seq c116:1
but to create them the "right" way according to systemd's udev implementation, we need the tmpfiles (or something like) that binary from systemd. That's a bit of a problem, of course.
The current approach is to go back to copying contents of /lib/udev/devices/ into /dev - we just have to do it from our init script since udevd won't do it for us.
Given one of the git log messages above, it appears that we should do this *before* udevd is started, as udev doesn't know to manage any nodes that either weren't present when it was started or it didn't create itself.
The permissions problem isn't an issue with /dev/net/tun, but it very well could be with some of the others, so I'm curious about a couple of things:
1) Do we actually need the rest of those device nodes? In other words, has anyone found any issues with them NOT being present already?
2) Does moving the copying of the static nodes to before udevd starts in rc.udev work correctly or cause any undesirable side effects?
In my local tests, the answer to (2) is an unequivocal "yes, it works correctly and no problems occur" -- the device nodes are still present after udevd starts, they get correct permissions applied according to udev's rules files, and needed modules are loaded when the nodes are accessed, e.g. "touch /dev/ppp" results in "ppp_generic" module being loaded.
For anyone willing to take a (small) risk and test this, here are new
http://slackware.com/~rworkman/rc.udev and
http://slackware.com/~rworkman/udev-...devices.tar.gz. Figure out where to put them in the eudev SlackBuild directory structure, rebuild, and let us know. Alternatively, put the rc.udev in place of your rc.udev, and add the contents of the udev-fixed-devices.tar.gz tarball to the appropriate place on your system, and again, let us know.
