On 18/08/21 12:24 pm, Amish wrote:

Hello

Further to my previous email:

I see that there is already an *extremely similar issue* reported on July 12, 2021 and it has been fixed.

https://github.com/systemd/systemd/issues/20203

But I do not know if this fix exists in systemd v249.3 (Arch Linux)

If it exists that means that fix is breaking my system.
And if it does not exist that means, I can expect it to fix my issue.


systemd v249.4 seems to have fixed the issue. (Arch Linux)

Regards

Amish


Regards,

Amish.

On 18/08/21 11:42 am, Amish wrote:

Hello,

Thank you for your reply.

I can understand that there can be race.

*But when I check logs, there is no race happening*.

*Let us see and analyze the logs.*

Stage 1:
System boots, and kernel assigns eth0, eth1 and eth2 as interface names.

Aug 18 09:17:13 kk kernel: e1000e 0000:00:1f.6 eth0: (PCI Express:2.5GT/s:Width x1) e0:d5:5e:8d:7f:2f Aug 18 09:17:13 kk kernel: e1000e 0000:00:1f.6 eth0: Intel(R) PRO/1000 Network Connection Aug 18 09:17:13 kk kernel: e1000e 0000:00:1f.6 eth0: MAC: 13, PHY: 12, PBA No: FFFFFF-0FF Aug 18 09:17:13 kk kernel: 8139too 0000:04:00.0 eth1: RealTek RTL8139 at 0x000000000e8fc9bb, 00:e0:4d:05:ee:a2, IRQ 19 Aug 18 09:17:13 kk kernel: r8169 0000:02:00.0 eth2: RTL8168e/8111e, 50:3e:aa:05:2b:ca, XID 2c2, IRQ 129 Aug 18 09:17:13 kk kernel: r8169 0000:02:00.0 eth2: jumbo features [frames: 9194 bytes, tx checksumming: ko]

Stage 2:
Now udev rules are triggered and the interfaces are renamed to tmpeth0, tmpeth2 and tmpeth1.

Aug 18 09:17:13 kk kernel: 8139too 0000:04:00.0 tmpeth2: renamed from eth1
Aug 18 09:17:13 kk kernel: e1000e 0000:00:1f.6 tmpeth0: renamed from eth0
Aug 18 09:17:13 kk kernel: r8169 0000:02:00.0 tmpeth1: renamed from eth2

Stage 3:
Now my script is called and it renames interfaces to eth0, eth2 and eth1.

Aug 18 09:17:13 kk kernel: e1000e 0000:00:1f.6 eth0: renamed from tmpeth0
Aug 18 09:17:14 kk kernel: r8169 0000:02:00.0 eth1: renamed from tmpeth1
Aug 18 09:17:14 kk kernel: 8139too 0000:04:00.0 eth2: renamed from tmpeth2

Effectively original interface eth1 and eth2 are swapped. While eth0 remains eth0.

All these happened before systemd-networkd started and interface renaming was over by 9:17:14.

Stage 4:
Now systemd-networkd starts, 2 seconds after all interface have been assigned their final names.

Aug 18 09:17:16 kk systemd[1]: Starting Network Configuration...
Aug 18 09:17:17 kk systemd-networkd[426]: lo: Link UP
Aug 18 09:17:17 kk systemd-networkd[426]: lo: Gained carrier
Aug 18 09:17:17 kk systemd-networkd[426]: Enumeration completed
Aug 18 09:17:17 kk systemd[1]: Started Network Configuration.
Aug 18 09:17:17 kk systemd-networkd[426]: eth2: Interface name change detected, renamed to eth1. Aug 18 09:17:17 kk systemd-networkd[426]: Could not process link message: File exists
Aug 18 09:17:17 kk systemd-networkd[426]: eth1: Failed
Aug 18 09:17:17 kk systemd-networkd[426]: eth1: Interface name change detected, renamed to eth2. Aug 18 09:17:17 kk systemd-networkd[426]: eth1: Interface name change detected, renamed to tmpeth2. Aug 18 09:17:17 kk systemd-networkd[426]: eth0: Interface name change detected, renamed to tmpeth0. Aug 18 09:17:17 kk systemd-networkd[426]: eth2: Interface name change detected, renamed to tmpeth1. Aug 18 09:17:17 kk systemd-networkd[426]: tmpeth0: Interface name change detected, renamed to eth0. Aug 18 09:17:17 kk systemd-networkd[426]: tmpeth1: Interface name change detected, renamed to eth1. Aug 18 09:17:17 kk systemd-networkd[426]: tmpeth2: Interface name change detected, renamed to eth2.
Aug 18 09:17:17 kk systemd-networkd[426]: eth1: Link UP
Aug 18 09:17:17 kk systemd-networkd[426]: eth0: Link UP
Aug 18 09:17:20 kk systemd-networkd[426]: eth0: Gained carrier

This is when eth0 and eth1 interfaces are up and configured by systemd-networkd but eth2 is down and not configured.

*None of the .network configuration files match by interface names. They all match just by MAC address.

*# sample .network file.

[Match]
MACAddress=e0:d5:5e:8d:7f:2f
Type=ether

[Network]
IgnoreCarrierLoss=yes
LinkLocalAddressing=no
IPv6AcceptRA=no
ConfigureWithoutCarrier=true
Address=192.168.25.2/24
*
*

Above error message "eth1: failed", was not showing earlier version of systemd.

So recent version of systemd-networkd is doing something different and this is where something is going wrong.

Stage 5: (my workaround for this issue)
I wrote a new service file which restarts systemd-networkd after waiting for 10 seconds.

Aug 18 09:17:27 kk systemd[1]: Stopping Network Configuration...
Aug 18 09:17:27 kk systemd[1]: systemd-networkd.service: Deactivated successfully.
Aug 18 09:17:27 kk systemd[1]: Stopped Network Configuration.
Aug 18 09:17:27 kk systemd[1]: Starting Network Configuration...
Aug 18 09:17:27 kk systemd-networkd[579]: eth1: Link UP
Aug 18 09:17:27 kk systemd-networkd[579]: eth0: Link UP
Aug 18 09:17:27 kk systemd-networkd[579]: eth0: Gained carrier
Aug 18 09:17:27 kk systemd-networkd[579]: lo: Link UP
Aug 18 09:17:27 kk systemd-networkd[579]: lo: Gained carrier
Aug 18 09:17:27 kk systemd-networkd[579]: Enumeration completed
Aug 18 09:17:27 kk systemd[1]: Started Network Configuration.
Aug 18 09:17:27 kk systemd-networkd[579]: eth2: Link UP
Aug 18 09:17:27 kk systemd-networkd[579]: eth2: Gained carrier

All interfaces are now up and running as expected.

Please check as I do not believe that this issue is causing any race but to me it looks like some logical change in systemd-networkd which is causing the issue.

Thank you and regards,

Amish

Reply via email to