Igor

From logs I can only conclude that problems are at your side - wrong configuration. Anyone can help you - problem is almost certainly not Armbian specific.
 
May 10 21:05:09 pirogue systemd-helper[8502]: dnsmasq: unknown interface end0 May 10 21:05:09 pirogue dnsmasq[8502]: unknown interface end0  
I am not an expert of application you try to install, in fact I never heard about until now. 

Most likely P2P wireless, not necessarily functional. This is automatically present by a (wireless) kernel driver. Use the device that works and ignore the other. If bogus device gets to your nerves, dig into the code, find a way how to disable it and sent a patch.

But you can step up and maintain this for everyone? We don't provide direct contact email, as we don't have capacity to deal with all packages that exists in open source world and as you discovered by yourself, some maintainers are not longer with us, so many packages doesn't really have anyone doing this.
 
In our system - all you need to do is changing / bumping numbers and open PR. If build and test succeeds, someone with merge rights, merge it into the system and within few hours, packages are available on repository.

PR:
https://github.com/armbian/os/pull/300
 
Pool and test install was successful:
https://github.com/armbian/os/actions/runs/14016836904/job/39243546741
Merge follows, packages will be out with next repo sync.

By community is already supported for some time
we even discussed option for official support in cooperation with its maker. We do that for their CB1. Which is Allwinner based, thus pretty different. As @Werner proposed, build is best, also there you can enable HA extension and build with preinstalled Home Assistant. We don't make stable pre-build images, but nighties are generating https://github.com/armbian/os/releases/

Which most likely won't work on Wayland based Gnome desktop ... switching Gnome to X or using XFCE or similar is a way that this will work.

This is probably happening due to wrong local time.
 
For the cli github package - remove it from /etc/apt/sources.d/ as its not needed anymore. We provide this package via our repo.
 

With enabled everything in automatic upgrades. If kernel is not frozen, it will update too. If it's frozen (check with apt-mark showhold) find in the armbian-config to unfreeze it.

Its a Trixie related bug (or some intentional splitting of package dependencies). Fixed: https://github.com/armbian/build/pull/7894

# Europe/Moscow - 2000 Mbit/s - server: stpete-mirror.armbian.com/beta/ rules: - field: location.country.iso_code not_in: - UA latitude: 59.9417 longitude: 30.3096 weight: 10  
# Europe/Kiev - 1000 Mbit/s - server: fastmirror.pp.ua/armbian/ rules: - field: location.country.iso_code not_in: - RU latitude: 50.458 longitude: 30.5303 weight: 10  
After this change, our redirector blocks access to Russian mirrors for users in Ukraine and vice versa. Hopefully, this feature will become obsolete soon.

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. This file fall into incoming by mistake, two weeks too soon. Since its harmless, it will stay.

This https://github.com/armbian/configng/pull/424/files should fix it. Update will be avail in couple of minutes after the merge.

Thank you!
 
apt update & upgrade will update armbian-config where this works as expected.
 
Until next bug found ... 

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 ...