Nanopi R5S with nvme boot, network interfaces gone after installing full firmware package

[takigama]

Hi All,

Took me a bit of work, but i’ve gotten the nanopi r5s booting form nvme.

But, after it was all working, i needed to get a firmware for a bluetooth usb adapter which was buried away in the “armbian-firmware-full” package. Installing it worked just fine until I rebooted and then network interfaces stopped working entirely (no longer coming up on boot, hard to tell for sure but according to the log of the boot i dont believe the interfaces even made an appearence).

What i’ve done to get back is boot off SD card with the same diet pi version, grab the /lib/firmware directory from the SD card’s rootfs then copy into the nvme root. Worked ok, but now i have a bit of a /lib/firmware directory that is no longer pure.

What I cant seem to figure out though is what firmware is causing me issues. The interfaces are RTL8125’s and the firmware for both is the same on the old a new directories:

root@r5c:~/firm# md5sum ./old/rtl_nic/rtl8125b-2.fw ./new/rtl_nic/rtl8125b-2.fw
3bd3db7cf923ea77932d6f348f752d46  ./old/rtl_nic/rtl8125b-2.fw
3bd3db7cf923ea77932d6f348f752d46  ./new/rtl_nic/rtl8125b-2.fw

Im on the most current version thats on the download site currently and it comes up as:

cat /boot/dietpi/.version 
G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=4
G_DIETPI_VERSION_RC=2
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
G_LIVE_PATCH_STATUS[0]='not applicable'

In truth it would probably be easier for me to rollback to the original version that was in the r5s’s installed image and then just add the BT adapter firmware but i hate doing things in the system directories outside of the packaged versions.

Any suggestions how to figure out which firmware is actually the culprit?

[Joulinar]

maybe @MichaIng could have a look

[MichaIng]

I guess the firmware is unrelated, but the recent kernel upgrade is causing this. See: NanoPi R5S | eth0 not configured on reboot · Issue #6951 · MichaIng/DietPi · GitHub
I guess your symptoms are the same, interfaces listed in ip a, but not configured with IP address? Probably long boot times, and sometimes CPU governor missing as well (see with cpu command)? Also compare the several service logs.

If your symptoms are not entirely different, please test the following:

mv /etc/udev/rules.d/dietpi-eth-leds.rules{,_bak}
reboot

If it works, please reboot multiple times to verify it works consistently, since the issue seems to be some kind of race condition. However, since also the CPU governor is missing in some cases, I think out udev rules being involved is a symptom, not the reason for the issue.

Next, try to downgrade the kernel:

apt install linux-{image,dtb}-current-rockchip64=24.2.1
reboot

If this helps, as well across multiple reboots, you can set them on hold, and may to enable the Ethernet LEDs again:

apt-mark hold linux-{image,dtb}-current-rockchip64
mv /etc/udev/rules.d/dietpi-eth-leds.rules{_bak,}

And if you find time, would be great if you could test as well, whether all works fine when you boot from SD card. This is true in my and cxgth’s case. I can hopefully test with eMMC later tonight.

---

About the Bluetooth firmware. I remember another such case. With WiFi/BT adapter is it in particular? If it is the same, I’ll try to patch our Armbian fork to have it included in the non-full armbian-firmware package.

[takigama]

Yes, i did stumble onto that one as well and i believe i applied what it was suggesting was the changes to make (same ones you’ve suggested i believe), Though Im not sure I ever had the issue in the first place because it seemed like it always booted successfully (though the leds weren’t correct was one thing i noticed). i didnt start having issues until I was trying to use the bluetooth dongle in it. Not sure if it matters but the only changes i made during the setup was to change from dropbear ssh to openssh and add docker.

It might explain the initial problems i had getting it booting from nvme, took some effort to get anything booting off nvme, then with dietpi i seemed to not have any issues with the SDCARD but randomally starting working from the nvme and I wasnt sure why or what I had done to make it work.

Just fyi, this is the firmware thats in the full-firmware package thats not in the base that the dongle itself needs:

root@dockerhost:~/firm# find /lib/firmware -name '*rtl8761bu*'
/lib/firmware/rtl_bt/rtl8761bu_config.bin
/lib/firmware/rtl_bt/rtl8761bu_fw.bin

it does seem to be pretty consistent though. I have three directories at the moment, one with armbian-full, one with armbian and one thats ambian-full with an overlay of armbian. When i put armbian-full in, the device fails to boot but the other two boot without issue.

I did also add an rc.local so i could capture some stuff on startup with a bit of a delay.

Im going to re-image it though cause im not 100% sure of everything i’ve done to it anymore and see if I can reproduce it again.

[MichaIng]

This seems to work around the issues implied with slot Ethernet adapter detection and likely also fixes the wrong Ethernet LEDs:

G_CONFIG_INJECT '\[Unit\]' '[Unit]' /etc/systemd/system/ifupdown-pre.service.d/dietpi.conf
G_CONFIG_INJECT 'Before=' 'Before=network-pre.target' /etc/systemd/system/ifupdown-pre.service.d/dietpi.conf '\[Unit\]'
G_CONFIG_INJECT 'Wants=' 'Wants=network-pre.target' /etc/systemd/system/ifupdown-pre.service.d/dietpi.conf '\[Unit\]'
reboot

Will be also included in next DietPi update.

However, why boot/Ethernet adapter detection does take so lang in your cases, is still unclear, and why it only happens when booting from NVMe or eMMC, but not when booting from SD card.

@takigama

i didnt start having issues until I was trying to use the bluetooth dongle in it.

You mean, booting from NVMe was stable when not using the Bluetooth adapter? Probably it was not the full-firmware, but just the fact that the adapter was attached?