Werner

This device is community-maintained. Armbian core team does not monitor its status nor gets involved into development here. However anyone from the community can step up and send fixes. I saw some stuff upstreamed from time to time for 5 ultra and max, hit somewhere between 6.16 and 6.18 I guess. When rockchip64 gets bumped further they will be available for these boards. Since mainline is still under development though sticking with 6.1.y vendor kernel isn't a bad option since most things work here.

sources are defined per board family, in your case sunxi:https://github.com/armbian/build/blob/main/config/sources/families/include/sunxi_common.inc Before attempting u-boot for a whole family I suggest to do some small scale tests at board level first by setting an override in the board config file. Example for a different board:https://github.com/armbian/build/blob/a7c19f1e35a65daf42f090ecc34ee1151ee6db23/config/boards/orangepi5-plus.conf#L31-L52

If you mean an external directory within immich, then answering this is out of scope of the Armbian project. We provide a fairly easy way to install the software, but everything beyond is userspace. If you mean sharing a directory from the host into the docker container, then here you can check how armbian-config installed immich: https://github.com/armbian/configng/blob/37f091998d74b059c4302a91ca1f2c06a908297f/tools/modules/software/module_immich.sh#L16

If you build the module in question on the target machine, why do you use stuff like "ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-"? Doesn't make sense when building natively.

Outdated kernel. overlays were probably added later https://github.com/armbian/linux-rockchip/tree/rk-6.1-rkr5.1/arch/arm64/boot/dts/rockchip/overlay

Debug boot issues: https://debug.armbian.de

At some point we will bump edge to 6.17. These bumps always take time since our patchset on top always needs adjustments. There are 3rd party ppa's for newer mesa. I suggest to use kisak since those are briefly tested. Otherwise go for oibaf which are automated untested, therefore latest mesa packages. In terms of Debian, no clue if there is a similar apt repo for such.

If you used edge, revert to 6.15

There are two ways to achieve hw acceleration: backported panthor or mali blobs. Depending on your usecase latter might be necessary. You may find this interesting: https://jellyfin.org/docs/general/post-install/transcoding/hardware-acceleration/rockchip/#configure-on-linux-host Don't forget to disable panthor overlay in /boot/armbianEnv.txt if you decide to go this route.

https://github.com/armbian/build/pull/8447#issuecomment-3195333910

https://github.com/armbian/build/pull/8447#issuecomment-3195333910

Revert to 6.15. The 6.16 package is useful for A523 only atm. Don't use bleeding edge and complain about things breaking the same time. To answer on your level: Either help fixing things or fuck off and move along.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Yeah something is wrong. I had a similar issue for noble base-files package on a different mirror.

Maybe upstream regression. KDE is using upstream testing branch.

https://wiki.debian.org/LXQt

data corruption can always happen when there is a power outage. Could be by chance that one device suffered while the other didn't. Best way to prevent is as guessed a small PSU which ideally tells the device 'there is an outtage, please shut down before I run out of battery". Having OS or data or microSD, eMMC or NVMe does not make a difference since the OS decides when and how often data is written. NVMe are even more fragile since they often come with an internal cache themselves that is emptied onto the actual flash asynchronously. Disabling write caches may lower chances for data corruption but for once can decrease performance a lot and for the other significantly decreases the lifetime of microSD cards.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

You probably have to replace base-files package.

Depending on your location this might not be anything that can be fixed on Armbian side. If this happens on any mirror, the issue is either your setup or ISP blocking access.

Tried this way? https://docs.armbian.com/User-Guide_Autoconfig/

How to debug boot issues: https://debug.armbian.de

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Provide full logs