SteeMan

It depends on which repository you are pointing to. But in general if you are pointing to the stable repository (apt.armbian.com) then you would see releases as they flow out to the stable channel. If you are pointing to the nightly rolling release repository (beta.armbian.com) then you get nightly rolling release builds. (look at what repository you are using in /etc/apt/sources.list.d/armbian.list) The version you are reporting for armbian-config is a nightly version (25.2.-trunk is a rolling release).

multiboot means different things in different contexts. But in this context it is the process that is used for amlogic based tv boxes to get the native Android uboot on the emmc to boot armbian from SD card. The process is to press the reset button with the SD card inserted which causes the native uboot to look for a certain file on the SD card which is then read and adjusts the uboot environment so that future boots will first boot from the SD card.

Don't know, as I am fine with using the IP address so never researched further. I suspect it is a timing issue between DNS starting and wireguard starting.

This is likely the error you are running into. Is that your valid domain name for your wireguard server? I have had issues with wireguard starting before DNS name resolution is in place which I resolved by using IP addresses in the wireguard config files instead of domain names.

Have you tried what I suggested to you previously? https://forum.armbian.com/topic/27210-how-to-install-armbian-to-amlogic-s805-android-box/#findComment-163422

So according to your last comment you are using a custom dtb file. You do know that installing a new kernel version deletes the entire dtb directory and replaces it with what is shipped with that kernel version? So if you have a custom dtb it may be the issue that it is being removed during the upgrade. You need to put a custom dtb file in a location not under /boot/dtb. I don't know if this is your issue or not, but I thought of that based on the information in your last post. Another suggestion, is to put a current image on an SD card and see that that boots. That way you can determine if the issue is with the current code, or something that is happening during the apt upgrade.

All you should need to do is the standard debian process to apply updates regularly: apt update followed by: apt upgrade

I honestly have no idea if the mechanism behind that android command will work in the current aml-s9xx-box Community Armbian builds. I've never tested that method, nor have any familiarity with how it works.

Very common. I'd bet it is an S905L and the Android firmware is reporting false information. Happens all the time on cheap TV boxes. They will also falsely report the RAM and storage amounts falsely too.

This isn't in the installation instructions you referenced. Why are you trying to do this?

Moved post from Supported to Community Maintained and adjusted the tag to reflect the correct board

According to your armbianmonitor output you are not using Armbian but an Ophub build. Ophub is a fork of Armbian, they do not participate in Armbian development nor these forums. You need to direct your question to their forums/support.

Moved to community support section and added BPI M1 tag.

I think you have to go back to earlier in this thread where Igor stated: I think there is information you are not including about your setup. The first screenshot indicates you are/were running Buster as the screenshot says "Debian end of life (Buster)". Then later screenshots indicate you are running Bullseye. It looks like you have attempted to upgrade from Buster to Bullseye during this process. Armbian doesn't support userspace upgrades. An error in doing an upgrade like that would potentially leave your apt signing keys out of sync.