Werner

Have you checked "mount" command to list actualy mounts? I am quite confident mount is happening by the ramlog service and is not integrated into fstab. some more background: sdcards have a limited amount of writes until its cells die. Since everytime some service or whatever writes some logs this issues a write event. To drastically increase the lifespan of the microsd log entries are buffered to (compressed) memory and then recurringly written all at once.

Good question. Have you tried to use binwalk oder strings on it? One is for ramlog and should be mounted to /var/log. The other is zram which by default is half of your actual memory. In the early days SBCs hat very limited memory, so using zram was a simple way to increase that by sacrificing some cpu resources. Nowadays SBCs come with a lot more memory and some may not even need zram anymore. Depending on your setup you can disable it as well. Check /etc/default/armbian-* files.

Customizing image and customizing kernel are different tasks. For latter use the code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } kernel-config command and then copy over the created config file from output to userpatches. The framework will look for custom kernel configuration files and uses them if they're detected. More details here: https://zuckerbude.org/armbian-using-kernel-config/

Easiest way is to use the customize-image.sh file in userpatches. Stuff there gets executed within chroot on the sdcard just before its closed and assembled. More advanced way is using extensions. Check extensions folder for examples.

You can either experiment with the CLEAN_LEVEL switch or use kernel-patch or uboot-patch (depending on what you want to modify) to create proper patch files from the diff.

I guess that is a bit misleading. As mentioned using armbian-config is optional to do certain tasks in a more comfortable way than manually/traditionally.

Yes. Installing this package on Debian-based build hosts fixed the issue. I don't think we have any developers using Arch so there aren't much tests of any other distros to ensure compatibility. Main focus is on Noble. If there is an equivalent package for arch try installing on the host machine and retry. Having it inside the docker container may not be enough.

Just to let you know. Rebasing our patchset on top of latest mainline is always a big effort, so getting the latest kernel may be delayed for weeks or month.

Um...no? Where did you get that info? Using armbian-config is totally optional. Everything this tool does can also be done manually.

I usually check here every couple of days: https://patchwork.kernel.org/project/linux-rockchip/list/ Yes, they will be included in edge kernel and in a year or two when the next LTS kernel hits they'll be included in current as well.

Not sure for what you need it but here: https://github.com/u-boot/u-boot tag specification and defined patch sources are here:

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.