eselarm

Standard Debian; select what you want when you run: sudo tasksel

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.

There is a separate boot partiton, it should be there. MACOS same as Windows might hide/block it as it is tagged as not normal filesystem (0x8300) but boot related (0xea00 or 0xef00) Linux has no issue with it.

You could use the Cubie for it. The trunk.100 works you said, so you have a working Linux computer, can be operated via serial cable console.

For you, 'make an image' means downloading a file from Armbian website and write it to an SD-card. For me, 'make an image' means using the Armbian build environment https://github.com/armbian/build to create an image yourself locally on your computer. This is what 'make an image' is. Already 2 people including myself showed that GPT is corrupted in the image file on the Armbian website. You can assume that the bootloader when run on the board itself also detects that, so it won't boot/proceed. So something goes wrong in the Armbian build infrastructure. However, that is what I assume. So up to you confirm by showing the logs of the bootloader. You need serial console cable for that, so you can copy and paste for sharing that log here on the forum. Other option, a step further ahead, is to make an image yourself. You need a Linux computer/environment for it. It also shows very detailed logs, share that.

I dumped all your text in ChatGPT and got enough answers; maybe do the same

I now actually see after some more reading and checking other SoC's that the CPU's in the A733 must start the kernel at EL2. See also ARM reference doc: 102412_0103_01_en So also 5.x kernel should work if EL2 I think If the A733 has not implemented EL2 and EL3 as could be the case as suggested in ARM reference doc, no KVM. See chapter6: As it is Allwinner, I won't be surprised, but wait and see what Radxa will come up with.

Have you also looked at the clocks? I have several NanoPi-NEO's (since around 2021 I think), H3 SoC, never had any overheating issues. I actually did some measurements recently and surprisingly low power, I had expected more. Clock stays at 480 mostly. I see the Duo2 is H3, Duo I don't see on FriendlyElec's site. But quite different HW/board. Only thing I could think of maybe is that I removed ( apt purge --autoremove) cpufrequtils after in-place upgrade from Bookworm to Trixie. Have not looked at it any further, it just is not in my vanilla Debian Bookworm -> Trixie, so just blind purge I thought. Still all fine, also with 6.18 kernel: # uname -a Linux raspi2 6.18.2-edge-sunxi #1 SMP Thu Dec 18 13:03:43 UTC 2025 armv7l GNU/Linux # cat /sys/class/regulator/regulator.?/microvolts 3000000 3300000 5000000 1100000 # cat /sys/class/thermal/thermal_zone0/temp 27116

May boot from new / known-to-work Armbian on SD-card and use command: sudo lsblk and/or sudo lsblk -f to see what is what. mmcblk numbers have swapped sometime in the past years, so indeed even if you know enough about Linux, mixing numbers might be a disater because you would overwrite the runnig installation. That might also be a reason why tooling might refuse or not list as there is a risk of having it wrong. But you should clean-up the 100% full filesystem. It will take time figuring out what should be deleted, but so does going to the toilet as well. It has to be done, cannot assume there is endless space.

Radxa staff actually does not answer the original question w.r.t. Allwinner A733 HW virtualization, it is just that kernel config has it. But I see from releases 'bullseye', that does not look good at all. In theory, that means 5.10 kernel, and oldoldstable libvirtd/KVM/QEMU etc. As this SoC is bigLITTLE, (Cortex-A76 Cortex-A55), starting a qemu-system-aarch64 process will pick some of those cores randomly, assuming you have more than 1 vCore (smp option > 1) . Kernel older than 6.8 or so does not support moving between an A76 and an A55. That is the same for Rockchips (RK3588). It took me quite a while before I discovered that this is known behavior. So on for example on vendor rk35xx 6.1.115, I pin vCPUs, can be done in virt-manager GUI xml config or cmdline via taskset. As easy test, use -smp 1, then it should work. mainline kernel CPU numbers are such that simplest/lowest CPU's get lowest number. That might be the other way around on 6.1 or older downstream/vendor/BSP kernels. On an RK3588, a 2-core VM with 2x A76 and 512MiB is done by: taskset --cpu-list 6-7 qemu-system-aarch64 -M virt -cpu host -enable-kvm -m 512 -smp 2 \ -bios u-boot.bin \ -drive if=none,file=armbian.img,format=raw,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -netdev bridge,id=hn1 -device virtio-net,netdev=hn1 \ -nographic Same should work on A733

log says: No space left on device So you need to look at that, remove unneeded stuff etc. Also check the output of df Maybe something else is wrong

