If the file is not in /boot could you have accidentally deleted it? Maybe try recreating it. In general, if you have boot problems you should attach a serial to USB cable and see what uboot is saying.

Ok, as promised with a report. Current setup - NanoPi R6S - Armbian Debian trixie minimal edition, with Kernel 6.1.115 - LXQT (using X11) - Jellyfin (installed via Jellyfin website instructions, NOT using armbian-config as that sets up docker and then makes it more opaque to run it with external media) - firefox Results - Jellyfin, accessed via apps for various SmartTVs (Google Chromecast, Amazon TV, etc), runs super smooth with 4K videos, indicating functioning hardware decoding. NanoPi stays very cool even for 4K transcodes. - Firefox video playback has to, like @eselarm already said, resort to software decode. NanoPi is able to play smooth up to HD level videos in firefox, but it gets pretty hot. Comments I suppose that getting firefox hardware accelerated video decode is further out of reach now that ffmpeg has DMCA-taken-down the rockchip-mpp github repository...but what do I know. I am wondering if running LXQT with wayland would offer improvements, but I am not sure it's worth the effort. I am a relatively happy camper with this setup.

I do not know how to fix that key / verify signature issue. It might be there because of earlier diskfull. I only know I needed new keyrings, listed in the armbian list files when I did the in-place upgrade from bookworm to trixie. There is a formal method for that I think, might be here on forum. I however did copy various things from a new Armbian Trixie image. E.g. new file is now: -rw-rw-r-- 1 root root 2297 Aug 31 22:15 /usr/share/keyrings/armbian-archive-keyring.gpg ~# sha256sum /usr/share/keyrings/armbian-archive-keyring.gpg 9d0ab1676008004f1ee0bfc0f99a6043544d8bb6df3d949f9bd30066246f9095 /usr/share/keyrings/armbian-archive-keyring.gpg For Docker problem: I don't use Docker, I have no clue why that file keeps growing.

From my experience with trunk 130 the gmac is working on both ports. Wifi is not always working, sometimes a reboot may make the wifi to work. There is no USB 3.0 and HDMI is not working either. Running gdisk armbian.img made it bootable. The easiest way to run this command for me was from WSL.

After having this happen again and investigating further, it looks like my container for transmission is writing to a log file that is just ballooning bigger and bigger until the system crashes. root@modron:/var/lib/docker/containers/899f42253bb7772351219b7a65ff21347455f11950f983fb7a8883c6b93cdb17# ls -al total 101656680 drwx--x--- 4 root root 4096 Dec 27 22:28 . drwx--x--- 22 root root 4096 Dec 27 22:28 .. -rw-r----- 1 root root 104095768576 Dec 31 15:08 899f42253bb7772351219b7a65ff21347455f11950f983fb7a8883c6b93cdb17-json.log drwx------ 2 root root 4096 Dec 27 22:28 checkpoints -rw------- 1 root root 5949 Dec 27 22:28 config.v2.json -rw------- 1 root root 1776 Dec 27 22:28 hostconfig.json -rw-r--r-- 1 root root 13 Dec 27 22:28 hostname -rw-r--r-- 1 root root 172 Dec 27 22:28 hosts drwx--x--- 2 root root 4096 Dec 27 22:28 mounts -rw-r--r-- 1 root root 336 Dec 27 22:28 resolv.conf -rw-r--r-- 1 root root 71 Dec 27 22:28 resolv.conf.hash I'm not sure what this file is. Tailing it prints this out, and I'm worried trying to load it into memory with less would cause a crash: {"log":"[warn] Error from accept() call: No file descriptors available\n","stream":"stderr","time":"2025-12-31T20:06:58.854663511Z"} {"log":"[warn] Error from accept() call: No file descriptors available\n","stream":"stderr","time":"2025-12-31T20:06:58.854793008Z"} {"log":"[warn] Error from accept() call: No file descriptors available\n","stream":"stderr","time":"2025-12-31T20:06:58.855042376Z"} {"log":"[warn] Error from accept() call: No file descriptors available\n","stream":"stderr","time":"2025-12-31T20:06:58.855144456Z"} {"log":"[warn] Error from accept() call: No file descriptors available\n","stream":"stderr","time":"2025-12-31T20:06:58.855165456Z"} {"log":"[warn] Error from accept() call: No file descriptors available\n","stream":"stderr","time":"2025-12-31T20:06:58.855213288Z"} {"log":"[warn] Error from accept() call: No file descriptors available\n","stream":"stderr","time":"2025-12-31T20:06:58.855254412Z"} {"log":"[warn] Error from accept() call: No file descriptors available\n","stream":"stderr","time":"2025-12-31T20:06:58.855304285Z"} {"log":"[warn] Error from accept() call: No file descriptors available\n","stream":"stderr","time":"2025-12-31T20:06:58.855320618Z"} {"log":"[warn] Error from accept() call: No file descriptors available\n","stream":"stderr","time":"2025-12- I've been running the 4.0.5 branch of the linuxserver.io container for transmission, I'm updating to their "latest" branch and seeing if that improves anything.