Werner

It is. We made the best possible support from it. Each new sdk version brings fixes but also regressions. Though you actially have to give credit to rockchip for their rk35xx sdk. We had way worse in the past, not necessarily from rk but others like aml or aw. In comparison its surprisingly good Anyway it will take another few years until it is close to feature-complete in mainline. I think rk3399 still hasn't all its features mainlined but overall it is well matured now. You always have to keep in mind that some smart person have to sit down and write drivers for sometimes poorly, sometimes not at all, documented features of a soc. Either being paid to do so or being an enthusiast where latter are very very rare people and their efforts are often strongly under-appreciated.

Yes there is some communication happening but this is out of scope for me. I do community Well thats unfortunate...and fortunate the same time. Let me explain real quick. rockchip socs have a built-in fixed boot order which is something like SPI, eMMC, microSD, USB and so on. However u-boot should be configured in a way, even though present on SPI or eMMC, it will check for an OS on microsd and try to boot that. tl;dr: Just write a fresh Armbian image on a microsd, put it into the ITX and power it on. It should boot from microsd. This system then can be used to fix your OS on the soldered eMMC.

moved wrong board. use orangepi5-pro if you want an image for orangepi5-pro. orangei5 will only boot on orangepi5.

Hi, first would be to set verbosity to 7 in order to get full boot logs. Excerpts are often useless. Further two things I'd do: For once I'd try to recover by chrooting into the system of the ITX by shoving the microsd into another arm64 machine (x86 can work too but it is far more annoying) and uninstall zfs package to see if this fixes the boot. If it is beyond recovery I'd try a fresh system from sd with a different userspace if the issue persists. Also just for the heck of it you could try this zfs package: https://github.com/zabbly/zfs I personnaly never tried this but it states to support arm64 so....just go for it Mainline is not an option for jellyfin, yes. It is far from being feature-complete while the rockchip sdk got most stuff working but, as correctly noticed, is fragile.

https://docs.armbian.com/Process_Contribute/ https://docs.armbian.com/User-Guide_Board-Support-Rules/

moved

short version: switch to vendor kernel. long version: mainline support for rk3588 is far from being feature-complete. Audio probably hasn't been mainlined yet. Check https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md If you need most things to work vendor is the way to go for now which is based on Rockchip SDK.

Just do "./compile.sh PREFER_DOCKER=no" and leave everything else to the interactive menu.

Took a quick look. Nothing obvious. Maybe kde noticed some broken package and sent a fixed version in the mean time? Hard to tell...

duplicate of https://github.com/armbian/configng/issues/360 ?

Cannot confirm. 217 package upgrades, reboot, works fine.

moved

This doesn't tell much. This below does Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed. Anyway DE is userspace. These packages come from KDE directly. If it worked before but broke after upgrade, there isn't much we can do since we don't control these packages. Since I have an opi5+ with KDE6 as well I'll try to upgrade later to see what happens.

merged

Ah alright. If this virt-manager creates a full-fledged vm with its own OS, own kernel and all the good stuff then it will work. You CAN use docker, but you don't have to. Cheers