Igor

Could be. I also don't know - has to be tested. Can you jut open a PR with those files to firmware repo? I can test perhaps next week.

Its a shame for us There are so many problems (in general) and so little time / resources. Not yet fully fixed, but working on.

This can give some ideas: https://docs.armbian.com/User-Guide_Recovery/ (not exact walk trough, but the principle is the same) Note that fixed packages are not yet uploaded. In a couple of hours.

Fixed by: https://github.com/armbian/build/commit/5115cdf47a91f9cf5eb15f1b4984deebbe329002 This can help https://docs.armbian.com/User-Guide_Recovery/

XU4 / HC1 is fixed by https://github.com/armbian/build/commit/5115cdf47a91f9cf5eb15f1b4984deebbe329002 Images are in generation, update is going out when possible. (broken updates were also disabled, but takes time for repo to sync)

No, as its (temporally) broken on our side. You can help us improving infrastructure by supporting the project.

Check this https://github.com/armbian/build/blob/main/extensions/mesa-vpu.sh as a way to integrate it.

This upgrade (for this board) fall into update by mistake and unfortunately its broken. We are still working on to determine why this happen, then publish images and if there is no report on problems, we pushed update to repo. To minimize what just happened to you. I am truly sorry, but we are operating this service with way too small resources and proper professional testing is far out of our reach. I am removing this broken update from repository ...

Redirector works on your IP address location, not timezone. We are aware of the problem and we are somewhere in the middle of solving it. Support for "don't use these mirrors for this country" was added to the code https://github.com/armbian/armbian-router (actually quite some time ago) but this was not yet pushed to production. Low resources / no time, there is always something more urgent ... @Efe Çetin started working on redeployment and re-configuring about a week ago and re-deployment of paste.bin server (which is also in bad shape). I would estimate task completion of this transition in about a week. Can only apologize for troubles and ask for patience. We do what we can. We have two fast mirrors in Russia: https://mirror.yandex.ru/mirrors/armbian/(Moscow) https://stpete-mirror.armbian.com/ (St. Petersburg) but if Ukrainian are closer, you will get those ... Other mirrors: https://docs.armbian.com/Mirrors/ This is re-director entry point, located in USA, Chicago. This should always work. https://whatismyipaddress.com/ip/130.185.239.78 This is also getting moved to another ISP, but will stay in USA.

I doubt problems has anything to do with networking stack. Its more down to the driver quality itself, perhaps (less possible) some changes in wireless section of kernel. This is 2nd worse wireless chip found on single board computers. The winner of worse is (in)famous Xradio, found on Orangepi Zero 1 and few others, for which we lost thousands of hours only to keep it barely functional. Opi tend to use the cheapest WiFi chips they can find ... Quality will probably always remain as is and keeping it build-able with modern kernels will always remain a challenge. This is the same with all wireless stuff. There is a nice project dedicated to Linux WiFi https://github.com/morrownr/USB-WiFi where one can get some overview on the topic.

Remove headers package as it seems broken. This is workaround. For fixing - we don't have resources nor time, so welcome to join resolving the problem for everyone.

That is a hard work of people that spent their precious private time to fix broken software support of Orangepi.

We will look into this. Build was reported working, but images were not tested yet.

