Werner

moved

duplicate

https://forum.armbian.com/terms

Board?

Thanks https://github.com/armbian/build/pull/4466

There are no source packages [in nice debian dpkg format] for u-boot. Sources are pulled from upstream. Everything including all applied patches are there: https://github.com/armbian/build

Ah my bad then. Didn't get that it was onboard.

Do other USB devices like a keyboard or a stick work on the same USB slot? Try using dmesg -w and watch output closely when you plug in and out your WiFi dongle.

As said there is no easy way to do that. If the given configs (legacy, current, edge) do not work for you the procedure to get a chance for an older kernel are mentioned above. You could use git blame in the file where the sources versions are specified to know when it changed to the version you prefer so less poking in the dark.

Device tree adjustments are applied via patches over the given kernel/uboot sources. Easiest would probably be to use CREATE_PATCHES switch. This way the build framework will patch everything up to the point where it is ready to compile stuff but will pause to give you a chance to modify the sources to your needs. Then it will scan those and create fresh patch files with the adjustments you made. These patches then can be applied to further builds. Take a look over here:https://zuckerbude.org/armbian-using-create-patches/

You could go old fashion way and disable systemd-resolvd and set your dns server manually in /etc/resolv.conf

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Nope, he does not Isn't that this board where the vendor explicitly asked customers to not bug Armbian folks with issues?

Probably. I assume some capacitor needs to discharge to erase some transient memory. Probably unfixable via software.

Am I the only person thinking that having a window of one week for maintainers to test RC images, collect feedback (if we get any valuable in that short time window at all) and even then try to attempt fixing reported issues on a "maintenance/bugfixing release" is a bad idea?

Then get yourself a wall safe or somethign and put the SBC (or just the eMMC module) into it so nobody can access (and read) it. On a more serious note: I have no idea what you are expecting. read-only filesystem with overlay? Physical protection against 3rd party?

AFAIK this soc has never been supported by Armbian.

Search for topics like full disk encryption or rootfs encryption.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Reasonable. Back then Xenial, Bionic and Focal were the only supported build environment while today it is Jammy.

Then you have to go farther in the past. However there is no guarantee that checking out an old tag will actually compile since this cannot revert upstream changes as well.

It will be present in all images built from that point forward. So next cycle of weekly community builds or next regular release.

There you go:https://docs.armbian.com/Developer-Guide_Build-Preparation/

https://fi.mirror.armbian.de/apt/pool/main/

You can always try to fetch the armbian/build repository selecting an older tag but chances are high that compiling will not work since those tags obviously cannot revert changes from upstream or other dependencies Armbian relies on. Fixing if necessary is up to you. I think 5.10 is legacy at the moment for sunxi. Older kernels are no longer available in master branch. I don't know about sunxi_usb_udc. Is that one of those vendor developed and never maintained or even upstreamed hardware-specific drivers?