NanoPi R76S - LAN ports switching on boot

[oxoocoffee]

Creating a bug report/issue

• [ x] I have searched the existing open and closed issues

Required Information

• DietPi version | cat /boot/dietpi/.version

G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=19
G_DIETPI_VERSION_RC=2
G_GITBRANCH='master'
G_GITOWNER='MichaIng'

• Distro version | echo $G_DISTRO_NAME $G_RASPBIAN

trixie

• Kernel version | uname -a

Linux nano 6.1.115-vendor-rk35xx #1 SMP Tue Nov  4 14:07:09 UTC 2025 aarch64 GNU/Linux

• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)

NanoPi R76S (aarch64) # 16G RAm and Wi-Fi add-on card

• Power supply used | (EG: 5V 1A RAVpower)

100W USB-C PD charger

• SD card used | (EG: SanDisk ultra)

SanDisk Extreme Black

Additional Information (if applicable)

• Software title | (EG: Nextcloud) Networking on boot
• Was the software title installed freshly or updated/migrated? Yes
• Can this issue be replicated on a fresh installation of DietPi? Yes

• Bug report ID | echo $G_HW_UUID

e5e16fdf-6783-47cd-bae7-b6aef2a8b38e

Steps to reproduce

1. Downloaded latest DietPi_NanoPiR76S-ARMv8-Trixie.img.xz and dd to SD card
2. Complete first time configuration.
3. Reboot sudo shutdown -h now

Expected behaviour

• Each time the unit is rebooted, eth0 is switched on boot between both 2.5G LAN ports
• This causes a stall on boot, since it is doing DHCP on wrong interface
• Each time the unit is rebooted, eth0 should locked to LAN port labeled and eth1 to port labeled WAN

Actual behaviour

• Each time you reboot the unit, eth0 seems to always flip flop between ports after each reboot. I did reboot about 10 times and so far this is 100%

Extra details

• Also noticed, if I do not switch the cable on reboot, and DHCP times out on boot, switching the cable to correct LAN port does not automatically reconnects and starts DHCP.
• Was there a separate package I need to install for auto enable?

73,

[MichaIng]

I'll try to replicate. I guess there is some randomness/race condition involved. Sadly there is no way to swap the kernel-assigned device names afterwards. One can assign names and aliases later, but their original name will remain internally and cannot be reused by another interface.

A workaround is to apply different names or aliases based on other hardware identifiers via udev rules, and use them in custom interface configs. I'll check a way later today.

We could try to artificially defer the loading of one of the two points, to enforce a fixed order/naming, but that is not exactly beautiful.

Ultimate solution is to implement support for custom network interface names to our tools, including systemd's "predictable interface names". But that is a larger rework, difficult to find time for.