FYI. Fundamental problem is that users expectations are not matching resources open source developers have to sponsor you. You are not our customer. You are a customer from someone else, a company that are also using software from us, for free. Their official images are Armbian based and they never give us a cent for that. They also removed all our names from it and returned minimal (c) and "based on" after we applied substantial pressure. Dietpi is a pirated copy pasted project. All problems we have, are copied too, nothing gets our way. Code is free, so this is hard to understand stealing, support and credits are not. They are stealing credits as they forget to tell you that "all their work and support" is originating from Armbian. They don't support anything. They fully rely on our support and they do everything to minimize value we product and glorify their (non existing) part. They even produce (fake) news on their (non existing) software development. This piracy would be smaller problem if they would at least contribute to common problems. But they don't do that. In past 10 years, you won't find much, less then 5 trivial code commits! Its amazing, but customers of free of course don't care. Free stuff from Armbian or free stuff from its copy, its the same. There are several projects that are working with us, we work with them, share problems and we are all happy. Dietpi (and also Orangepi) works against us and against you (on a long run, so you don't see it). For different reasons. We still actively maintain software you use, even you also ignore us totally. Nobody cover all hardware features on all boars. This is impossible. Word "support" is generally and largely abused. There is little we can do about / and over-expectations. We had to invest substantial amount of efforts to develop rules under which term "support" is abused less. https://docs.armbian.com/User-Guide_Board-Support-Rules/ Remember that not just all R&D but also all support costs, dealing with costumers, remain open source project financial expense. And our income are donations, which most people don't even notice. And you are telling us that we should do it better? Hardware support is hard work, not an art / cosmetic / philosophical value that is present on 90% of Linux distributions Orangepi want that software stays the same and they just want to sell you new products. So they are doing new models (illusion of progress and improvements) and each has something to tackle, bring support costs (which they don't have). Support is never improved by them. Its by us, never by Dietpi. For every 1000 contributions to common problems, they make perhaps one ... Its that bad and that obvious, but still, ordinary Joe don't see as anything wrong. Competition is healthy - yes, software doesn't need to be better, just you need be believe it is "supported". Nobody claimed anything. Our support is "best effort". Support how we see it is different how you see it and we can't change that. Armbian is not a commercial product - we work for fun. If its no fun ... "there are sources, DIY, stop complaining". End users donations only cover us 0.5% of time we lost instead of everyone, including supporting dirty players that doesn't help in resolving common problems and certainly doesn't make any donations. Donations have important motivation role. There is little developers / sponsors of software you use can do. Except placing a donate button, asking to support this. We are not doing this for money, we don't need better software and support. You do.

Hey! When those three jobs finishes: https://github.com/armbian/os/actions/runs/13238582459 https://github.com/armbian/os/actions/runs/13240767648 https://github.com/armbian/armbian.github.io/actions/workflows/generate-redirector-config.yml it should be O.K. Fundamental problem is that at this moment, repo and index is not in sync. Why that happened ... is another story, it should not happen. First job checks and updates if there is something to pull to stable repository. It pushes to 1st class repo Second job is optional in this case. Third job checks all mirrors and only serve the ones where index and files are in sync. Problem is that those jobs takes hours ... and in the mean time, repo is broken.

Yes, this is temporally problem that shows up here and there or you simply forget to run apt update before? We are having difficulties with maintaining our infrastructure (not enough people and other resources) which needs several improvements ...

Here are variants how you can support our project Board support rules: https://docs.armbian.com/User-Guide_Board-Support-Rules/ (I think you will be able to get an answer by reading this)

There is /boot/boot.ini Change this there and try.

If you happen to figure out which firmware files we need, we can copy them to smaller firmware package that is installed by default: https://github.com/armbian/firmware (pull request is welcome)

6.6. contains it, but we are moving all kernels to 6.12.y, where this seems broken - major kernel upgrades always kills some functionality, which is why our work is hard, stressful and expensive. I have tested booting this device on kernel 6.12.y, but not USB as that would make testing just a lot more expensive. Burning most of project donations, which is all we have, for a device we don't even support, just to fix this problem is destructive for project. Morally and financially. Support rules: https://docs.armbian.com/User-Guide_Board-Support-Rules/#community-maintained This is a problem of this particular device. All I can afford to do is reverting this upgrade and we forget about kernel 6.12 on this device.

What is the right Ramdisk format?

Thanks @Josua-SR! I tried with self made and this binary - we have some troubles with kernel I guess. => boot switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2996 bytes read in 15 ms (194.3 KiB/s) ## Executing script at 03000000 Boot script loaded from mmc 158 bytes read in 12 ms (12.7 KiB/s) 28834 bytes read in 27 ms (1 MiB/s) 11476654 bytes read in 1086 ms (10.1 MiB/s) 8546328 bytes read in 843 ms (9.7 MiB/s) Working FDT set to 2040000 Kernel image @ 0x2080000 [ 0x000000 - 0x826818 ] Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid SCRIPT FAILED: continuing... Loading Boot0000 'mmc 0' failed EFI boot manager: Cannot load any image

Yes. This file fall into incoming by mistake, two weeks too soon. Since its harmless, it will stay.

I set most used combination as we have to set some limits. Currently we are at 500 weekly images, which is already a rape for (limited) CI infrastructure After we manage to move desktops to runtime (https://github.com/armbian/configng), we will be able to remove many desktop images and provide more CLI combinations. Exactly, I think its not worth going manual exceptions way. HAS_VIDEO_OUTPUT should suffice. Server builds is heavier and comes with Network Manager, while minimal comes with systemd-networkd and less tooling. Debian based or Ubuntu, depends on what is your use case further. A very few native application suites won't work on one, while it will work on another. The rest are IHMO personal preferences and stereotypes. Ubuntu server is cleaned from Canonical things and its pretty much Debianized. Exceptions can be covered that way. This build target is common for many different TV boxes, so I assume the user-base is also bigger, so is the need I guess.

Please check updated documentation: https://github.com/armbian/documentation/pull/620 if this answers your questions clearly enough. Rendered: https://github.armbian.com/documentation/620/Process_CI/