Igor

This is a reminder that for production quality someone needs to constantly invest time. We build community images for amateur usage and to match other projects support levels. We also keep archives of almost all older builds: https://archive.armbian.com/orangepi2/archive which could serve as a cheap workaround.
 
We do that for many boards, but there are simply too many of them. Producing them is dirt cheap ... maintaining extremely expensive. There is also lack of cooperation from 3rd party projects and vendor in question. Support goes in reverse order, they actually harm us all the time, consume our work, contribute nothing. Orangepi also only invests in sales and does not support open source developers / projects. For our group I can tell you 1st hand, but I have solid information that others are also unlucky.
 
 
We are happy to help.
https://www.armbian.com/contact/ -> Quick start
 
Not sure what is current support status. It could be very broken with weeks to invest or not so much. Last time I had those boards (2e to be precise) in the automating testing, they were not very stable. Reboot sometimes didn't bring them back, crashing on load ... 

Impossible.
 

This might help you: https://github.com/amazingfate/armbian-xiaomi-elish/wiki/Flashing-Guide

Reading the A20 SoC documentation?
 
tl;dr;
That is not possible on this hardware as boot from NAND is not supported on modern U-boot / Linux.

They are back, but no warranty that images works as someone from community added them to the build system. Which are making them automatically ... and automation needs costly and constant maintenance for which we have very limited resources.

Yes. Rolling updates gets updates all the time. Here:
https://github.com/armbian/os/actions/workflows/repository-update.yml
you can see when beta repository is updated. If nothing breaks, every day, sometimes more then once per day, when the code changes. We can not distinguish if fixes are for certain board as they (32b Allwinner in this case) share kernel.

tl;dr; There is nothing to worry about. You can also disable https://docs.armbian.com/User-Guide_Armbian-Config/System/#disable-armbian-kernel-upgrades this and only keep upgrading user-space packages or switch to stable repository https://docs.armbian.com/User-Guide_Armbian-Config/System/#switch-system-to-stable-packages-repository Sadly I can't tell you if this will make any change to this particular hardware, but you won't be bothered for upgrade until next point release. We keep those boards on rolling because we have no resources / funding to tag them officially stable.

Those are community supported images - they work or not. Nobody will debug them but you. Just type:

armbian-config
 
and switch to alternative kernels which might work better - easy.
 
I accidentally bump into this by scanning copycat projects.
 
 
Without supplying logs, nobody will answer. This is open source project that invest into R/D. Time is not at our side. There are too many problems in open source, so you need to fight for attention  ... and community supported is down to community, make friends first, ask questions next. Team is not covering those.

I don't know if you noticed, but he only does lots of chatting and not resolving common problems.
https://docs.armbian.com/#comparison FYI (downstream = dietpi)
 
 
We (developers) know that very well, its quite a norm. Pure luck keep those boards functional - "Armbian community support" counts only on that. Mainline support means little in this regard. Without constant maintenance, things will certainly break apart. This is law in this world. In most cases (supported branches) we fix this before anyone notices. For not maintained, as in this case, - we don't know and don't want to know. I mean, perhaps you got lucky and someone will respond.
 

I think it is better asking CHATGPT.
 
 
... which is our work. We suffered and lost months, while he is selling this under his brand while he never helped in any way. Contrary. 
 

It is hard to describe how muck work was needed to get this working: (sales person you have been talking too, never worked with / for us)
https://docs.armbian.com/Release_Changelog/#v24111-2024-11-28
 
Here you can make a donation:
https://www.armbian.com/donate/
 
And here 
 
you can step up as a maintainer. I would not ask you this, if we would have other options. Then you can sort out and provide people images that works.
 

@TonyMac32

Try from here https://rsync.armbian.com/incoming/efectn/orangepi5/archive/

Nice to see that you managed to put our build framework into good use!  
 
Build configuration can be .conf, if you plan to keep it maintained here, else it can be .csc (community configuration). ! tl;dr; version of support policy can be found here  https://docs.armbian.com/User-Guide_Board-Support-Rules/ 
 

Code wise, not an issue, all of it, until it met common coding standards (quick check = it does) and that it doesn't break anything else (which I also believe it won't). Remaining problem is the instructions part ... We currently don't have any, not right, not wrong place in the documentation to keep that kind of things well organised. A comment with URL in board config file can do for now.
 

Most of contributions to Armbian are done in similar way. 

Its a feature  We decide to leave this utility on development branch (there is separate armbian-config.list in the source folder) for awhile to speed up with the integration. There is a lot of automation that is helping preventing shipping broken app. And the app itself is very simple compared to everything else.

No, it doesn't. This needs to be done beyond.
 
sudo apt purge linux-image-legacy-sunxi64 linux-dtb-legacy-sunxi64  

They are not needed. We use flash media friendly and more advanced ZSWAP solution by default.
https://www.google.com/search?q=zswap
 
