Igor

Nice! In case you will get an idea to add something to this system, this is how it goes: https://docs.armbian.com/Contribute/Armbian-config/

Yes, of course. Running apt update + apt upgrade should update armbian-config to the latest. If you want to keep installed software updated, see options in "Updates". You can enable automatic updating of container images. If you are somehow missing sources lists, manual way: https://github.com/armbian/configng/tree/main?tab=readme-ov-file#getting-started

Yes of course. But documentation or FAQ should be somewhere and up2date. Its a lot of work / impossible for our small team to cover all aspects of a Linux system. But for at least Armbian specifics - which this is - we might have somehting. Thanks!

Help in improving our recovery instructions is also warmly welcome https://docs.armbian.com/User-Guide_Recovery/ We are too small for "everything"

Old one works nice again: https://www.armbian.com/odroidc1/

This looks like DNS problem / or lack of apt update command before installation.

With point releases we are targeting (CURRENT) LTS kernels, while the rest is anyway DIY or build daily. This is just an idea / option, perhaps better way to share the load. Keep the good work!

You should always use apt.armbian.com as we are automatically removing mirrors from pool that are not synced yet. I just tested Odroid XU4 switching between nightly and stable, and it works when installing packages from stable repo. Name / version of the file is the same. If someone has time, those instructions would need some update https://docs.armbian.com/User-Guide_Recovery/ I am totally busy making a release and can't touch this in weeks to come.

No worries, I am happy that you tried. Its never too late to learn new tools, and Git is the most important tool in this world. What you did wrong is removing other files - keep old, add new, then we merge them into the code. Principle goes this way: 1. You make a clone of this Git (git clone ...) 2. You checkout to a new branch (git checkout -b adding_rpi5_firm) 3. Add files to correct location (which it looks like you did) 4. Push the code and open pull request Some generic instructions: https://docs.armbian.com/Process_Contribute/ https://github.com/armbian/build/blob/main/CONTRIBUTING.md Also some AI tool can help you driving this process easily.

@unic8 I look into the code too, but it will have to wait ... not exactly 5 minute job. I have reverted that bump, so we are back at 6.6 and working USB.

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.