OrangePi in general is bad support, as also is stated on the image download page. For just driving a relay, so a pin change between high and low, you first need to select which pin from the GPIO header you want to use. You can see what are probably generic GPIO by default from picture here: http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-Zero-2W.html In the latest image, I see there is no real support for OrangePi02W, only H5 and A64, not the actual H618 (it seems to use H616, so also that might lead to issues). You can look in file maybe, if you want other then defaults: /boot/dtb/allwinner/overlay/README.sun50i-H5-overlays I have older 32-bit Allwinner things, H3 for example. Analog and SPDIF audio works great there, that is why I bought those mainly. Also GPIO6 I use for driving a switch (via extra resistors and some MOSFET/TRIAC). I did some C-code and got working temp sensor and switch, see lgio code https://abyz.me.uk/lg/download.html But currently for years already in bash script: init: test -f /sys/class/gpio/gpio6/value && echo 6 > /sys/class/gpio/unexport echo 6 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio6/direction chown root:gpio /sys/class/gpio/gpio6/value chmod g+w /sys/class/gpio/gpio6/value on: gpioset gpiochip0 6=1 off: gpioset gpiochip0 6=0 This still works since Armbian Buster, now kernel 6.12. Not tested yet with 6.18

You have to allocate the I/O pins you want to use and how you want to use them yourself, can be done in armbianEnv.txt. A generic image cannot know what you want and what is connected to which I/O pins. GPIO is not like USB or PCIe that is can be automatically let its connected hardware enumerate. Also old Linux behavior w.r.t. GPIO is gone. You fundamentally need to open it, keep it operational with handle, in your code. Like you open a file when you want to read or write. Python might do that for you, but for C-code maybe look at lgio. So maybe tell first what you want to achieve, is it a temperature sensor maybe, or control a MOSFET or relay, etc.

There is at least no primary GPT, all zeros from 0x200-0x20000 Fixed with: # gdisk Armbian_community_26.2.0-trunk.130_Radxa-cubie-a5e_trixie_edge_6.18.2_minimal.img GPT fdisk (gdisk) version 1.0.10 Caution: invalid main GPT header, but valid backup; regenerating main header from backup! Warning: Invalid CRC on main header data; loaded backup partition table. Warning! Main and backup partition tables differ! Use the 'c' and 'e' options on the recovery & transformation menu to examine the two tables. Warning! Main partition table CRC mismatch! Loaded backup partition table instead of main partition table! Warning! One or more CRCs don't match. You should repair the disk! Main header: ERROR Backup header: OK Main partition table: ERROR Backup partition table: OK Partition table scan: MBR: protective BSD: not present APM: not present GPT: damaged **************************************************************************** Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk verification and recovery are STRONGLY recommended. **************************************************************************** Command (? for help): w Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!! Do you want to proceed? (Y/N): y OK; writing new GUID partition table (GPT) to Armbian_community_26.2.0-trunk.130_Radxa-cubie-a5e_trixie_edge_6.18.2_minimal.img. Warning: The kernel is still using the old partition table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) The operation has completed successfully.

OK, I have the following in my test NanoPi-NEO (using 6.18 kernel): U-Boot SPL 2024.01-armbian-2024.01-S866c-P7738-Ha5c2-V2b78-Bb703-R448a (Mar 09 2025 - 03:54:42 +0000) Same base, but it is older and anyway different hardware, although H3 SoC. I have no more ideas why you need that extra kernel cmdline statement. I think I have seen it as well for another board/SoC, but does not ring a bell.

I do not see something clearly wrong, but likely is is a newer U-Boot, maybe something wrong there; version in SD-card you can show with: dd if=/dev/mmcblk0 count=32k status=none | strings | grep "U-Boot SPL"

I think it must be /boot/armbianEnv.txt Besides that, I never had this issue with my 5 NanoPi-NEO boards, originally Armbian Buster, always in-place upgraded. Also 1 now tested with kernel 6.18, now issues. So I think you maybe need to look at what U-Boot you use, what kernel is it and logs ( all via armbianmonitor -u )

That the Helios64 SW/firmware did sequencing of 3.5inch HDD spin-up is indeed a good method to limit the maximum current draw. I do not know how power architecture is done in Helios64, but w.r.t. 3.5inch disks, so the 12V power need, you might avoid letting the current of the 12V flow through the SBC/motherboard. It is not needed, there might be connectors, still it is not needed. Even for traditional x86 PCs, 12V (and 5V as well) comes straight from the PSU, that is 100-1000W or so usually. The 12V also does not need to be exactly 12V, I feed a 4TB WD HDD from a 12V car battery in the field, is solar powered and 10 years old or so. Due to battery wear out, it sees a voltage of 10.5-14 Volts or so. No problem. 5V for SBC and some other small stuff is via a 3A DC/DC module. A car battery (72Ah or so) should have no issue with spinning up a handfull of 3.5inch HDDs simultaneously. The PCIe-to-SATA chips support hotplug, so you could use some P-MOSFETs or so to have GPIO-controlled powerswitch, but is of course electronics circuit design and soldering etc. Also maybe think if you need all that 5 HDDs (and at the same time) and with a RK3588 SoCo that can go as low as 1.5Watt idle. 5 spinning disks is 20W or so.

