Igor

Here, yes. Thank you! No, but we need to test images made for release. There is another last minute change https://github.com/armbian/build/commit/1890d7f6566a65202f73730b469d024c20f863b8 than can, in theory, make unbootable image. OK. Bugs will be present and we won't be fixing them at this stage. Here - if basic things works - that image boots, have connectivity and video output ... its ready to ship. All other things can be fixed with an update. If / when they are fixed.

What was already tested: UEFI x86 KDE Neon, Gnome, Ubuntu minimal MusePI Pro Xfce Odroid M1 KDE Neon Odroid N2 Xfce https://paste.armbian.com/oqegebaqey Orangepi 5 Nanopi M4V2 Odroid M2 Radxa E54 Rock 5C Orangepi 3LTS

We are opening public testing for upcoming Armbian images. The goal is to verify that the right images are built and that basic functionality works before boards are moved to the main download pages. You don’t need to be a developer. Simple testing and short reports are enough. 1. Download testing images Testing images are available here: https://fi.mirror.armbian.de/incoming/igorpecovnik/ Pick the image matching your board and choose desktop if applicable. Once image is confirmed working, the board will be: Moved to the main download pages Added to Armbian Imager 2. Check that expected images exist Before testing, please verify that: Your board is listed The expected image variants exist If an image (variant) seems to be missing: Check the release target definitions: https://github.com/armbian/armbian.github.io/tree/main/release-targets If the image should exist, check build logs to see if it failed: https://github.com/armbian/os/actions/runs/21642728389 If you are unsure, report it anyway. 3. Flash and boot Flash the image using Armbian Imager: https://imager.armbian.com Boot the board and check whether it reaches: Login prompt (CLI images) Desktop (Desktop images) If the board does not boot, serial output or photos help. 4. What to test Please focus on basic functionality: Boot reliability and reboot Networking (Ethernet, Wi-Fi, Bluetooth) Display and GPU, if applicable Installer and first-boot experience Advanced features can wait. Stability comes first. 5. UEFI ARM64 images If your board might support UEFI on ARM64, please test those images on them. Working UEFI images allow us to reuse targets and reduce the number of generated images. Reference: https://github.com/armbian/armbian.github.io/blob/main/release-targets/reusable.yml 6. Community-supported boards Some boards are currently released as community-supported: https://github.com/armbian/community/releases We want to promote suitable boards to standard support which brings more image variants and much faster download. This requires: Confirmation that basic functionality works Send a PR to change status from .csc to .conf A community member willing to step up as maintainer If you rely on such a board and want it promoted, this is the time to help. 7. Reporting (here in this topic!) When reporting test results, please include: Board model Image name and variant What works and what does not Logs or serial output if available Even short reports like “Board X, image Y, boots and networking works” are useful. Thanks to everyone helping with testing. Early feedback directly improves the release quality!

BTF is hungry for memory, yes. KERNEL_BTF=n and it needs less. On 16Gb+ machine you should be fine. If not memory is eaten away by something else.

https://github.com/armbian/os/pull/426 Once automation finishes - couple of hours, repo will have a missing package. Workaround: manually install package from https://packages.debian.org/forky/zfs-zed

Headers are present. https://imola.armbian.com/apt/pool/main/l/linux-headers-current-rockchip64/ Upgrade packages to latest and try again.

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