Igor

Some context: https://docs.armbian.com/User-Guide_FAQ/#why-things-stop-working The hardest part and expensive for time is keeping functions working while kernel changes, goes up. Image you are referring too is probably a demo image with some ancient kernel that will never be changed. This is usual way to sell hardware. It is made to work, but you will stay at this very old SW stack without any real option to change or fix anything. All functions on 300+ boards, which on top of extreme diversity, have also different revisions, quality issue ... is already not possible to keep up by entire open source community. Armbian is small part focused into SBCs and we do what we can. Work we are doing is never complete, we (nobody) can't solve bugs and especially not near to (expected) real-time. We (or community open source in total) can address a problem within weeks or months fastest as resources are tiny compared to problems that are constantly found in open source code that somebody else made. We have no option to expand the team / project as users don't care about well being of SW developers. We can only try to keep SW stack operational on a best effort principle. Once this job becomes too expensive (<1% of costs share is on users side), we have to step back and declare support as "community". We will continue to build and ship images as they might still work for some use cases and as downstream projects will provide those Armbian images anyway.

Rpi support for whatever of their devices is mainly on the level of RaspberryPi OS. We use their kernels sources as base, add some additional things and release timing is different - not much difference. If they added new device, it should just work. If anyone wants to improve support or fix WiFi -> https://github.com/armbian/build/pulls

There is no way. You need a dedicated image for your hardware. https://docs.armbian.com/User-Guide_FAQ/

Test automation doesn't detect any issues https://github.com/armbian/configng/actions/runs/21465331853 and since I had freshly build Armbian Trixie on Nanopi R6S (same arch) I run install: Works like charm. Make sure to do apt update + apt upgrade before you start.

Did you used most up2date armbian-config? Few days ago some critical bugs were fixed - i tested it several times and it worked ...

Probably, my guess, issue with a boot loader - fail to / disabled by mistake power SATA port? We don't have anyone actively maintaining this kind of (10+years) hardware anymore. Support is "community / upstream" maintained "as is". But this forum / community can provide assistance to fix this. I gave a tip - where I think is the problem. Not working feature on particular hardware is not Armbian problem. This is custom hardware world and our work is tooling https://github.com/armbian/build and best effort hardware maintenance on this principle https://docs.armbian.com/User-Guide_Board-Support-Rules/ If we try to fix everything, everyone would be long burned out ...

Userspace has nothing to do with hardware features. I don't know what is the case for A20, but for many others, OTG functionality is driven with overlays. If there are no overlays, you need to edit device tree and change its role. If that doesn't help, it is more complex problem. More complex, perhaps days / weeks to debug and fix. Most of (Armbian) kernel developers are long gone from this 10+ years old platform and users can't help. Also look into previous builds. Finding out when this broke is half of the solution https://fi.mirror.armbian.de/oldarchive/ or by finding a kernel that works https://docs.armbian.com/User-Guide_Armbian-Config/System/#alternative-kernels With any userspace (trixie/noble/jammy ...) Probably all A10 and A20 boards share this problem.

Feature regressions are sadly something that happens all the time. There are many variants out there and (part of) Armbian OS is different for every board ... First resolve confusion - do you have M1 (we call it just bananapi) or M3. You mention M3 in the text, while title says M1+. Those are totally different boards. Proceed from older images and find out when this feature stopped working: https://fi.mirror.armbian.de/archive/ https://fi.mirror.armbian.de/oldarchive/

Ubuntu Noble variant already supports ZFS on 6.18.y while Trixie was added today: https://github.com/armbian/os/pull/425 Testing: Once automation completes, it will be provided via normal apt update.

Old automated builds are not kept. Only last three releases https://github.com/armbian/community/releases Its 300Gb / week

fixed

It is not recommended to match ZFS with vendor kernel(s). In general. Use mainline based current / edge kernels. Here v6.18.y we also might not have suitable ZFS yet as the kernel is too fresh. But if not today, it will be avail within days / weeks.

First testing on similar device (Odroid N2) didn't reveal any troubles. Need to locate VIM3 and try to recreate.

And others: https://docs.armbian.com/Mirrors/#current-mirrors

Sure, no worries. You will notice once its fixed. as this is not something you should adjust on the APT client side. You didn't and won't loose anything except current updating mechanism is broken.

I spent practically whole holidays to rework repository management and there are still some problems, even it was tested on and on before going into production. But beta repository, which you are having troubles with, was never tested. Only stable. Motive: https://github.com/armbian/build/pull/9150 Affected: https://github.com/armbian/armbian.github.io/blob/main/.github/workflows/infrastructure-repository-update.yml https://github.com/armbian/armbian.github.io/blob/main/.github/workflows/infrastructure-download-external.yml https://github.com/armbian/armbian.github.io/blob/main/scripts/sync-repository.sh https://github.com/armbian/armbian.github.io/blob/main/scripts/copy-kernel-packages.sh https://github.com/armbian/build/blob/main/tools/repository/extract-repo.sh https://github.com/armbian/build/blob/main/tools/repository/repo.sh ... so you might get an idea on the problem complexity

Current way of installing is as written on the download pages. It was verified with latest v24.11.2 image.

Yes, highly recommended in order to avoid troubles. We mainly use Noble and all of our build & test automation runs on Jammy / Noble. However, when using Docker, you should have more freedom.

Welcome! Strange. Works here without a problem: https://paste.armbian.com/uqutokajas

They are not empty. You need to go one level deeper: https://armbian.nardol.ovh/dl/tinkerboard/archive/ BTW, try https://github.com/armbian/imager It will be much easier.

I though some older images worked ... here you are on your own. Compare device tree from cubox and this hardware and repeate this on modern kernel, and apply difference. Just an idea. Sadly, no simple solution such as download and play.

If you need older images for cubox-i, archive and oldarchieve at https://fi.mirror.armbian.de/

You need this for m1s. As I said, those were hints / clues, not an actual how-to. Writing how-to takes more time then doing it

We only provide mainline based kernel, where video acceleration might not work. If you have a need for that, than use those hints: add DT here: https://github.com/armbian/linux-rockchip/blob/rk-6.1-rkr5.1/arch/arm64/boot/dts/rockchip/rk3568-odroid-m1.dts enable vendor kernel https://github.com/armbian/build/blob/main/config/boards/odroidm1s.csc#L7 build with ENABLE_EXTENSIONS="v4l2loopback-dkms,mesa-vpu" and desktop will work faster, video acceleration will most likely just work OOB.

This is custom hardware world and Armbian is a build framework 1st. It is not Debian vs. Armbian vs. Ubuntu. Debian, Ubuntu and other labels means something in mainstream x86 world while here they mean nothing, they are abused to generate sales. If you go for regular Debian, you will do 1-2-3 steps back and if you are lucky, one step forward - to accidentally load kernel where feature you need, works. If i2c stack wasn't properly ported to mainline kernel or if there is some other trouble that prevents this working in standard world, you can only run firmware that is provided by vendor. This is quite common and there you will have other problems. Problems you have are not simple to resolve or at least not in the "by the way" fashion. In order to help you - there are two ways and both are difficult - you are lucky and meet a person on this forum that knows rare technical specifics for this particular board from head or you meet someone that will invest few days to get down to this level ... People who are maintaining this place, don't have time to breathe and some are old too. It is impossible to focus into every problem that shows up as there is no capacity. And bugs are being re-introducted all the time. By everyone. In that case you would need to go for Intel mini PC. Custom hardware needs hard push sometimes to get something in order. I can assure you that Armbian works perfectly on Intel PC I use it for my desktop. Many of boards we present here would be paperweight long time ago.