Igor

Without maintaining, those boards (upgrades) simply stop working. This is one of the ways how it manifests. Features starts to break apart and we have to spent insane amount of time trying to keep this herd operational. Every board has its own caveats. And here we also have OS release upgrade - deprecated OS. There are enough of troubles without that. Start with a new image and see if it works. Upgrade from Bullseye to Bookworm is problematic and I advise you to not deal with that if you are not experienced.

What is wrong with Armbian in production? Where you anyway have to work with kernel / firmware under your control. We have several cases. But yeah, hardware support wise, one needs to be careful what to choose. Here OS is irrelevant anyway. You are welcome (to join). If you go that route, remember that it is usually a lonely one and sharing here gives some companionship. Forum can provide some tech but mainly moral support, share some tips and ideas, but expect that nobody have much time to do the homework instead of you - answering "why this doesn't work", "how to fix this and that feature", ... Most of those questions require research - some are already answered but not integrated, so forum search is probably best 1st step. AI is also getting better every day and can help in some cases ... If you convert some popular unsupported board into supported (within Armbian), we can help more. Working with them made us bigger financial loss and worse software support. Most of what they provide SW wise is what they get from Allwinner (SDK) + board level adjustment or they steal (our framework) or push their buyers to milk open source projects. We suffered biggest loss and some had to close their projects down to this negative impact. They also re-brand-port our work into "Orangepi OS Debian / Ubuntu" and "Orangepi Arch OS" with help of Manjaro, which is yet another dirty FOSS player. They also produce fake Kali, fake Armbian and other fake images by themselves. To make sales and leverage support costs to others, mainly to us. We will keep supporting some old boards for end users, but we won't be touching any new HW from them. Association between brands and articles from years ago exists and still makes us damages. They will keep sucking from Armbian without contributing a single cent. They are directly stealing from our work and this is their business model and there is little we can do about except informing you. They always could make a donation, like everyone else, but they never found that button. tl;dr; Fake.

Yes, you need to install matching kernel and headers, otherwise it won't work. Remove CURRENT kernels by hand, install LEGACY and then proceed with headers installation. This will work.

This is custom hardware world, not general purpose Linux. There are 15 x Bananapi https://www.armbian.com/download/?tx_maker=sinovoip and every device has its own firmware. There are similarities, sure, which help, but if one boots and works fine, perhaps others won't. We keep images for those too, as some still might work. Trunk = development branch, changes daily. There was never ever support for that. This is for developers and experienced users, which are able to fix the problems as such. And even when "standard support" is declared, when whole SW stack is stabilized to some degree, it means "high level of software maturity" and you are welcome to share your frustration with everyone. Nobody can provide warranty on software support where users contribute less then 0.5% of costs for making it usable. In general. For specific - you need to share all data and logs, and then maybe someone will have a clue on what is happening here.

Moved to Allwinner section as this is not an user space problem. Percentage of breakage on not supported and (also not supported) trunk / untested / nightly build is very high. What you experience, under those circumstances, it is normal and expected.

Is a raw material from which we are developing / keeping support. It takes thousands of hours annually on top of that - for Allwinner hw to keep in a good shape. Use Armbian kernel and tell your customer to make a donation and your job is done - unless you are here to improve Allwinner support withing Armbian, Armbian itself? If you need Arch - it is probably easier to implement Arch to the build framework (not sure if it makes sense), then what you are aiming at. We are generating a loss by keeping those cheap boards usable - and we expect from you to at least not make the loss bigger - asking questions for 3rd party benefits is a path to this direction. Allwinner, Orangepi, ... are already making us enough of damages by doing nothing else but selling their cheap stuff - and not supporting any of our work. Similar to your customer, just at significantly bigger scale. Perhaps this is one of the reasons why things are as they are?

Probably. This can be solved by adding an overlay, so user can enable this at will, manually or via armbian-config. armbian-config lives in its own repository. Always make sure your packages are up2date / latest. Or at least armbian-config.

https://netcup-03.armbian.com/apt/pool/main/l/linux-headers-legacy-bcm2711/ Try with: sudo apt install linux-headers-legacy-bcm2711

