Igor

Adding there would be too late. https://github.com/armbian/build/blob/master/config/bootscripts/boot-sunxi.cmd#L36 Anywhere, but the problem are overrides: config:% grep -R BOOTDELAY * config:% grep -R BOOTDELAY * sources/families/rockchip.conf:BOOTDELAY=1 sources/families/rk322x.conf:BOOTDELAY=0 sources/families/include/rockchip64_common.inc:BOOTDELAY=0 sources/families/include/sunxi64_common.inc:BOOTDELAY=1 sources/families/include/sunxi_common.inc:BOOTDELAY=1 I don't know why we have this in first place.

Applying patches to Armbian system that will build kernel with additional changes? Put those patches them into userpatches/kernel/sunxi-current or userpatches/kernel/sunxi-edge and add them to series file inside that folder. Outside of this is not Armbian specific anymore, so you can check any book, guide, attend school, curses, whatever ... and hope they patches apply cleanly. If not, you will need to correct them. Not Armbian problem, also not LibreELEC. Specifically what you are asking is not my field, can't tell.

There are many different version of images for download and you didn't specify with which you have issues with. You have to read how to documentation and see if you can help yourself as you don't want to make additional damages. Also start from here https://www.armbian.com/faq as without all information, bug doesn't exists. After you https://forum.armbian.com/subscriptions/

Yes. I think its related to this code. BOOTDELAY is armbian internal variable, which you can set with parameter. https://github.com/armbian/build/blob/master/lib/compilation.sh#L225-L227

I fix sources so they don't change to secure stability. You need to build from sources https://github.com/aircrack-ng/rtl8812au to see if there are changes. If things are working, provide new commit ID for https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh#L385 and you will help everyone.

I choose to move away from repository under our control to PPA simply because I hardly find time to see my kids and nobody else care ... until its changed on worse. If we as a community (I can fix this for myself this way or another) want to have all those segments under better control, no PPA involved, automated testing of this feature and similar ... this project need help on a daily basis. I am afraid not many other options.

Upgrade won't work atm but if you build a clean image, ZFS will build. Also if you know how to add this by hand.

Like today and from latest sources? Can you provide information exactly which image did you build? Changes to the partition management has been merged last week and they could cause those problems: https://github.com/armbian/build/pull/4184 https://github.com/armbian/build/pull/4138 @going

Board is supported if there are volunteer maintainers which are suppose to help this way. I can personally assure you that WiFi on 3 LTS was tested (at least on 2.4G network) and it works. I am not saying it works pitch perfect yet, but it works good enough for amateur use. More then this we can't provide as there is absolutely no interest from your side to compensate time lost working on things in your interest. Since this is open source and since we provide perfectly supported SDK, nobody prevents anyone to fix problems. Its always a trade. That kernel will probably never receive any update. If that suits you and if you trust that vendor private kernel which nobody else uses with random hacks and random hacks on top of Armbian (yes, they use Armbian as a base, not Ubuntu. Ubuntu is only to make sales association), use that. Usually there is just one version that is ported to the new kernel with minimum efforts. Mainlining drivers is epic and expensive project which is difficult to run if clients are not paying anything and all benefits also goes to your competition. https://docs.armbian.com/User-Guide_FAQ/#development-time (check other FAQ points) Possible workarounds: try connecting with other tools, twice, try rfkill list / block / unblock, reboot, ...

Yes. You need to run nand-sata-installer and choose "update u-boot"

Check logs -> output/debug

1. Looks good. 2. Yes 3. https://docs.armbian.com/Process_Contribute/, always add patches to CURRENT (5.15.y) and EDGE (5.19.y). Usually patch can be identical. Look here: https://github.com/armbian/build/blob/master/patch/kernel/archive/sunxi-5.19/patches.armbian/arm-dts-overlay-sun8i-h3-cpu-clock-add-overclock.patch https://github.com/armbian/build/blob/master/patch/kernel/archive/sunxi-5.19/patches.armbian/Move-sun50i-h6-pwm-settings-to-its-own-overlay.patch https://github.com/armbian/build/blob/master/patch/kernel/archive/sunxi-5.19/patches.armbian/arm-dts-overlay-Add-Overlays-for-sunxi.patch https://github.com/armbian/build/pull/4165 It is handy to use ./compile.sh EXPERT=yes CREATE_PATCHES="yes" command line to help make patches.

Since several weeks, we build all not supported images that at least build, but they are elsewhere https://github.com/armbian/community and untested. Improvements, if any, are still accepted: https://docs.armbian.com/Process_Contribute/

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