Werner

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?

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

https://github.com/armbian/community Support status is unknown. May work, may not.

Balbes maintains his own fork of the Armbian Build Framework but pushes his changes frequently into Armbian. So for now only his pre-built images are available until next push.

Nobody prevents you from using any available kernel in any available userspace by simply building the combination of your choice via our build framework. However there is no guarantee that this will work/boot or even compile properly. https://docs.armbian.com/User-Guide_FAQ/ And it is our choice which prebuilt images we provide for convenience since building and providing those takes lots of computing and storage ressources

So you download the wrong image and wonder why it does not work? M4 (non V2 does not have a maintainer attached (feel free to volunteer) and therefore no images are directly provided for download. You can try those from archive: https://fi.mirror.armbian.de/archive/nanopim4/archive/

Yes but no idea how well they work https://www.armbian.com/orangepi3-lts/

We do not provide support for 3rd party images.

Increase verbosity to 7 in your /boot/armbianEnv.txt. Otherwise nobody knows what's going on inside.

moving to unsupported

Maybe @NicoD or @seclorumgets a chance to both confirm the issue and check if the commit fixes it.

https://github.com/armbian/build/pull/4296

Apologies for the short downtime about an hour ago. Both forums and main website have been relocated to new hardware. You may notice a significant performance improvement, especially in forums. Enjoy

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