Werner

moved since neither a review nor a tutorial. I made a writeup just a few days ago how to get an idea about how Armbian puts its kernel and uboot sources together with an example for a different board:

Armbian does not accept new boards for official support unless there is funding involved. However anyone from the community can step up and add it as community-supported.

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

Very good. First make sure you are actually having the 5B and not the 5 model. The reason I'm asking is in the logs is always model 5 and not 5B as supposed to. Did you adjust the dtb to use 5b one just like mentioned at the download page?

Hm that should not be a BIG issue since H2+ and H3 are quite similar, just a few features were stripped IIRC. I don't know for their images but I assume there is something similar like Armbian has. Edit /boot/armbianEnv.txt and set verbosity to 7 to increase the output of the kernel while it is starting. So you may know why it is stuck. Overall I'd recommend to try some older images like https://fi.mirror.armbian.de/archive/nanopiduo/archive/ or https://fi.mirror.armbian.de/oldarchive/nanopiduo/archive/ and then bump kernel step by step via armbian-config to know where it starts failing.

There is usually only one or two images built per board. That's enough to make sure it compiles properly. All other combinations can be made DIY with the framework, check documentation. Continous Integration https://en.wikipedia.org/wiki/Continuous_integration

Our CI produces automated builds which are published here: https://github.com/armbian/community/releases If a build fails we will notice and fix if it doesn't much effort. Otherwise it's demoted to EOS and autobuilds disabled.

Yes, csc boards are not actively monitored. Build test only.

moved

Alright, let's give a real quick overview where the code for A20 comes from. Let's focus on current. First stop. Board config: https://github.com/armbian/build/blob/main/config/boards/bananapipro.csc -> BOARDFAMILY="sun7i" Next stop. Family config: https://github.com/armbian/build/blob/main/config/sources/families/sun7i.conf -> No sources defined. However there are includes. Next stop. Includes: https://github.com/armbian/build/blob/main/config/sources/families/include/sunxi_common.inc -> No kernel source URL defined. Therefore kernel comes from mainline (kernel.org to say). However a version is tagged: v6.12.43 So we know: Linux source comes from unmodified mainline and the version is 6.12.43 Next stop. Patches: https://github.com/armbian/build/tree/main/patch/kernel/archive/sunxi-6.12 -> vendor family = sunxi, kernel major.minor is 6.12 All these patches are applied on top of the kernel source from kernel.org. And yes, that's a lot. I think sunxi is the worst family regarding number of additional patches to make stuff work. Next component is u-boot. https://github.com/armbian/build/blob/main/config/sources/families/include/sunxi_common.inc -> BOOTBRANCH:-"tag:v2024.01" so uboot is tagged to this version. So we know: U-Boot source comes from unmodified mainline and the version is v2024.01. And BOOTPATCHDIR="${BOOTPATCHDIR:-"u-boot-sunxi"}" which means here we find the patchset put on top of that version. Let's check. https://github.com/armbian/build/tree/main/patch/u-boot/u-boot-sunxi -> folders starting with board_ are applied only if the target board is being built. All remaining paches are always applied. There are more definitions of stuff appling for multiple families, whole architectures or even all boards regardless of architecture but in this case they are not important. Just including for the sake of completion/information: https://github.com/armbian/build/blob/main/config/sources/armhf.conf https://github.com/armbian/build/blob/main/config/sources/common.conf Good luck.

What's wrong with just using the curl command? It will upload the logs to one of our paste servers and it will be nicely formatted and colorful. Way easier to read.

Excerpts are often useless. Provide full logs using the curl command from the end of each run. If the used hardware isn't very powerful, yes, can be.

Kobol went out of business years ago. I don't think you will be able to find replacement parts.

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.