Until only you, me and those few people that will read this thread knows about this .... doesn't make any sense. Our current download logic and UX is very bad at this state, almost as bad as Debian It is very difficult to know that such image exists, what are their advantages (this part I have some draft and will be sent to the docs eventually), then telling them that they can choose between .xz .qcow2 .xz.qcow2 ... while ISO (what people understand) is nowhere to be found. Enabling a feature at build framework. This is trivial and I think it's even supported with a switch already "KEEP_UNCOMPRESSED_IMAGE" or similar, but its not supported at CDN. When compressed qcow2 was replaced with uncompressed, redirection followed as it doesn't carry file extensions https://dl.armbian.com/uefi-arm64/Noble_cloud_minimal-qcow2 which means we don't have support for .xz at this moment. Changing this? Chain of command and execution is slow, I can't deal with everything, and people are busy. I still wait that https://dl.armbian.com/uefi-arm64/Noble_cloud_minimal-hyperv.zip (HyperV Azure) started to work. As you can see, compressed is even bigger then qcow2 image and apparently it has to be zip (don't know that yet). Once re-director is extended, now hard coded values goes out of the code, so its small refactoring - easier job for the future. When re-director is fixed, we need to adjust (already messy) web page. Which is now half broken, those cloud images are mixed with minimal / IOT. You don't know until you click on the link. That cloud kernel supports features required to run Docker. Something like this: curl https://raw.githubusercontent.com/docker/docker/master/contrib/check-config.sh | bash Already have some draft ready, but wanted to do more tests before. On some clouds.

Understand. But I also just prove you that it works on Armbian perfectly. Problem is with this TV box device. (probably / hopefully "just" wrong DT settings) The reason that it works on Alex / random OS is randomness, pure luck and just to understand why, someone needs to sponsor (!) days to weeks of his time. Armbian provides you build framework, we maintain and supports this community and many of those device, but there are simply too many of them. Those are resources that will help, we can provide hints and tips, but fixing this "small problem" is up to the one that sold you this device (never) and general Linux community, not necessarily Armbian community, and certainly not Armbian OS maintainers. Once you fix this problem, someone needs to keep those features working on firmware upgrade ... so you have some idea on the scale of operation.

Yes. Cloud providers, those that accept direct qcow2 images loading, expect uncompressed variant. It is handy if you can just pass URL or upload image without any additional handling. This should address the problem. https://github.com/armbian/build/pull/8046

Copy / paste / automation ... but joke on a side, robots & AI tools are helpful in the process, but saying thanks to them probably not make much sense.

This is a report from our automated testing. This device works well with generic kernel withing VM. Lets say a proof that a driver itself is O.K. Ah, I see, you don't see results:

If you boot with this plugged in? AR9271 is one of the most stable things on USB, but USB hardware / sw stack on weird tv boxes can vary. We are also having it in the auto performance testing case: https://github.com/armbian/armbian.github.io/actions/runs/14167367586

Thank you for letting us know! Hardware troubles of this board are unrelated to HA deployment. If you install this to not supported device, its on you to deal with HW level bugs. You can try engaging here https://forum.armbian.com/forum/173-allwinner-sunxi/ or contact the one that sold you this device. tl;dr; I suggest you to run it from a quality SD card. I also do.

This should happen automatically, but takes a day. https://github.com/armbian/os/blob/main/external/zfs-jammy.conf#L9 B -> beta repo S -> stable repo

Confirmed, many thanks for reporting. 6.12.y has troubles with one of the NICs, but as regressions at major kernel upgrades are totally normal and expected in embedded Linux, we are providing you this: https://docs.armbian.com/User-Guide_Armbian-Config/System/#install-alternative-kernels Use older kernels: Make sure you update armbian-config package before doing that, then proceed with "Disable Armbian upgrades" https://docs.armbian.com/User-Guide_Armbian-Config/System/#enable-armbian-firmware-upgrades It was moved to armbian-config -> system -> updates Verify in CLI: igorp@rockpi-e:~$ sudo apt-mark showhold linux-dtb-current-rockchip64 linux-image-current-rockchip64

Its probably a "feature" of new kernel version that broke some mechanism. Kernel 6.12.y is packed well so its something in the middle, corner case. I also don't know more then you.

