Igor

Only best long term way is to have one such device in auto testing lab and some help to improve testing routines. With no resources, I can only move super slow into this direction.

Solving bugs can eat a lot more time - you contribute nothing to - and require a lot more energy then casual chatting with forum newbies. We have prepared FAQ for your welcoming. Make friends, then ask for help. There are 1000 people before you asked extremely limited and expensive resources for something ... why your problem is more important ?

Without providing logs, you are on your own - i highly suspect your install is broken in some way, but since there are no logs ... Please don't double post and make us additional expenses. We don't need to fix bugs over and over again, for each person individually.

Software support - the most expensive part of hardware product - is pure Armbian and without Armbian this project would never get this far. Also there is no need to create any mirrors since Armbian keeps archives at many places. Also you can rebuild images from sources at any time.

I know - it was triaged - since this solution covers the most important aspects - you can boot the board and it doesn't freeze. Which is not nearly granted feature and its not secured when u-boot goes up with its version. For more polishing we ran out of time ... and FYI supporting fixing bugs can cost a lot more. Also doesn't align with carefully planned time expenses for R&D. tl;dr; With limited time and no budget it is not possible to fix everything. There are others, more important problems waiting to be addressed.

Archive contain older images. Use the one from the download section - images that are aligned with your model regardless of the date diff, read FAQ, get support to give some fraction back ... and wait for: Hard to tell. A question for them.

It's not a bug but bugfix: https://github.com/armbian/build/pull/3036 Sources are available so I would assume its fixable. Its probably just a configuration or patch issue. Dig in. If you find and fix the problem and when you are sure it doesn't break any other board, send a patch.

Also for other reason. We keep well known and those a bit less known wireless drivers in best possible shape and bundled with kernels we provide. In theory - users should not need to compile exotic drivers that Linux doesn't support (well enough) on their own, but all dependencies are ready (kernel headers, compilers) - so you can. For things we don't cover, can't bundle (zfs) or for experimenting ... We all are It is impossible to know everything, especially in this tech world full of complicated details.

In fact it is. Starting with v197 systemd: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-understanding_the_predictable_network_interface_device_names

For having a rootfs, a bit more work has to be done. We pushed it very far but here fun stops - its impossible to waste months working only on this and without receiving anything in return. Bills has to be paid ... If you have strength, capacity and will to pick it up and push forward: https://github.com/armbian/build/pull/2414 https://github.com/armbian/build/pull/2410 This is needed if you want to have zfs rootfs.

We are aware that R2S device tree is not accurate / correct, but first read this then think what you can do about.

Nice catch, I must have forget about that. I am unable to test if that helps at least by the end of this week.

armbian-config -> software -> source_install ... and it downloads + unpack + add config which was used ... ready to compile. Only deb packing part is not solved yet. Older kernels sources are only in our offline archives. tl;dr; We recently had some repository crash and after big waste of time solving nothing ... I restarted with minimal repository containing only last packages. Which was successfully build.

https://forum.armbian.com/topic/12210-armbian-1911y-release-notes/

Reading this will help you in understanding how you have to form your questions. Currently nobody can help you. https://forum.armbian.com/guidelines https://docs.armbian.com/User-Guide_FAQ/

So you go to download pages and search for "orange pi plus" ok, we have a "+" instead of "plus" https://www.armbian.com/orange-pi-plus/ For the naming part - its up to vendors. We can't do much to reduce this naming confusion

Which OrangePi exactly do you have? There are different models - some images are compatible with Bananas, mainly not.

Yes, we are attached to mainline ATF and u-boot. Probably kernel is the problem.

This is not merged yet, so it won't be in beta builds.

https://forum.armbian.com/search/?q=Hash Sum mismatch&quick=1 We need to extend repository index synchronisation timeout from 1 day to several days since mirrors doesn't get in sync in this time frame. The problem is that current main rsync server is slow (only 50Mbps upload in total), but is cheap and has no traffic limits. We know how to solve this, but we lack time: https://armbian.atlassian.net/browse/AR-789

There is more info in this task: https://armbian.atlassian.net/browse/AR-828

https://github.com/armbian/build/pull/2620/files We have more or less fully functional image with legacy kernel, but 5.13.y hangs at: @jernej Do you know latest working combination (atf / u-boot / kernel) ?

Please don't bump topics without adding value. This is not commercial technical support for your private problems, but community forum and those are its rules and recommendations. Putting a pressure is a very bad strategy when asking for help where precious resources you don't support are wasted - better start here or here or just wait and hope someone that has time and knowledge that can help.

OK, me neither. Lets's wait for some input here then.

Next update will break this again. It would be best that this gets fixed in https://github.com/armbian/build @Heisath Wasn't this fixed already?