Igor

No Linux is having full control over its component made by thousands of people. This particular problem was caused by this https://github.com/cli/cli/issues/6175 where you can find instructions how to fix a problem you have. I already fixed the key, so future releases will have this fixed https://github.com/armbian/build/pull/4163

4.14.y is very old kernel, which even Hardkernel stop supporting awhile ago and problem could be related to that - ZRAM implementation. Move to 5.4.y. At least.

That link proves that problem was fixed, but network issues and bugs in 3rd party components can rise up at any time ... This commit https://github.com/armbian/build/pull/4163 could contribute to the problem you were facing. Another possible problem are APT_CATCHER bugs, another Qemu bugs, ... Documentation is your first stop.

Hi stranger. Start here: https://www.armbian.com/bugs/ and here https://docs.armbian.com/Developer-Guide_Build-Preparation/ Then search forums. Logs are located in output/debug. This is what you need to check 1st. This https://github.com/armbian/build/actions/workflows/build-all-desktops.yml tells us that 20 hours ago installation of all possible desktops worked. Tried local build: no issues. It could be some network related problem on your side. Try again.

This is the diff between your device tree and the one shipped with (latest 5.19.y) kernel: Everything is there, just disabled by default. Don't we have overlays for enabling this via armbian-config -> system -> hardware?

Image is pre-configured for RPi4, but I think some mingling of /boot/config.txt can make this hardware work.

Idea was to provide client part, so I don't know why server was also there. If you agree with the change, comment & approve: https://github.com/armbian/build/pull/4162

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.