If you don't want to have this, you can of course disable this feature in /etc/defaults/ (will be soon added to armbian-config) and add swap file. But that is not recommended. 

We keep several oldies in the automated testing facility and Cubietruck is almost identical to Bananapi M1 and it works perfectly well:
https://github.com/armbian/os?tab=readme-ov-file#cubietruck
I would put my bet on wrong / not sufficient powering. Which is still there and those (old) topics are still valid.
 
 
Old boards are fine! I have several boxes of them and might sent them to a museum one day  We are just too small team / project to face with several hundred different devices. Old boards should, in theory, works well, but silent (as nobody monitor / maintain them) regressions comes to the code.
 
I hope someday dedicated retro hardware section emerges on Armbian forums and further prolong life of those devices. We did / do what we can ... 
 

Made a PR https://github.com/armbian/build/pull/7245

Yes, most likely broken / incomplete driver. Desktop runs Network Manager and CLI / minimal systemd-networkd. If driver is not in a good state, this is how it could manifest. Possible workaround = build CLI server image which contain Network Manager. No warranty that it will work ...
 
Topic was moved from https://forum.armbian.com/forum/25-beginners/ as Armbian don't work with this vendor / hardware so its on you (& community) to resolve the problem. Or not. When you find out what is the problem, you are welcome to share it with everyone.

This cheap (WiFi) hardware was pushed to the market in unfinished state and since ever, with negative budget this is the only way, kept at basic operational state:
"does it connect?" "yes it does", "does it work satisfactory? "yes it does".  "does AP works" "perhaps" as this was already difficult and expensive for time, but enough for all home users. Drivers are by Armbian only kept maintained to meet kernel API changes, while real driver maintenance was abandoned by everyone years ago. It is unlikely that what you are looking for will ever be fixed. But sources are open, perhaps. You only need to find and fix this problem or compensate someone weeks or months to get this feature fixed ... if you have a biz case / budget to support this. Without our maintenance work, you would not have this question in first place as WiFi support would be gone. I don't think you will find anyone that will do this instead of you for a feature almost nobody needs. Good luck.
 
My 2c.

Interesting.
 
Perhaps extending this service?
https://github.com/armbian/build/blob/main/packages/bsp/common/lib/systemd/system/armbian-firstrun.service
At build time, this is cp to the image and enabled:
https://github.com/armbian/build/blob/main/lib/functions/rootfs/distro-agnostic.sh#L400-L401
Script:
https://github.com/armbian/build/blob/main/packages/bsp/common/usr/lib/armbian/armbian-firstrun

All those files you can edit, compile image and try. I hope this helps in some way.

Try to remove armbian-bsp-cli-orangepi5 first or both bsp packages at once.

Releasing packages on repo was purposefully delayed for a good week in order to keep with another expectation you have - that release software is well tested  What we help here is to lower % of breaking your old installations by delaying with releasing packages so images gives additional round of test resoults. Testing of one release exceeds budgets for hundreds  if not thousands of times. If you don't help with testing, its impossible to test. And you don't / very little. There is nothing we can do and only everyone of you can improve this. If you want better service, step up, help us maintain some small part, perhaps automation for repository management? Which is related to your problem. More people, better organisation, faster and better will be updates ... or at least not worse.
 
https://github.com/armbian/os/actions/runs/10762581915
Once this is finished with success, packages will be uploaded to the repo:

https://github.com/armbian/os/actions/workflows/repository-sync.yml
Then few cycles of repository synchronisation:
 
https://github.com/armbian/os/actions/workflows/redirector-update.yml
Followed by re-director update, which serves, in theory, only mirrors that are up to date:
 
Someone needs to help maintaining this mechanism. 

If you expect drivers going up with the kernel, then you need to help here:
https://github.com/armbian/build/blob/main/lib/functions/compilation/patch/drivers_network.sh

Its known issue. We don't have a fix yet.

https://github.com/armbian/build/blob/main/packages/bsp/common/usr/lib/armbian/armbian-firstlogin

No. You need more recent ZFS, which comes with supported Armbian OS, which is Bookworm. Bullseye generally works, but we don't support it anymore as upstream is also deserting it. We ship ZFS v2.2.4, soon upgrading to 2.2.5, but only on:
 

 

All those headers are useless, remove them, also generic kernel 5.10 as it probably won't even boot. You need:
 
apt install linux-headers-current-rockchip64  
Fresh Bookworm image, same (sub)arch:
 

Try this way:
 

This was dropped out from kernel by mistake, but it was already fixed at sources https://github.com/armbian/build/pull/6984 You need to build kernel from sources or use kernel from nightly repository that is already having this fix.
 

1st option (Noble Gnome) with full featured desktop, where (almost) all features works / are enabled. Second is for IOT / server and others are ... there is some small info why they are. If you don't know why, skip / ignore them.