Werner

Forum moderatores are there to provide guidance in discussion and take action if things get out of control. Having a wide varity of knowledge in various areas is desireable but not mandatory. As for myself I did not know about that either.

moved to userspace

RPi added some checks in their initramfs post-update script which causes this, found here: /etc/initramfs/post-update.d/z50-raspi-firmware: case $flavour in v8|v8-rt|2712|v6|v7|v7l) ;; *) echo "ERROR: Unsupported initramfs version ($initrd_version)" exit 0 ;; esac However there is also another fine in this folder which was added years ago: https://github.com/armbian/build/pull/6039/files#diff-02b9b6fbb77fcab23278cd4a148b3f2c91d2c1361d05f33a21bdab19182caf21R139-R153 That seems to handle initramfs creation properly. So the error message is purely cosmetical. That would give trouble when updating rpi packages from upstream since there would be changes detected. Better solution might be to add a hint to our code stating that the ERROR can be ignored as long as overall initramfs generation was successful.

I explained above what zram is created for. OPi3LTS should have 2G of memory, so having 1G of zram makes perfect sense here.

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: