nanopi r4s - LAN port works on initial boot, but not after auto-update and reboot

I’ve got a nanopi r4s here. When I first image the sd card with dietpi and boot it up, I get link on the LAN port, and I can ssh to it via the IP address it gets.

Immediately on logging in, it does an auto-update and that seems to include a new kernel. Then it reboots itself. At that point, I no longer have link on the LAN port, and can only use the WAN port. In the shell, it doesn’t even see the LAN port, via ‘ip a’ or ‘ifconfig -a’ or ‘lshw’.

Connecting via the WAN port, I installed a few firmware packages, which resulted in a new initramfs, then rebooted, which didn’t help at all.

Can I get both ethernet ports working? What sort of magic incantation might be necessary?

I’ve tried other linux distributions, and the few that I can get to boot will only activate the WAN port, even on the first boot.

I’ve tried to find a solution with google and even the search on this forum, and haven’t found anything.

I did the update steps to go to the 8.3.0 beta, and that didn’t help. It didn’t install a new kernel, which I suspect will probably be required.

root@legolas:~# ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast
        ether 54:10:ec:69:2a:04  txqueuelen 1000  (Ethernet)
        RX packets 715641  bytes 953306072 (909.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 94709  bytes 14613488 (13.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 31  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet  netmask
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 112  bytes 11216 (10.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 112  bytes 11216 (10.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I noticed that the -edge kernel variant was newer than what got installed by the auto-update (5.16.16), so I installed that. No change.

Just to avoid a missunderstanding. DietPi is not and will not do any kernel development. The kernel is the official one provided by the underlying OS/base image. In your case it might be Armbian. DietPi themselves is just a set of bash scripts and some configs + a little bit of automation.

I know that there are some issues with latest Armbian kernel but not sure if there is a relation to your system. Are you able to rollback to a previous kernel version?

pls can you have a look.

By mounting the image file, I was able to take a look at the changelog in /usr/share/doc/linux-image-cirrent-rockchip64 and see that the initial image is running kernel 5.10.63.

I did not see any options for a kernel package of that version, so I installed the only older kernel version I could find, the one with “-legacy” in the name, which is version 4.4.213. And to be sure that’s the one that booted, I uninstalled all the -current and -edge packages. The SD card no longer booted at that point.

After I reimaged the SD card and went through the whole auto-update sequence again, I did not see a way in dietpi-config to select the legacy kernel. I was able to determine that when it works on the 5.10.63 kernel, that it loads another NIC driver, r8169. I did notice that during the auto-update, it complains about firmware for that NIC being absent. Installing the armbian-firmware-full package fixes that error, but the LAN port still doesn’t work.

This may not be a question anyone here can answer, but why in the world did the nanopi designers opt to use two different NIC chipsets for the onboard ports?

usually this should downgrade the kernel. There is no direct option inside our configuration menu

apt install linux-dtb-current-rockchip64=21.08.2 linux-image-current-rockchip64=21.08.2
apt-mark hold linux-dtb-current-rockchip64 linux-image-current-rockchip64

I reinstalled with Armbian so I could seek help from that project. The kernel downgrade commands worked on Armbian, likely because DietPi at a low level basically is Armbian.

With that, the LAN became enp1s0 and the WAN became eth1. A little bit annoying. So I added “extrargs=net.ifnames=0 biosdevnames=0” to the boot environment. This gave me better interface names, but both ports had the same mac address. Removing biosdevnames=0 fixed that.

Thanks for your assistance. I’d like to file a bug for this problem … holding the kernel at an old version isn’t something that can last forever. I will miss out on bug fixes and improvements. Where exactly would be the best place to file a bug?

One thing to note – although the LAN port works perfectly, the link light never comes on. That’s the case for both the light on the port itself and the “LAN” led on the top of the box.

Basically it’s an Armbian kernel issue. Probably best place would be the Armbian forum.

Can you please show the:

cat /boot/armbianEnv.txt

If the “net.ifnames=0” is surrounded by double quotes, please remove those double quotes. I see those are indeed there with our current image, I’ll update it.

Path added for our next release:
But also patched our R4S image.

Downgrading the kernel packages worked. It also works on Armbian. They seem unwilling to accept a bug report, and’s bugzilla says that unless I’m compiling my own kernel, I’m probably in the wrong place, to file a bug with the distro.

I only have the one NanoPi available, so I can’t try another one to see if maybe there’s something wrong with the hardware. There do not seem to be a flood of reports of the LAN port not working on this specific hardware, so maybe this one is bad. But the fact that downgrading the kernel works is weird.

Have you tried what I suggested above? As of the false double quotation, AFAIK, with the new kernel the network interface names change, so that network fails on reboot.

elyograg@legolas:~$ cat /boot/armbianEnv.txt 

I am no longer using telling it not to change the interface name. I found that when I did that, which port got eth0 and which port got eth1 could change on reboot, which would mean it is not possible to script listening to the other port with tcpdump. Without the option, the LAN port is always enp1s0.