Werner

moved

Just tested opt-out on a test account and it worked flawless w/o being logged in. Therefore cannot reproduce.

Tried blacklisting ipv6 kernel module?

Moved. Since the topic is tagged as "solved" would you mind sharing your solution?

moved to tvboxes

Zero 3 is a completely different board. Besides the "Zero" in the name they have literally nothing in common. Therefore this question cannot be answered in this topic since it would be off-topic.

We do not provide support for 3rd party OS

Try older from archive

Two options: - downgrade to 23.02 kernel and grab header from repo - use the build framework to build a set of firmware packages by yourself which then can be installed via dpkg

tl;dr: 5.3 to 5.4 volts and 4 amps. Ideally something industrial-grade. Ideally you'd get something that outputs slightly above 5 volts in order to compensate for voltage drop. For example the wall adapter sold by Xulong with their boards actually outputs 5.3 volts (even though the there is 5 volts written on it). Under full load the voltage drops down to around 5 volts across the board (measured at the USB-A connector). Now imagine powering the board with "only" 5 volts and put a heavy load to it. Will drop well below 5v and this causes malfunction. Also RK SoCs seem to enjoy slight overvoltage

How to get these: https://www.youtube.com/watch?v=UpVMO7gbnYM

Just a guess but I assume it won't work anyways. It would need at least a modified ffmpeg version that supports rockchip vpu which I guess isn't default in these pre-made containers. Could be wrong though.

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

Perhaps host certificates are outdated?

moved

https://www.google.com/search?q=what+is+an+led+and+how+does+it+work Welcome

Login credentials for genuine Armbian images are always root / 1234 For 3rd party images we cannot help.

From a quick look (I don't know about this device in particular) it seems like it supports UEFI and therefore generic ARM64 UEFI target applies. https://github.com/armbian/build/blob/main/config/boards/thinkpad-x13s.wip

Can you share a link? I'm curios.

This happened several times over the past years across almost all SoCs. Personally I discovered this first on the OPi1+ with H6 SoC and vendor images. Now I notice this on RK3588 when using 5.10.160 (rk4.1 branch and up) kernel...

You did this on the remote server, right?

Claims. But that's it. Those are made and provided by 3rd party. Armbian cannot and will not provide support for such. https://docs.armbian.com/User-Guide_Getting-Started/#how-to-check-download-authenticity

moved to userspace

Tried adding a delay? https://stackoverflow.com/questions/43001223/how-to-ensure-that-there-is-a-delay-before-a-service-is-started-in-systemd

use armbian-config to freeze firmware packages. Then they will not be upgraded on regular apt upgrade.