<mgorny> it seems that udev-git is b0rked while tag '173' works fine for me
<mgorny> the rule in question is:
<mgorny> also, with >173 persistent-net rules seem to get constantly recreated
for same devices
<kay> mgorny: logic bug. we only sort the keys in an index, but we don't care
about the index when reading the list, which doesn't work too well for
the rules file list where we depend on the order
Most of the udev database from initramfs should be deleted before
starting udev in the real root. udevadm: info --cleanup-db deletes
all database entries in /run/udev. Events that processed IMPORT{db},
or mark devices explicitely as persistent, will be excluded.
Do not label any files in the udev runtime directory, but only nodes,
links and directories below /dev.
In case the runtime directory falls back to /dev/.udev, label this
directory once at udevd startup, but never anything below it.
Warning: noted but unhandled ioctl 0x641e with no size/direction hints
Syscall param socketcall.setsockopt(optval) points to uninitialised byte(s)
at 0x6A30BAA: setsockopt (syscall-template.S:82)
by 0x4E36E1C: udev_monitor_filter_update (libudev-monitor.c:347)
by 0x4E36ED8: udev_monitor_enable_receiving (libudev-monitor.c:373)
by 0x8A9E68E: I830ScreenInit (intel_driver.c:838)
by 0x42EE9E: AddScreen (dispatch.c:3890)
by 0x471561: InitOutput (xf86Init.c:738)
by 0x422C18: main (main.c:205)
Location 0x7ff0000c2 is 2 bytes inside local var "filter"
declared at libudev-monitor.c:256, in frame #1 of thread 1
Uninitialised value was created by a stack allocation
at 0x4E30860: ??? (in /lib64/libudev.so.0.10.0)
Thanks to Zdenek Kabelac.
We should bind the udev socket from systemd, so we are sure
that the abstract namespace socket is always bound by a root
process and there is never a window during an update where
an untrusted process can steal our socket.
Also split the udev.service file, so that the daemon can be
updated/restarted without triggering any coldplug events.
Kay Sievers
Nix