Werner

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

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

vendor kernel has rknpu enabled by default. edge will receive initial support for it (called Rocket then) with 6.17 iirc.