Not that I’ve noticed, but I only tested the WiFi as far as checking that I could connect to my own ESSIDs and reach the Internet.
I prefer wired networking, even with the annoying ports-switching.
Hey, only two issues (the ports switching and very rare hang on reboot) for an entire device… is fine by me, others have it much worse, like only having a measly 8GB RAM, forever. ;-D
I’m tracking the interface swap here: Orange Pi 5 Plus | Network interface names can swap on reboot · Issue #6592 · MichaIng/DietPi · GitHub
Thanks for the link, @MichaIng! Following that one too now.
It is so very unfortunate, because apart from that network ports-switching and the very rare hang on reboot, this is just about the perfect at-home and probably also small-business server for running many services on the same device (and probably other tasks too, but that is the one I got it for and use it for), but then it is plagued by this.
Once the ports-switching issue has been fixed somehow, it would be nice to be able to configure both of the physical ports in dietpi-config alongside the wifi, instead of as now just one physical port, but until the ports-switching is fixed I guess most people do (or should) use both ports as if they are the same in different ways (as seen also in that GitHub-issue) so configuring a second physical network port would probably have little real benefit as long as the issue persists.
Hi, I’m trying to get bluetooth working on my orange pi 5+. I’m not sure if this is the right place or if I should start a new thread but this is the only thread I’ve found so far that references the same wifi module that I installed (RTL8852BE). I’m happy to open a new thread though if this discussion should go elsewhere.
I installed the kernel so the result of uname -a now reads
Linux dietpi 6.1.43-vendor-rk35xx #1 SMP Sat Apr 27 18:12:21 UTC 2024 aarch64 GNU/Linux
I have bluetooth enabled in dietpi-config but when I run hcitool dev it doesn’t show any devices. Should the kernel update have fixed anything related to bluetooth?
Huh. When I enable Bluetooth in dietpi-config the resulting process ends with
Setting up bluez (5.66-1+deb12u1) ...
Created symlink /etc/systemd/system/dbus-org.bluez.service → /lib/systemd/system/bluetooth.service.
Created symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service → /lib/systemd/system/bluetooth.service.
Processing triggers for libc-bin (2.36-9+deb12u7) ...
Processing triggers for man-db (2.11.2-2) ...
Processing triggers for dbus (1.14.10-1~deb12u1) ...
[ OK ] DietPi-Set_hardware | APT install bluez
[ OK ] DietPi-Set_hardware | systemctl enable --now bluetooth
[FAILED] bluetooth enable | Exited with error
So I looked in dmesg and the related output there seems to be this:
[10716.405025] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[10716.405059] Bluetooth: BNEP filters: protocol multicast
[10716.405084] Bluetooth: BNEP socket layer initialized
[10717.258663] Bluetooth: RFCOMM TTY layer initialized
[10717.258684] Bluetooth: RFCOMM socket layer initialized
[10717.258704] Bluetooth: RFCOMM ver 1.11
[10717.272741] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[10717.272768] Bluetooth: HIDP socket layer initialized
[10717.289407] Bluetooth: HCI UART driver ver 2.3
[10717.289426] Bluetooth: HCI UART protocol H4 registered
[10717.289432] Bluetooth: HCI UART protocol BCSP registered
[10717.289438] Bluetooth: HCI UART protocol ATH3K registered
[10717.289520] Bluetooth: HCI UART protocol Three-wire (H5) registered
[10717.289879] Bluetooth: HCI UART protocol Intel registered
[10717.290117] Bluetooth: HCI UART protocol Broadcom registered
[10717.290160] Bluetooth: HCI UART protocol QCA registered
[10717.290166] Bluetooth: HCI UART protocol AG6XX registered
…but those are not errors, so I guess the error-message must have been sent elsewhere.
I hadn’t even tried using the Bluetooth until now, because I didn’t need to, so that was the behavior on a fresh first attempt.
You know what - I just disabled & re-enabled bluetooth and I’m seeing the same Exited with error but dietpi-config reports that bluetooth is “On” (though I guess this is just what it stored regardless of whether it was successfully enabled).
Yep, same here. Even after the “Exited with error”, dietpi-config claims that Bluetooth is “On”.
It should probably not do that in any cases of any non-success exit-codes.
Found and fixed the reason: v9.4 · MichaIng/DietPi@03b8282 · GitHub
However, it is visual only. The last successful command was the last to be applied. After that, a conditional was wrong, leading to a non-zero return code of the function. So [On] is correct as well.
@cchaz003 did Bluetooth work for you with the legacy 5.10.160 kernel? Else I suggest to open a new issue/topic.
Yes, this did happen on the previous kernel as well. I’ll open a new issue then.
Is there a good reason to revert the kernel back to 5.10.160? And where would I download that kernel package if I did? Thanks!
Not, unless the upgrade broke something for you. I aim to move all RK3588 boards to this kernel anyway, just waiting for one test on NanoPC T6.
Hmm, I tested the vendor kernel on my Orange Pi 5 Plus, and it causes in infinite udev reload loop with persistent 5% CPU usage, due to one HDMI related device: Orange Pi 5 Plus | Network interface names can swap on reboot · Issue #6592 · MichaIng/DietPi · GitHub
While debugging our udev rule which assures fixed Ethernet interface names, the systemd journal was regularly written full and rotated due to the udev log spam.
Do you (anyone) as well see a udev worker process in your htop which never settles?
Hmm, yes, after I tested to see that the new rules with reliable workaround for the wired ethernet ports switching was working fine through 25 reboots, with only 2 of the seemingly unrelated hang-on-reboot-exit thingies, I went to look at this too and in in htop I see one (udev-worker) and one /lib/systemd/systemd-udevd seemingly constantly chilling at 2-5% CPU. The (udev-worker) process ID in ps says it is [kworker/5:0+events].
This was while the machine had no other interactive use than htop/btop/ps.
Okay that one will be it. I’ll do some testing when I find time, e.g. whether having an HDMI screen attached to the related port helps, and which port it is. Maybe we can find some responsible node in the decice tree which causes it and at best some fix.
Comparing with Xunlong’s 6.1 sources and at best testing with a build of their unmodified sources makes sense. So in case we can report it at the Xunlong repo.
Hey, @MichaIng, now my Orange Pi 5+ got an update through APT making the kernel Linux [REDACTED] 5.10.160-legacy-rk35xx #1 SMP Wed May 15 03:04:45 UTC 2024 aarch64 GNU/Linux instead of this Linux [REDACTED] 6.1.43-vendor-rk35xx #1 SMP Sat Apr 27 18:12:21 UTC 2024 aarch64 GNU/Linux which we previously got working.
Remove the legacy kernel. Each kernel upgrade will apply the upgraded kernel as default. But check afterwards whether all symlinks are pointing to the vendor kernel, in case reconfigure it to assure that:
apt autopurge linux-{image,dtb}-legacy-rk35xx
ls -l /boot/{Image,dtb,uInitrd} # those should pointing to 6.1 versions
dpkg-reconfigure linux-{image,dtb}-vendor-rk35xx
ls -l /boot/{Image,dtb,uInitrd} # check again
Well, @MichaIng, that failed.
It seemed to go entirely to plan executing your suggested commands
# dpkg-reconfigure linux-{image,dtb}-vendor-rk35xx
Armbian 'linux-image-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'prerm' starting.
Armbian 'linux-image-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'prerm' finishing.
Armbian 'linux-image-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'preinst' starting.
Armbian 'linux-image-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'preinst' finishing.
Armbian 'linux-image-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'postinst' starting.
Removing obsolete initramfs images
update-initramfs: Generating /boot/initrd.img-6.1.43-vendor-rk35xx
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8402-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8105e-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for module r8169
update-initramfs: Converting to U-Boot format
Image Name: uInitrd
Created: Sun Jun 2 18:05:29 2024
Image Type: AArch64 Linux RAMDisk Image (gzip compressed)
Data Size: 8001123 Bytes = 7813.60 KiB = 7.63 MiB
Load Address: 00000000
Entry Point: 00000000
'/boot/uInitrd' -> 'uInitrd-6.1.43-vendor-rk35xx'
Armbian: update last-installed kernel symlink to 'Image'...
'/boot/Image' -> 'vmlinuz-6.1.43-vendor-rk35xx'
Armbian: Debian compat: linux-update-symlinks install 6.1.43-vendor-rk35xx boot/vmlinuz-6.1.43-vendor-rk35xx
Armbian 'linux-image-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'postinst' finishing.
Armbian 'linux-dtb-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'preinst' starting.
Armbian 'linux-dtb-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'preinst' finishing.
Armbian 'linux-dtb-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'postinst' starting.
Armbian: DTB: symlinking /boot/dtb to /boot/dtb-6.1.43-vendor-rk35xx...
'dtb' -> 'dtb-6.1.43-vendor-rk35xx'
Armbian 'linux-dtb-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'postinst' finishing.
and I checked as you suggested
# ls -l /boot/{Image,dtb,uInitrd}
lrwxrwxrwx 1 root root 24 Jun 2 18:05 /boot/dtb -> dtb-6.1.43-vendor-rk35xx
lrwxrwxrwx 1 root root 28 Jun 2 18:05 /boot/Image -> vmlinuz-6.1.43-vendor-rk35xx
lrwxrwxrwx 1 root root 28 Jun 2 18:05 /boot/uInitrd -> uInitrd-6.1.43-vendor-rk35xx
…but then when rebooting to use the kernel, the Orange Pi 5+ just… won’t boot from the NVMe anymore, instead just standing there with a constant red light on at the front but no green light indicating activity and the display remains blank while the (wired) keyboard lights are all lit up.
Booting an SD-card works fine and the DietPi install can be mounted from that.
Any suggestions? Right now, my OPi5+ is out of operation until we fix this. :-/
Hmm, can you check whether the three targets of the symlinks do actually exist? While testing something else on Odroid N2, after purging one kernel/dtb package there, the /boot/dtb-6.x.y directory of the other one was somehow missing. But since this is a test device with many back and forth installs, I was not sure whether there is a bug in the package maintainer scripts.
Hmm, it seems somehow the dtb-link was left without anything to point at.
root@orangepi5plus:~# ls -al /mnt/target/boot/
total 58292
drwxr-xr-x 4 root root 4096 Jun 3 00:28 .
drwxr-xr-x 18 root root 4096 May 14 02:27 ..
-rw-r--r-- 1 root root 2692 Feb 20 10:21 boot.cmd
-rw-r--r-- 1 root root 2764 Feb 20 10:25 boot.scr
-rw-r--r-- 1 root root 243278 May 20 21:52 config-6.1.43-vendor-rk35xx
drwxr-xr-x 4 root root 4096 May 14 06:24 dietpi
-rw-r--r-- 1 root root 292 May 1 04:58 dietpiEnv.txt
-rw-r--r-- 1 root root 18092 Feb 20 06:41 dietpi-LICENSE.txt
-rw-r--r-- 1 root root 16059 Feb 20 06:41 dietpi-README.md
-rw-r--r-- 1 root root 17519 Mar 18 20:46 dietpi.txt
lrwxrwxrwx 1 root root 24 Jun 3 00:28 dtb -> dtb-6.1.43-vendor-rk35xx
lrwxrwxrwx 1 root root 28 Jun 3 00:28 Image -> vmlinuz-6.1.43-vendor-rk35xx
-rw-r--r-- 1 root root 7439569 Jun 3 00:28 initrd.img-6.1.43-vendor-rk35xx
-rw-r--r-- 1 root root 0 Jun 3 00:28 .next
drwxr-xr-x 2 root root 4096 May 1 04:59 overlay-user
-rw-r--r-- 1 root root 6998291 May 20 21:52 System.map-6.1.43-vendor-rk35xx
lrwxrwxrwx 1 root root 28 Jun 3 00:28 uInitrd -> uInitrd-6.1.43-vendor-rk35xx
-rw-r--r-- 1 root root 7439633 Jun 3 00:28 uInitrd-6.1.43-vendor-rk35xx
-rw-r--r-- 1 root root 37468672 May 20 21:52 vmlinuz-6.1.43-vendor-rk35xx
For reference, before I started following the suggested commands I also listed all contents of /boot so I have that listing preserved and it looked like this before the upgrade (“la” is my alias for ‘/bin/ls -halF --color=force’:
# la /boot/
total 114M
drwxr-xr-x 6 root root 4.0K May 27 09:23 ./
drwxr-xr-x 18 root root 4.0K May 13 20:27 ../
-rw-r--r-- 1 root root 2.7K Feb 20 03:21 boot.cmd
-rw-r--r-- 1 root root 2.7K Feb 20 03:25 boot.scr
-rw-r--r-- 1 root root 218K May 15 09:21 config-5.10.160-legacy-rk35xx
-rw-r--r-- 1 root root 238K May 20 15:52 config-6.1.43-vendor-rk35xx
drwxr-xr-x 4 root root 4.0K May 14 00:24 dietpi/
-rw-r--r-- 1 root root 292 Apr 30 22:58 dietpiEnv.txt
-rw-r--r-- 1 root root 18K Feb 19 23:41 dietpi-LICENSE.txt
-rw-r--r-- 1 root root 16K Feb 19 23:41 dietpi-README.md
-rw-r--r-- 1 root root 18K Mar 18 13:46 dietpi.txt
lrwxrwxrwx 1 root root 26 May 27 09:23 dtb -> dtb-5.10.160-legacy-rk35xx/
drwxr-xr-x 3 root root 4.0K May 27 09:23 dtb-5.10.160-legacy-rk35xx/
drwxr-xr-x 3 root root 4.0K May 27 09:23 dtb-6.1.43-vendor-rk35xx/
lrwxrwxrwx 1 root root 30 May 27 09:23 Image -> vmlinuz-5.10.160-legacy-rk35xx
-rw-r--r-- 1 root root 7.2M May 27 09:23 initrd.img-5.10.160-legacy-rk35xx
-rw-r--r-- 1 root root 7.7M May 27 09:23 initrd.img-6.1.43-vendor-rk35xx
-rw-r--r-- 1 root root 0 May 27 09:23 .next
drwxr-xr-x 2 root root 4.0K Apr 30 22:59 overlay-user/
-rw-r--r-- 1 root root 7.7M May 15 09:21 System.map-5.10.160-legacy-rk35xx
-rw-r--r-- 1 root root 6.7M May 20 15:52 System.map-6.1.43-vendor-rk35xx
lrwxrwxrwx 1 root root 30 May 27 09:23 uInitrd -> uInitrd-5.10.160-legacy-rk35xx
-rw-r--r-- 1 root root 7.2M May 27 09:23 uInitrd-5.10.160-legacy-rk35xx
-rw-r--r-- 1 root root 7.7M May 27 09:23 uInitrd-6.1.43-vendor-rk35xx
-rw-r--r-- 1 root root 34M May 15 09:21 vmlinuz-5.10.160-legacy-rk35xx
-rw-r--r-- 1 root root 36M May 20 15:52 vmlinuz-6.1.43-vendor-rk35xx
Okay, so there is a bug in one of those maintainer scripts, so that device tree dirs from other kernel versions are purged. I’ll have a look into this.
You can recover the missing directory when mounting that broken rootfs:
apt download linux-dtb-vendor-rk35xx
dpkg-deb -x linux-dtb-vendor-rk35xx* dir
mv -v dir/boot/dtb-* /mnt/<mountpoint>/boot/
This should move the dtb-6.1.43-vendor-rk35xx directory in place, to give the symlink its missing target.
Yep, with that the OPi5+ happily rebooted and everything seems to be back as it was before this little adventure.
Thank you very much for your fast resolution to this issue. 
1 Like