I have noticed in the DietPi changelogs related to the closely related but significantly different Orange Pi 5/5B that “we moved to mainline Linux” (quoting latest Release v10.7 · MichaIng/DietPi · GitHub release’s changelog), so I was just wondering, you know… can and should the Orange Pi 5+ devices move too?
No rush or anything, but I’m wondering.
Also while I’m here, some positive feedback: My Orange Pi 5+ has been running flawless since the Linux kernel switch 2 years 3 months ago (https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/63?u=b9ace),
providing Jellyfin (for streaming my music collection to me while away from home), FreshRSS with FlareSolverr, Multi-Scrobbler, a Tor-project OBFS4-Bridge, Open WebUI, RSSHub, Caddy, Syncthing, Watchtower, and Cloudflare’s tunnel “cloudflared”, running in Docker Compose with the entire thing installed on M.2 NVMe (root filesystem on /dev/nvme0n1p1).
Very nice, thank you DietPi!
Orange Pi CM5, since mainline has a device tree for the base board, but not for the tablet base board, which is the one I have.
But we did not actively migrate RK3588 boards from vendor to mainline. To do so with the Orange Pi 5 Plus:
G_DIETPI-NOTIFY 2 'Migrating to "current" kernel branch with Linux 6.18'
board_id='orangepi5-plus'
packages=()
dpkg-query -s 'linux-headers-vendor-rk35xx' 2> /dev/null | grep -q '^Status: install ok installed$' && packages+=('linux-headers-current-rockchip64')
dpkg-query -s 'linux-libc-dev-vendor-rk35xx' 2> /dev/null | grep -q '^Status: install ok installed$' && packages+=('linux-libc-dev-current-rockchip64')
G_AGI linux-image-current-rockchip64 "${packages[@]}" "linux-u-boot-$board_id-current"
G_AGP linux-{image,dtb,headers,libc-dev}-vendor-rk35xx
# The /boot/dtb symlink has been found to be missing after kernel removal, despite a newer kernel being installed already. Assure it is present and correct.
[[ -d '/boot/dtb' ]] || G_EXEC_OUTPUT=1 G_EXEC dpkg-reconfigure -f noninteractive linux-image-current-rockchip64
G_EXEC_OUTPUT=1 G_EXEC /boot/dietpi/func/dietpi-set_hardware flash-u-boot-mmc
G_EXEC sed --follow-symlinks -i 's/ttyFIQ0/ttyS2/' /boot/dietpiEnv.txt
if systemctl -q is-enabled serial-getty@ttyFIQ0
then
G_EXEC_OUTPUT=1 G_EXEC /boot/dietpi/func/dietpi-set_hardware serialconsole disable ttyFIQ0
G_EXEC_OUTPUT=1 G_EXEC /boot/dietpi/func/dietpi-set_hardware serialconsole enable ttyS2
fi
This is kinda failsafe, considering that older package versions with split image and dtb packages, and such with an old bug (problematic behavior) in their postrm script could still be installed.
Oh, very good.
I did not know we should/could switch manually already. Did I miss some changelog? I am usually good about reading those to spot if I must/should do something at upgrades.
I ran the lines you suggested and then rebooted, after which running “uname -r” output “6.18.45-current-rockchip64”, so that’s that done.
Indeed, it was not mentioned in the changelog. I’ll inform about/offer this migration with next DietPi update. The change for new images was done with v10.5, hence it is/was good to have 1-2 release cycles of users testing it with new images. It is always better if an issue appears in a fresh instance, rather than breaking something with a migration on a production instance.
