Hi, like said in bug 551644 comment #30 I have the problem that sometimes my NICs won't be renamed on boot. The problem first appeared with the recent changes to sys-fs/udev-init-script but that's not the root cause: I have a udev rule which will rename my NICs: $ cat /etc/udev/rules.d/80-net-setup-link.rules # Internal network SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:0a:e4:XX:XX:XX", NAME="internal0" # External network SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:0a:e4:ZZ:ZZ:ZZ", NAME="external0" This was working fine with sys-fs/udev-220-r1 and sys-fs/udev-init-scripts-27. With the new udev-init-scripts-29, sometimes my NICs aren't renamed on boot. Like written in bug 551644 comment #32 a "sleep 10" before calling "udevadm trigger --type=devices --action=add" helps but this only uncovers a race condition. So I bisected udev and found the bad commit (http://cgit.freedesktop.org/systemd/systemd/commit/?id=aeb24f3081ad4971a82d90a9dac4cbe8da3bb228): commit aeb24f3081ad4971a82d90a9dac4cbe8da3bb228 Author: Lennart Poettering <lennart@poettering.net> Date: Thu May 14 11:30:14 2015 +0200 util: use GNU comparison function prototype for qsort_safe() It wasn't easy to find because it is a race condition but I am very sure that's the bad commit: I build udev with the previous commit (7185d80558f7d85ddb67da0268a0f47138bf1401) and rebooted about 30 times without any problems (my NICs were always renamed). With the bad commit I rebooted 10 times and 3 times my NICs weren't renamed... Reproducible: Always
Well, seems like that aeb24f3081 was not the bad commit: I did the bisect on a physical system (FUJITSU PRIMERGY RX200 S8). In the meantime I have rebooted this system about 130 times with udev build from commit 7185d80558f7d85ddb67da0268a0f47138bf1401 (this is the previous commit before the "bad" commit) and it works. I never experienced a problem with 7185d805 to date. Rebooting the system with udev build from aeb24f3081ad4971a82d90a9dac4cbe8da3bb228 however fails sometimes (not on every boot, but sometimes). I tried to build sys-fs/udev-220-r1 with "git show -R aeb24f3081" applied but still saw failures. So yes, it is very unlikely that this is the bad commit. However I tried another physical system (HP DL120 Gen9). This system failed to boot 10 of 10 times with udev build from aeb24f3081ad4971a82d90a9dac4cbe8da3bb228 _and_ 7185d80558f7d85ddb67da0268a0f47138bf1401. So I started a new bisect using this system. New bad commit: commit ecb17862ad969cc15e94f95d0255b51ba3e588e1 Author: Tom Gundersen <teg@jklm.no> Date: Tue May 12 19:06:33 2015 +0200 udevd: manager - move a few global variables into the Manager object But I am unable to just undo this patch (too many changes; functions like event_queue_update were removed later...). But at least this commit looks more promising, not? Any idea how to proceed?
Same issues with renaming NICs... didnt do multiple boots to check if at least sometimes they get renamed properly, but reverted init scripts from ~28/29 to ~27 and issue is gone. So this issue started for me with udev-init-scripts-28. So atm i just masked it.
Still an issue with recent udev releases?
