Werner

moved

My guess is that there is no npu driver upstreamed yet. Try vendor kernel

moved

moved

Hi Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

If you run from sdcard, put it into an existing system and make necessary adjustments. Easiest would be to use another arm64 based computer since you can simply chroot into your sdcard and use armbian-config to switch back to stable.

moved to userspace

Try these: https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Orangepizero_bookworm_legacy_6.1.104_minimal.img.xz https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Orangepizero_bookworm_edge_6.12.9_minimal.img.xz

Hi Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Not for mainline. HDMI implementation is incomplete and still WIP. If you need other resolutions vendor kernel is the way to go for now.

Hi Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Did you check that the overlay has been added properly to /boot/armbianEnv.txt after using armbian-config? In some situations this fails for a reason still to be determined. Also make sure to apt update&upgrade beforehand since this tool gets patches frequently.

If this works from terminal but not from within armbian-config I suggest to report here: https://github.com/armbian/configng/issues

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