MichaIng

No, just using a different kernel: We used the one from FriendlyELEC previously, now Armbian. But at least the two LAN ports on NanoPi R5S still have a random MAC,...

The MAC addesses should be at best set with whichever common logic the kernel uses, based on individual adapter, not set/overwritten by us, and definitely not hardcoded (which would break...

What I meant is that usually the MAC address is based on the individual adapters hardware attributes, not random and not based on another adapters attributes. It should be the...

Generally verify that there is `allow-hotplug eth0` or `allow-hotplug eth1` uncommented in `/etc/network/interfaces`. On first boot, we loop through all (detected) network adapters, enable them one by one and configure...

So I guess the network adapters are detected in inconsistent order and hence can have assigned different interface names each time. I'll try to replicate it and test some possible...

Jep, such udev rules solution is what we gonna do as well. But we'll use `eth0`/`eth1`, to remain compatible with `dietpi-config` and consistent. And we need to find another attribute...

I found a solution via udev rules, which does work. It was not so easy, since udev cannot swap device names via `NAME`. Both names `eth0` and `eth1` exist already...

A little update: ```sh cat /etc/udev/rules.d/99-dietpi-orangepi5plus.rules SUBSYSTEM=="net", KERNEL=="eth0", KERNELS=="0004:41:00.0", RUN:="/bin/true" SUBSYSTEM=="net", KERNEL=="eth1", KERNELS=="0003:31:00.0", NAME="to_eth0", RUN:="/bin/true" SUBSYSTEM=="net", KERNEL=="to_eth0", RUN="/bin/ip l s dev eth0 name eth1", RUN+="/bin/ip l s dev to_eth0 name...

> looks like the new udev rules happened after my net0/1 rules so the interfaces were recreated back to eth0/1 If they happen after yours, they would not apply anymore,...

Since it as generally solved, I'll close this issue. For particular issues or question regarding the udev rules, feel free to keep posting here or open a new issue.