This is expected and totally normal behavior we are seeing constantly. Without maintenance, support breaks apart. This is just the way it is. You can believe or understand. All the time. And we can't afford to invest more if we already generate huge loss. Not a single vendor ever helped around old devices. While we don't have the millions needed for keeping devices in perfect state, we still invest hundreds of thousands each year to keep these devices running on at 'best effort' basis. Understandably, end users often - always expect military-grade software quality, even though they contribute nothing financially and refer back to hardware dealers for support. Their support is cosmetic, some even fake that support (there are few companies stealing from us, while bragging how they invested into open source). It is their word against ours and it seems users believe dealers, which are always sweet and nice, more ... Loss of the time is always a lot bigger what people can afford, so many people got broke, suffer mental breakdown when helping you (and HW dealers). Lack of your support / compensation is a fundamental problem. Numbers and name suggests lack of polishing and stability, but you expect that things works perfectly? I don't know how to describe you this in tl;dr; - this doesn't work this way. We have Linux kernel, general stuff, which is maintained by general Linux community. Then there is this device family, this device itself (here sadly even several badly compatible revisions). If nobody is dealing with it in general Linux community, which is usually the case, it often breaks at this level before anyone at Armbian even touches it. Then we apply family patch-set on top of this source. Patches often needs adjustments, but luckily they are usually trivial. Still, this takes time. A lot of. We usually don't fix devices at EDGE kernels. This mainly happens when its time to switch kernel at CURRENT (stable / LTS) branch. In 25.2 we switched from 6.6 -> 6.12. For that, our focus for half a year (!) were to 6.12 which was EDGE at that time. Stabilization of mainline kernel with functional addon is our major loss of time. And when it gets down to devices specifics, we are just more limited - we can't test all devices (+ all revisions = impossible) and we can't fix all of them. Recording a bug / known issue is already a luxury. And there is 99% our private time that is lost. Most of end users demands feels very insulting as you have no idea who pays the bills. You don't as also most of vendors don't want to hear about those troubles. Since you don't support developers, people who you think to support you but they don't support you, support at least people which job is to listen to you and collect info for developers. From the loss those people generate, they can't support them better. But you can.

We developed so called Cloud images, which are a combination of minimal images + kernel with minimal set of drivers. Images also doesn't have any firmware packages, so bare OS comes down to 700Mb. Build from sources: ./compile.sh \ BETA=no \ BOARD=uefi-x86 \ BRANCH=cloud \ BUILD_DESKTOP=no \ BUILD_MINIMAL=yes \ ENABLE_EXTENSIONS=image-output-qcow2 \ IMAGE_VERSION=25.2.3 \ RELEASE=noble \ VENDOR="Company" \ VENDORCOLOR="5;100;115" \ KERNEL_CONFIGURE=no \ KERNEL_BTF=yes Customization: https://docs.armbian.com/Developer-Guide_Overview/ Details in promo style: Images were developed and tested in Qemu / KVM, but they should work (well) on all cloud platform. I need some help for testing those images, on any cloud that you can. It should also boot bare metal, but kernel is stripped down and many things won't work. Kernel configs: https://github.com/armbian/build/blob/main/config/kernel/linux-uefi-arm64-cloud.config https://github.com/armbian/build/blob/main/config/kernel/linux-uefi-x86-cloud.config x86 images: https://netcup-01.armbian.com/dl/uefi-x86/archive/Armbian_25.2.3_Uefi-x86_bookworm_cloud_6.12.20_minimal.img.qcow2 https://netcup-01.armbian.com/dl/uefi-x86/archive/Armbian_25.2.3_Uefi-x86_bookworm_cloud_6.12.21_minimal.hyperv.zip (Azure format) arm64 images: https://netcup-01.armbian.com/dl/uefi-arm64/archive/Armbian_25.2.3_Uefi-arm64_bookworm_cloud_6.12.20_minimal.img.qcow2 https://netcup-01.armbian.com/dl/uefi-arm64/archive/Armbian_25.2.3_Uefi-arm64_bookworm_cloud_6.12.21_minimal.hyperv.zip (Azure format) We are soon switching to those image for our armbian-config software install testing, so those images will be kept in good shape, but for Cloud deployments we need your help. In case you find them working well out of the box, install Docker "Hello world" and do some general things, please report which Cloud provider this was. Thank you!

Always use main branch, older branches are here for reference and to build with sources at the state of initial build. We had several bug fix builds after point release, but they were made from main branch ... as we don't backport commits to frozen branch. Not enough people ... OS version is not determined by build framework, but externally. https://github.com/armbian/os/blob/main/stable.json Which version is bumped when any new Armbian package is sent to the repository. You can also set version with a parameter IMAGE_VERSION=25.2.3 ... In theory, if we would have "endless" computing / storage resources, we could make RT kernels for all variants. Currently, this is a bit insane as there are too many kernels.

Correct, but I also haven't tried it yet. https://docs.armbian.com/Developer-Guide_Build-Preparation/ Once you get it running, choose this: and enable what needs to be enabled (there must be guides around the internet and AI also usually knows). Make sure to freeze this custom kernel, so update won't be replacing it later.

This board uses modern kernel, where many features are missing: https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one Since sources are not coming from Hardkernel, this is what is needed: - developing and adding missing driver - adjusting device tree for this kernel / driver - keeping this working (maintenance) None of this is quick, cheap, easy or simple. If project donations increase by a factor of 100+ or if Hardkernel / someone covers it, we can take meaningful action. Otherwise, progress will depend on random contributions from individual supporters - "Community support".

FYI. I tested booting Rock64 with latest images, but there are several revisions of this hardware and not all might work (well).

Yes. Then we have automatic test install on target release while making a PR. If that passes, merge is good to go.