Igor

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.

Its not enabled in config.

1. Sent PR to enable it https://github.com/armbian/build/blob/main/config/kernel/linux-rk35xx-vendor.config#L2885
2. Upgrade to vendor 6.1 kernel as we will not maintain 5.10.y anymore (there its also not enabled)
3. Use nightly kernel builds / tell us to sent update to stable repository

If you have downloaded "Debian" from Orangepi site, you are already using Armbian. Only some slightly changed old version and without Armbian & community support. To try Armbian, you burn SD card and boot from it. No need to install it anywhere yet. To install it, just run armbian-install and select correct (root) partition. Since this is Linux and your are using 3rd party OS (and bootloader), backup of /storage is recommended before proceeding. Just to be on a safe side.

Orangepi OS (Arch) is custom / re-branded Manjaro and Manjaro is not doing much else then shipping (selling) their Arch derived OS while taking our and community work on kernel maintainace. This is the story how Orangepi "supports" open source - by primarily supporting code dealers that already mainly have negative contribution to open source development. But who cares other then small group of people called "developers"?

In general, HW vendors have interest to block or at least control other OS providers and it is possible they purposefully compiled SPI boot-loader to not load anything else then their OS. This would explain why you can't load our OS. Manjaro already provided (or tried to) this "solution" to Pine64, so average users would have troubles changing OS. Details: https://blog.brixit.nl/why-i-left-pine64/ 
 
For us, this is easy to work-around, but bulk of people might still need to stick to their official promo/spy/pirate-ware.
 
Solution?

Debian based OS:
 
sudo apt update sudo apt install mtd-utils sudo flash_eraseall /dev/mtd0  
Arch based OS:
sudo pacman -Syy sudo pacman -S mtd-utils sudo flash_erase /dev/mtd0  
Then boot armbian from SD card and run:
 
sudo armbian-install  
And choose "update MTD boot-loader" or "Install it to NVME", which will also update boot-loader and transfer image to SSD. Tested right now with Opi5 lying on my desk.

This. I think the shell / concept is done and adding this should already be possible, but from scratch. We try to get rid of that old spaghetti code that is in old armbian-config.
 
 
I am not very up 2 date on what is going on there. @Tearran and @schwar3kat are trying hard to push it further and perhaps they can give you some hints how to add this section. 
 

Yes. That the idea.

This is probably some (temporally) network issue. Infrastructure shows no signs of troubles.

https://armbian.atlassian.net/browse/AR-2192
Fixed in latest release.

Bookworm is latest stable. You can only upgrade to unstable ... which is not recommended for production. You could upgrade kernels, but we don't provide them anymore for bullseye.
 

That is correct. This is the list of packages per distribution:
https://fi.mirror.armbian.de/apt/content.html
Bullseye only has some files, probably by mistake. It should be just empty as its not supported anymore. Change tags in armbian.list from bullseye to bookworm and update. Should be fine .... at least as far as from Armbian perspective. We can't vouch for packages that are coming from Debian repository as they might come into some conflicts between each other. This is the problem we observe on older releases and have no capacity nor wish to address.