Igor

It is possible that radxa mraa implementation is only compatible with their private 4.4.y kernel. Legacy (kernel forks) vs. mainline and why this is far from simple https://docs.armbian.com/User-Guide_Getting-Started/ Check this forum https://forum.armbian.com/forum/40-reviews-tutorials-hardware-hacks/ for standard libraries. Not relevant as already answered at vendor forum. Which has almost nothing to do with this - if you want to use modern kernel. Someone needs to develop those overlay for modern kernel. Then you can add them. If they exists, you can enable / disable them via armbian-config -> hardware

What is loading long time? OS? https://opensource.com/article/20/9/systemd-startup-configuration

Yes it is. We provide it for older kernels https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh#L236-L263

NP. Happy to clarify. It took us and other projects and people several years turning this board of electronics into something usable. Out of, lets say, 1000 hours of our private time we lost dealing with HW and frustrated users, few minutes were compensated by users donations, not a second by people that were selling you this HW. And people remain unsatisfied (vendor does not communicate with you for a very long time) as not every feature works in upstream code and it probably never will. With time, features can going to break anyway if not well maintained ... If this is a core thing for you, you can try to add it. Use our SDK, which will save you several weeks on the top of the code that was already cleaned and improved by community. All this is top notch compared to the "SDK" shipped by vendor(s) (its hard to imagine what kind of shit software support was shipped by vendor). Then start working on it. This is how things go. Perhaps this feature is already developed by someone (similar hardware can have same driver), just not shipped upstream or driver exists, just need enabling, adjustment of config, timings. Again - going this path is something normal in this world.

apt-get install armbian-firmware-full resolve this Those two things are unrelated. We maintain a lot of 3rd party wireless drivers https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh , which normally end users should be dealing with. And with all the problems that are related to the build process. Here you can observe how users from random Linux distribution suffers every time code breaks down due to changes in the kernel code: https://github.com/aircrack-ng/rtl8812au/issues https://github.com/aircrack-ng/rtl8188eus/issues https://github.com/cilynx/rtl88x2bu/issues https://github.com/brektrou/rtl8821CU/issues https://github.com/jwrdegoede/rtl8189ES_linux/issues https://github.com/Mange/rtl8192eu-linux-driver/issues ... With Armbian, plug and play works almost every time. If not, you still have the manual way - as you would need to do with Debian, Ubuntu, Manjaro, Fedora, ...

Yes.

Its not uncommon and is highly possible that network drivers were not ported to modern u-boot. Or they are just not enabled? We switched to the modern u-boot about a year ago and lack of this functionality does not bother us.

https://docs.armbian.com/#what-is-armbian Armbian is closer to Embedded Linux then Debian / Ubuntu. From embedded Linux perspective, "Debian" or "Ubuntu", upper levels, user space, different versions of standard libraries and application, is irrelevant. Something that has absolutely no relationship with problems most people face. Like to issue you have. General Linux Experience, like you probably already figured out, doesn't help to fix the problem. There are a few of reasons why this instability happens and all require investigation, usually into boot loader ("bios") or related kernel functions. It can hang because of not well tuned power management, badly written network driver, hw quality ... diagnostic can take an hour, but can stretch to weeks. If you have experiences and know where to look. I would start with an easy solutions, which doesn't take much time. 1/2 hour to build, then testing.

This problem was mitigated this way https://github.com/armbian/build/commit/4a689f8b89bca4ecc60a5c24cd8f9beee73bbec9 but perhaps its not enough?

https://docs.armbian.com/User-Guide_FAQ/ Yes they are. They are actively stealing what we develop. They even come to this forum with their users asking us to support their clients. Its sick how other distributions operate.

Changes in kernel 5.19.2 -> are responsible to adjust the code yet again I tried, but I find myself running in the circles ... Anyone more familiar with this driver? @arclight @piknew @Skupsy @Icenowy We are still attached to @karabekfork https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh#L418-L424 but this https://github.com/dbeinder/xradio/commits/karabek_rebase looks like most recent.

Can you perhaps elaborate in detail what have you tried so far? And supplying all the logs. If feature works on hardware and with their legacy kernel, this doesn't mean it works elsewhere right away. We ditched old and security highly problematic legacy code long time ago. But the price is that not all functions work yet. Here its not mentioned https://linux-meson.com/mainlining.html# and I don't recall if we have this working or not.

This is a bit outdated, but might help https://docs.armbian.com/User-Guide_Advanced-Features/#how-to-freeze-your-filesystem-outdated

Which image exactly? Link.

If you have a battery and its getting faulty, perhaps this or the bug within was the trigger? https://github.com/armbian/build/pull/3084

Kernel is what defines interaction with the hardware. Which kernel is there. "ubuntu" plays zero role. https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one

https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one Contact ASUS. This is their duty and expense to cover. Or yours. Our build system will save you few weeks so welcome to make a donation. It is very expensive to keep it maintained. https://docs.armbian.com/Developer-Guide_Build-Preparation/ When you are done, by you or by people you will be hiring to solve this problem for you, share a patch with others. Armbian does not need this to function. You do.

Here you can find build system: https://github.com/armbian/build and here are instructions how to use it: https://docs.armbian.com/Developer-Guide_Build-Preparation/

This is Ubuntu problem, but the solution is probably sudo apt install ca-certificates Also check if your clock / date is correct.

Working here ... re-director is currently under some re-work. Could be related. Its should be a temporal problem.

I was also looking into usbip as I want to implement it to be able to attach devices under test to USB server containing a bunch of wireless cards. This seems covered well. Under this? https://github.com/armbian/build/tree/master/packages/extras-buildpkgs

This (except lines 107 and 108) https://github.com/armbian/scripts/blob/master/.github/workflows/maintain-runners.yml#L104-L109

I didn't fix this for you, but for all of us. I know it works, as it was tested. If you really do, you can equalise your dept in a few years by getting lowest possible https://forum.armbian.com/subscriptions/ or by doing something project needs to help you https://forum.armbian.com/staffapplications/ Both options are in your best interest. This is the problem and solution. https://armbian.atlassian.net/browse/AR-1285 Here you can start learning https://docs.armbian.com/Process_Contribute/

I have upgraded our runners this way: https://github.com/armbian/scripts/blob/master/.github/workflows/maintain-runners.yml#L94-L123