[systemd-devel] Upgraded multiple systems to systemd 249.3 and all had eth1 not started / configured

Amish anon.amish at gmail.com
Mon Aug 16 12:01:54 UTC 2021


On 16/08/21 5:25 pm, Lennart Poettering wrote:
> On Mo, 16.08.21 16:09, Amish (anon.amish at gmail.com) wrote:
>
>> Some old scripts that we have expect interface names starting with eth. But
>> those names are not predictable.
>>
>> So to get predictable names starting with eth*, first I temporarily rename
>> all interface with tmpeth*. This is done via udev rules.
>>
>> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:XX",
>> NAME="tmpeth0"
>> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:YY",
>> NAME="tmpeth1"
>> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:ZZ",
>> NAME="tmpeth2"
>>
>> Then I have a small service (script) which runs before network-pre.target to
>> convert these names back to eth*
>>
>> #search for network interface with name starting from "tmpeth" and rename
>> them to "eth"
>> /usr/bin/find /sys/class/net -maxdepth 1 -name "tmpeth[0-9]" -type l -printf
>> "%f\n" | while read tmpiface; do /usr/bin/ip link set dev "$tmpiface" name
>> "$(echo $tmpiface | sed s/tmpeth/eth/)"; done
>>
>> This ensures that I have predictable names starting with eth*. And it is
>> working fine from 2-3 years. Even with current issue, name assignment is
>> working fine.
> This cannot work and is necesarily race. Stay out of the ethXYZ
> namespace, that's the kernel's namespace. Pick any other names,
> i.e. "foobar0", "foobar1", but otherwise you just have a racy racy
> mess, because the kernel might take the name whenever it pleases.

No I dont think this is race. Because my script runs after Udev has 
finished assigning the interfaces names.

Otherwise if kernel changes name again (back to eth*) after udev has 
finished renaming the device then persistent naming will never work.

Regards,

Amish.



More information about the systemd-devel mailing list