My NanoPi-R6C came with FriendlyWRT pre-installed (OpenWRT variant) and I bought it 2 years ago partly also because I had a Samsumg 970 Evo NVME that needed a computer wrapped around it. I do not use images, instead root-filesystems (Btrfs). I Initially kept the FriendlyElec U-Boot, with all rest on NVME. Now still use the same principle, but EDK2-UEFI v1.1 as bootloader in eMMC and Armbian Trixie or Opensuse Tumbleweed with Armbian kernel and grub-efi. With latest u-boot (2026 rc2) I get no HDMI audio. I thought it was a power/reset issue, but also later tested again with complete un-powering first, but then also no HDMI audio. It might simply be a latency issue. Both older U-Boot and even much older FriendlyElec U-Boot as well as EDK2-UEFI initialize HDMI before the kernel and do simple 1080p60, so you also see the kernel being loaded, before KMS (re)-inits the HDMI. EDK2-UEFI has GUI for its settings, so no surprise it works there. For Jellyfin, I currently use a ROCK5B Armbian Trixie with Armbian vendor 6.1.115 kernel (also EDK2-UEFI bootloader). There were some issue with Jellyfin strreaming/transcoding, also on N100, I currently don't know why/what. The jellyfin-ffmpeg via CLI works great though, so about 5x realtime transcoding HEVC->H264. But Firefox on N100 or x5-Z8350 uses HEVC HW decoder, so no real need to do transcoding for me. LibreElec a month ago or so on NanoPi-R6C temporary booted from SD-card did do HW decoding OK, except for VP9 it was artifacts, not usable actually. So there is unfortunately no easy 1-size-fits-all currenlty. You can scan the forum, there are people who took unfinished patches and use very latest unstable Debian stuff, then things might work same as for x86.

If this fails on multiple build host environments, maybe check your network/internet connectivity. Else I don't really know what could be the cause. I use Armbian Aarch64 (RK3588s) with various tweaks ans kernels and it works fine for builds.

This suggests it is 5V only and also no USB-C PD. You should power a ROCK5 with higher voltage, then no issues, at least that is my experience and is also what you can see if you look at schematics. You can also read the end-user docs/wiki. ROCK3A, ROCK5B, NanoPi-R6C all have own step-down DC/DC converter on the board itself. The latter one for example has an 8A component for it. So it can make enough power from 20 or 15 Volt input at a perfect 5V internally for USB devices on its type-A ports, and also easily maintain its 3.3V and lower voltages for CPU etc. OrangePi is cheap, same as RaspberryPi. Those shift the powering (issues) to the end-user, meaning you need a stable enough 5V on the USB power input connector. A slight voltagedrop can lead to problems. But board itself is cheap. RPi5 requires a quite rare 5A capable 5V USB-C PD (RPI5), where the ROCK3A/5B can just be fed from any voltage between 9 and 20 Volt (see docs/wiki). If you use 5V, the on-board DC/DC step-down cannot do its work of course, so essentially bypassed. Why did you buy a ROCK5 then. Same as buying a car with combustion engine with empty fuel tank, instead put a horse in front to pull you forward from A to B. (Or get a bicycle). The (extra) horse is the 27W Pi5 PSU here, costed me 18 Euros, half the price of the ROCK3A. I put a fixed 12V on a USB-C connector, from an old card battery, that by itself is kept at about 12V by a 12V/10A generic powerbrick. Is also UPS then is no 230VAC mains. The Nanpi-R6C with latest U-Boot and latest mainline kernel does also do USB-C PD, so with a generic 45W USB-C PD PSU, is flips automatically to 15V on its USB-C input. With another 60W USB-C PD PSU it was 20V. ROCK5B should be able to do the same, but haven't tried as run 24/7 for months as home/house server.

Mainline 6.18 or 6.19 does only decoding accelerated, not encoding (yet) what is to great benefit of Jellyfin. Also for that transcoding, Jellyfin uses RKMPP, not V4l2. So 6.1.115 vendor kernel is what I use on the Jellyfin server (headless). For desktop RK3588, I use mainline 6.18.2 at the moment, brute force SW decoding, that works for me as content is max 1080p60 (HEVC or VP9 or H264).

See here, HW description bulletpoint 17 https://www.hardkernel.com/shop/odroid-m1s-with-4gbyte-ram/ Maybe it is also available on the 40-pins or 14-pins I/O headers, so a simple generic USB serial cable with jumper wires can be connected.

If this is something with languages: I remember Armbian has a preferences option in apt config somewhere 'no languages'. Is old memory, maybe changed nowadays. Maybe a hint where to look and what to try. It would actually be a Cinnamon issue then.

What is booted also depends on boot scripts (and what is in armbianEnv.txt). This might have changed. And also the U-Boot code on the SD-card (sits invisible between partition table and 1st partition, usually sector 34-32767) might be newer and assume other defaults, I don't know. You need serial console cable and loglevel set to 7 so you can see what is happening after power-on. But maybe something else is wrong, at least make sure you post relevant info here on the forum. You can look in /usr/lib/u-boot/platform_install.sh to see where U-Boot is written. Also if you look there you can find some version string, likely in your mtd0/SPI is older than on the SD-card.