elyograg

The WAN port is back to eth0 now.

Today there was a new firmware package. After reboot, the LAN interface is gone again. A power cycle did not help.

In the last few months, some upgrades would break the port and others would fix it. One of the recent upgrades I made was to update to kernel 6.0 ... since then it looks like the LAN port has been there consistently. Curiously, the WAN port got renamed from eth0 to eth1 and that also seems to be consistent after every reboot. My netplan config does not have any network device names in it, so that name change doesn't break anything.

I upgraded my kernel again today and now the LAN port shows up in the OS. It works with both a cold boot and a warm reboot. elyograg@legolas:~$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 54:10:ec:69:2a:04 brd ff:ff:ff:ff:ff:ff inet 192.168.217.165/24 brd 192.168.217.255 scope global dynamic noprefixroute eth0 valid_lft 10776sec preferred_lft 10776sec inet6 fe80::e711:cec1:6580:b9c9/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: enp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether be:4f:ec:fc:14:a2 brd ff:ff:ff:ff:ff:ff elyograg@legolas:~$ uname -a Linux legolas 6.0.5-rockchip64 #22.08.8 SMP PREEMPT Fri Oct 28 15:15:06 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux elyograg@legolas:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.1 LTS Release: 22.04 Codename: jammy

I upgraded my kernel again today and now the LAN port shows up in the OS. It works with both a cold boot and a warm reboot. elyograg@legolas:~$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 54:10:ec:69:2a:04 brd ff:ff:ff:ff:ff:ff inet 192.168.217.165/24 brd 192.168.217.255 scope global dynamic noprefixroute eth0 valid_lft 10776sec preferred_lft 10776sec inet6 fe80::e711:cec1:6580:b9c9/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: enp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether be:4f:ec:fc:14:a2 brd ff:ff:ff:ff:ff:ff elyograg@legolas:~$ uname -a Linux legolas 6.0.5-rockchip64 #22.08.8 SMP PREEMPT Fri Oct 28 15:15:06 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux elyograg@legolas:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.1 LTS Release: 22.04 Codename: jammy

Update: I haven't had that port working for a while now. For a brief time after I installed the full firmware, it was working, and now it doesn't any more. Cold boot does not seem to help. I did a complete reinstall with the jammy build and it still doesn't work.

I was having a similar issue, but can't remember if I tried fully powering it down. I think I've always done the soft reboot. As I said in that topic, the new version of the armbian-firmware-full package seems to have fixed the problem. I did "reboot" via ssh. The kernel was not updated.

Today I updated packages. That update included armbian-firmware-full version 22.08.0-trunk.0038 ... on reboot, the LAN port now shows up as enp1s0 and the WAN port is still eth0. Problem solved.

None of the patches failed to apply to the 5.17.y branch, which REALLY surprised me. I thought for sure at least one of them would have failed. I do not have enough experience with kernel code to make any adjustments to the patches. I'm just guessing when I say that because they are designed for 5.16, they break the code for 5.17.

The build failed. Probably because the patchset for the kernel was intended be applied to a 5.16 kernel. not a 5.17 kernel. Would there be anyone here who knows how to modify the build to use a 5.17 or 5.18 kernel?

I am in the process of building an "edge" package set with the branch of kernel source pulled down changed from 5.16.y to 5.17.y, hoping that works. if it doesn't I can reinstall from scratch and downgrade the kernel again.

My takeaway from this is that there is a problem with the kernel, especially as I have seen it on multiple distros. I only went distro-hopping because I had a problem, and wanted to understand exactly where the problem is. I guess the remaining question is whether you will accept this as a bug report on Armbian, where your best kernel expert pursues it with kernel.org, or whether I need to be the one to take it to kernel.org. If this is not affecting all NanoPi R4S users, I will be surprised. That would most likely mean that I have a defective piece of hardware. As I only have one unit, I cannot make that determination. I've just created an account on bugzilla.kernel.org ... on the main page for that site, it says "If you did not compile your own kernel from scratch, you are probably in the wrong place." They prefer bugs filed with the distribution. Is there a guide for compiling your own kernel on Armbian? A *really* long time ago on ancient linux distributions, I compiled my own kernel. This was in the days when lilo was king and I had never heard of grub. I would compile virtually everything I needed for a specific machine into its kernel, not really using modules at all. Eventually the distribution-provided kernels got to the point where they were sufficiently optimized and would support virtually all hardware with zero problems, and so I stopped compiling my own kernels. Now, although I remember enough about *compiling* a custom kernel, I have almost no knowledge about how to *install* such a beast on a modern linux distribution. The best route might be to get the source package, customize that, and build a new package, then just let the package installer handle all the magic.

The DietPi folks gave me the following commands: apt -y --allow-downgrades install linux-dtb-current-rockchip64=21.08.2 linux-image-current-rockchip64=21.08.2 linux-headers-current-rockchip64=21.08.2 apt-mark hold linux-dtb-current-rockchip64 linux-image-current-rockchip64 linux-headers-current-rockchip64 This has gotten both ports working, but it isn't a good long-term solution. It means I'm going to miss out on bug fixes and improvements because I won't be able to update my kernel. Here are some system reports using armbianmonitor -u ... the first one is running a kernel where the LAN port doesn't work, the second one is running the older kernel where it does work: http://ix.io/3U37 http://ix.io/3U7o Can this post serve as a bug report, or do I need to make a post in another forum? I found another distro that works on the R4S - FriendlyWRT. This image has kernel 5.15.11. The LAN port does not work on this either. One other data point: Although the LAN port does work with kernel 5.10.63, the link light never illuminates. Neither the link light on the port nor the one on the top of the box is lit. If I plug into the WAN port, then that link light does work. Why would the nanopi designers use two different realtek LAN chipsets? Seems like the board would be a lot simpler if they used a single chipset managing two ports.

I started this journey with DietPi on a nanopi r4s. I asked about it on the DietPi forum, and they basically said "Our distro is a bunch of scripts on top of Armbian. We can't really help you with a kernel problem." So I reimaged with Armbian and I'm here now. Background with DietPi: When I first boot the DietPi image, the LAN port works. This is on kernel 5.10.63. Then as soon as I log into it via ssh on the IP address acquired by the LAN port, it proceeds to auto-upgrade software, including the kernel, which goes to 5.15.25. During the upgrade, I got messages saying a bunch of firmware for the r8169 driver was not there. Installing armbian-firmware-full gets rid of that error, but does not help. Once it reboots into the new kernel, the LAN port will not get link, and cannot even be seen by Linux. I cannot make it work no matter what I do. Some things I tried made the system unbootable. The WAN port does continue to work. So I grabbed the latest Armbian image for the r4s. When I boot that, the LAN port never works, but the WAN port works just fine. For what I am trying to do with the device, I need both ports working. I tried updating all the software on the system, including installing the -edge-rockchip64 linux packages. I just cannot make it work. Looking deeper into the dietpi initial boot with 5.10.63, I discovered that it loads the r8169 driver, but the newer versions don't.