While doing some testing of multiple things I decided to build 2 images, fresh/new for my nanopineo's also trying to have the resulting image as close as possible to what I have running on the nanopineo's for years since 2022 or so. That was originally Armbian Buster and I have been tweaking the installations to match other computer installations. Main thing is split the root partitions into a rootfs (Btrfs) and a bootfs (Ext4). More recently, I did more changes, such that I can run the whole image as KVM and/or systemd-nspawn container. 

 

The 1st image was adding extension 'u-boot-menu'; build ended in success, but have not tested it on HW. I saw in extlinux.conf that there was no 'FDT' line (with  sun8i-h3-nanopi-neo.dtb), which I did ad myself in own extlinux testting/semi-automatic .conf generation, but as BOARD=nanopineo, the U-Boot can know a default to be loaded, or nothing at all as the DT in the U-Boot is likely good enough or almost the same as th eone from kernel, but maybe I test/challenge that later.

 

The 2nd image build was just 'u-boot-menu' replaced by 'grub-with-dtb':

cd /local/s0/armbuild/
sudo btrfs subvolume create nanopineo
sudo chown 1000:1000 nanopineo
cd nanopineo
git clone https://github.com/armbian/build
cd build
./compile.sh \
BOARD=nanopineo \
RELEASE=trixie \
BRANCH=edge \
BUILD_DESKTOP=no \
BUILD_MINIMAL=yes \
NETWORKING_STACK=systemd-networkd \
FIXED_IMAGE_SIZE=2G \
IMAGE_PARTITION_TABLE=gpt \
BOOTPART_REQUIRED=yes \
BOOTSIZE=256 \
BOOTFS_TYPE=fat \
ROOTFS_TYPE=btrfs \
BTRFS_COMPRESSION=zstd \
COMPRESS_OUTPUTIMAGE=sha \
EXTRAWIFI=no \
KERNEL_CONFIGURE=no \
KERNEL_BTF=no \
KERNEL_GIT=shallow \
ENABLE_EXTENSIONS=watchdog,net-systemd-networkd,uboot-btrfs,grub-with-dtb

It then fails with:

[🔨]   E: Unable to locate package grub-efi-armhf-bin
[🔨]   E: Unable to locate package grub-efi-armhf
 

The issue here is that the Debian package must be: grub-efi-arm

Also I now remember an issue from years ago when I made a non-EFI system UEFI bootable, must have been RPi thing or so, but also did it several times for x86. AFAIR if only grub-efi-arm and grub-efi-arm-bin, you get into trouble later on, can be years later when dist-upgrading in-place. So I just do 'apt install grub-efi' which then works fine as is pulls in also some dependencies. Not 'efibootmgr', that is just recommended, and I add that manually as most systems allow storing boot URL's in SPI-flash or so, certainly the KVM ones where machine is using EDK2 UEFI, which I use extensively.

 

So it seems to me that this is an architecture naming or aliasing issue, like we have amd64 vs. x86-64 vs. x86_64 and arm64 vs. aarch64

If just 'grub-efi' that also works for riscv I guess, so avoiding this naming/aliasing issue and also better future proof. It might be that dependencies are not supported in image building, I don't know enough about that to judge. I have also not looked in detail at size impact, but it is relative I would say. There is plenty of other issues that claim more space or can reduce way more. There were more issues, but I solved those via trial-error, no show-stoppers.

 

Although topic tag NanoPi-NEO, this is more like an Armbian Build issue, but for me it is about my 5 NanoPi-NEO's that are still great (and still overkill for their 4x Cortex-A7), but they are still Debian 32-bit ARMv7, not like unsupported RPi0/1 single-core ARMv6 (arm11* or older). A reason for wanting EFI bootloader is that upgrading/testing can by done in a KVM running on RPi4 (fast USB3-SSD) or ROCK3A (fast PCI-Ev3x2 NVMe) while using (differential) btrfs send|receive, which is way faster than on SD-cards en real HW. The other option is via U-Boot (QEMU -enable-kvm option), is supported for 64-bit in Armbian by BOARD=qemu-uboot-arm64, not for 32-bit.

 

I did some other test builds, 1 obvious thing is that FIXED_IMAGE_SIZE=2G should be FIXED_IMAGE_SIZE=2048, then image is 2GiB and not about 1.7G or so.

Other thing that boot partition was 260 and not 256 is now fixed by https://github.com/armbian/build/pull/11072

Due to that, I looked into grub.sh and after several trial-error and hacking/removing some line locally from grub.sh I got a successful build.

 

But as I already knew actually, a 128-entry GPT overlaps Allwinner H3 8k offset bootloader location. I did convert with gdisk to MBR but then partition error/not-found as grub looks for GPT, probably also a GUID and changing all to old MBR is possible I think, but might even need own grub compile, so no option. 

What works is to have or to convert the GPT to contain less entries, I set it to 16 (gdisk x or r menu then s). Then after sector 6 free space instead of sector 34.

 

Then some other mutual exclusive issue is that having grub assumes vendor/board UEFI FW like Dragon6 or a PC. Or special EDK2 for RK358.8 ROM-only tiny SBC's nee U-Boot in EFI mode in order to boot an EFI based installation. So I had compiled latest U-Boot (for its Btrfs Zstd compression fix on 32-bit sunxi at least) so just wrote that .bin file at the bootloader offset at 8k

 

Then SD-card started with the 2026.07 U-Boot build, seen via serial console cable and and nice blue kernel menu via screen in konsole on tumbleweed. Then next issue is the the Armbian sunxi 7.3.0.rc7 has no EFI_STUB, so rebuild kernel with that copied that so SD-card. Then it loaded the kernel and activity on the board, also ethernet active, but I did not see the blue grub menu anymore, it just booted the first entry silently after some seconds. No serial output at all, not more that this:

 

Booting: Label: mmc 0 Device path: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,0000000000000000)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,7200000000000000)/SD(0)/SD(0)
error: serial port `auto' isn't found.
error: terminal `serial' isn't found.
error: terminal `serial' isn't found.
  Booting `Armbian GNU/Linux, with Linux 7.3.0-rc7-edge-sunxi'

Loading Linux 7.3.0-rc7-edge-sunxi ...
Loading initial ramdisk ...
Loading device tree blob... /@/boot/armbian-dtb-7.3.0-rc7-edge-sunxi

But as this NanoPi-NEO has HW MAC-address reservation for mu DHCP server, IPv4 was know and I could ssh in as root with 1234. Then normal firstboot sequences so create user/password/localization etc. I think on another boot attempt I also saw 'com1' as serial port, so for sure something wrong there.

First reboot did hang, later reboots went fine, is somehow known to me. So it all went remarkably fine, taking into account the many tweaks and hacks. So the build line I used (on ROCK5B running Armbian Trixie with 7.3.0.rc5 rockchip64 kernel ATM):

cd /local/s0/armbuild/grubboots/build
git pull
git fetch origin pull/11072/head:pr-11072
git checkout pr-11072
./compile.sh build \
BOARD=nanopineo \
RELEASE=trixie \
BRANCH=edge \
BUILD_DESKTOP=no \
BUILD_MINIMAL=yes \
NETWORKING_STACK=systemd-networkd \
FIXED_IMAGE_SIZE=2048 \
BOOTPART_REQUIRED=yes \
BOOTFS_TYPE=fat \
ROOTFS_TYPE=btrfs \
BTRFS_COMPRESSION=zstd \
COMPRESS_OUTPUTIMAGE=sha \
EXTRAWIFI=no \
KERNEL_CONFIGURE=no \
KERNEL_BTF=no \
KERNEL_GIT=shallow \
ENABLE_EXTENSIONS=grub-with-dtb \
GRUB_FDT_FILE=sun8i-h3-nanopi-neo.dtb \
UEFISIZE=100

Unfortunately, after a few extra reboots, networking did not come online, and as the serial console went dead after kernel+initrd+dtb load, I have no clue why, at least no DHCP request visible in router. 

I have doen update-grub, various changes in console= statement w.r.t. 'serial', but that is current a major showstopper. It is similar frustration as with RPI boards with older BCM SoC only have 2 UARTs and RPL kept swapping because BlueTooth etc so getting mainline to work is endless fiddling with serial parameters (if you try U-Boot or EDK2 on RPI4 for example).

I also installed linux-image-armmp, but that did not boot. Not using the kernel package DTB did make LEDs blink differently, but no boot success. So my perception is that Allwinner H3 needs and uses many great Armbian patches in order to be usefull, which means it does not make sense (currently) to have 1 kernel that boots on both real HW and also in a KVM. So same as for RPI0-3 (when Raspbian), when the rootfs is booted in a KVM, select the generic Debian ARMv7 architecture kernel. For that I use apt pinning on Raspbian (as it is not ARMv7) but on Armbian 32-bit armmp can be installed in addition. When on real HW, I use extlinux folder on FAT (or just basic 1 kernel boot.scr), when in KVM with 32-bit EDK2 it sees EFI folder and uses BOOTARM.EFI and grub.

 

This also makes me think that it might be faster to improve scripting around qemu-system-aarch64 using U-Boot native loading instead of EFI-based. I have it for 64-bit, only text-mode/CLI of course. I use Btrfs enabled Armbian qemu-uboot-arm64, it had/has no issues with decompressing Zstd at least. There is no 32-bit variant of that, so I'll have to see how that would work. 64-bit is all no issue AFAIK, the rockchip64 kernels also include virtio drivers same as standard Debian arm64, so runs in KVM/virt-manager without issue, nice same 1 flavor kernel.

Maybe I do a similar build for rock-3a, disable SPI-CLK with jumper and then see if SD-card boots (when latest U-boot written to SD-card manually still).

After another power-on, first removing the y2k timestamped ubootenv.var which I thought maybe stores things and not waiting on boot, it turns out the board (still) comes online, just took much longer. It might be due to netplan using some other systemd-networkd config then my own .network files, so as minimal I did:

systemctl disable systemd-networkd-wait-online.service

that is a bit more relaxing.

But still no serial I/O

Then I saw my usual edits to /etc/grub:

GRUB_CMDLINE_LINUX_DEFAULT="loglevel=7"
GRUB_TERMINAL="serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"
where overruled by what is in: /etc/default/grub.d/98-armbian.cfg, especially GRUB_TIMEOUT=0, which makes you cannot select anything and that is reason I saw nothing when EFI compiled kernel. Earlier it just could not load the plain image kernel, so essentially the error menu. So the sledgehammer:

mv 98-armbian.cfg 98-armbian.cfg.disabled

systemctl set-default multi-user.target  # an SBC with no connector at all for a screen/monitor should not default to graphical.target, 'it is defacto headless'

Debian's default GRUB_TIMEOUT=5 is just too short in this case due to the error with 'com0' 'serial', I saw just a short flash of the grub menu, so made it 15

Also for GRUB_CMDLINE_LINUX_DEFAULT, 'splash' is not recognised and transferred to userspace. Plymouth I see as a real PITA, certainly purge all when CLI/headless, maybe it is 'plymouth.ignore-serial-consoles' that is the problem.
 

So then update-grub:

Generating grub configuration file ...
Found linux image: /boot/vmlinuz-7.3.0-rc7-edge-sunxi
Found initrd image: /boot/initrd.img-7.3.0-rc7-edge-sunxi
Found DTB path: /boot/armbian-dtb-7.3.0-rc7-edge-sunxi
Found DTB file, using it: /boot/armbian-dtb-7.3.0-rc7-edge-sunxi
Found linux image: /boot/vmlinuz-6.12.113+deb13-armmp
Found initrd image: /boot/initrd.img-6.12.113+deb13-armmp
Found DTB path: /boot/armbian-dtb-6.12.113+deb13-armmp
Found DTB file, using it: /boot/armbian-dtb-6.12.113+deb13-armmp
Adding boot menu entry for UEFI Firmware Settings ...
done

 

Reboot, then all normal, all U-Boot, grub menu, kernel log, finally login prompt.

 

Armbian-unofficial 26.11.0-trunk Trixie ttyS0  

ekker login: root
Password:  

root@ekker:~# cat /etc/update-motd.d/99-blank  
#!/bin/bash
echo ""
exit 0

 

This last thing confused me some months ago w.r.t. ssh login speed testing. After disabled all motd, still a linefeed, was not form ssh config or so, but this file. echo -n "" I would say, but maybe than other issues. The linefeed should be 'pre-' I think, not '-post' w.r.t. all the motd items. As brute force I just removed the whole folder as for almost exclusively unattended login normally, I anyway don't see what is displayed.

 

W.r.t.  ttyGS0 v.s. ttyS0, that is still unclear to me, but at least now I can select a kernel, also edit in grub menu to change a few things on command line ad-hoc etc, so much easier to test new kernels/configs (with or without DTB from kernel package).
 

 

 

 

To my surprise, the board also boots OK with the standard Debian Trixie 6.12.113+deb13-armmp kernel. Noticeable difference is quite a long pause between EFI_GRUB stub messages and kernel starting to spit out messages and that the red LED is constant on and green blinking as sort of activity. I prefer no LEDs on at all during normal operation, but this is a minor issue and likely some Armbian patch for sunxi puts them off. 

Of course Debian delivers no overlays, so the actual use-case is then 0, as I need analog-codec, SPDIF, 1-wire at leasta and some extra UART as well, all from the header pins, but it is great that it behaves now 'as a small UEFI Debian computer'.

53 minutes ago, eselarm said:

a minor issue and likely some Armbian patch for sunxi puts them off

I see it is actually a failure for the 7.3.0-rc7-edge-sunxi kernel (with my extra setting CONFIG_EFI=y), just full log from armbian-debug here: https://paste.armbian.com/ucitawavax
 

[ 1.526902] leds-gpio leds: error -EBUSY: Failed to get GPIO '/leds/pwr'

[ 1.526958] leds-gpio leds: probe with driver leds-gpio failed with error -16

 

and already: 

root@ekker:~# systemctl status armbian-led-state.service 
* armbian-led-state.service - Armbian leds state
     Loaded: loaded (/usr/lib/systemd/system/armbian-led-state.service; enabled; preset: enabled)
     Active: active (exited) since Fri 2026-10-23 14:03:16 UTC; 27min ago
 Invocation: b071139a57234fb7a65ef3dc88c4534d
    Process: 376 ExecStart=/usr/lib/armbian/armbian-led-state-restore.sh (code=exited, status=0/SUCCESS)
   Main PID: 376 (code=exited, status=0/SUCCESS)
   Mem peak: 1.3M
        CPU: 485ms

Oct 23 14:03:06 ekker systemd[1]: Starting armbian-led-state.service - Armbian leds state...
Oct 23 14:03:16 ekker armbian-led-state-restore.sh[376]: warning: /sys/class/leds/nanopi:blue:status/trigger could not be restored
Oct 23 14:03:16 ekker armbian-led-state-restore.sh[376]: warning: /sys/class/leds/nanopi:blue:status/invert could not be restored
Oct 23 14:03:16 ekker armbian-led-state-restore.sh[376]: warning: /sys/class/leds/nanopi:green:pwr/trigger could not be restored
Oct 23 14:03:16 ekker armbian-led-state-restore.sh[376]: warning: /sys/class/leds/nanopi:green:pwr/brightness could not be restored
Oct 23 14:03:16 ekker systemd[1]: Finished armbian-led-state.service - Armbian leds state.

So seems a matter of a new or wrong path for the leds or pins, where the older Debian kernel does is correct, also the leds config file is correct according to my understanding. Long time ago I disabled blue led of my rock-3a, so remenber a bit.

 

Probably I install current sunxi as well (6.18) and see what that does.

EDIT: sorry too fast, this won't work as it has no EFI enabled, so needs then booted via boot.scr or extlinux

Edited October 23Oct 23 by eselarm

Something happened to the file below while installing and remove packages:

root@ekker:/etc# stat armbian-leds.conf 
  File: armbian-leds.conf
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 0,28    Inode: 42402       Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2026-10-23 14:39:59.268000002 +0000
Modify: 2026-10-23 14:39:53.194144084 +0000
Change: 2026-10-23 14:39:53.194144084 +0000
 Birth: 2026-10-23 14:02:59.333152304 +0000
root@ekker:/etc# date
Fri Oct 23 15:10:41 UTC 2026

So now with empty file of course no leds problem. I will add snapper and change subvols so I can better track what is happening. 

Edited October 23Oct 23 by eselarm

11 hours ago, eselarm said:

Maybe I do a similar build for rock-3a

Done this, with the difference no local hacking grub.sh anymore as $ARCH=arm64 (so no failure where topic is about) AND this is with both PR#11072 (already merged) and PR#11084 in effect. The build option BOOTPART_REQUIRED=yes needs removed, so this:

 

./compile.sh build BOARD=rock-3a RELEASE=trixie BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=yes NETWORKING_STACK=systemd-networkd FIXED_IMAGE_SIZE=2048
BOOTFS_TYPE=fat ROOTFS_TYPE=btrfs BTRFS_COMPRESSION=zstd COMPRESS_OUTPUTIMAGE=sha EXTRAWIFI=no KERNEL_CONFIGURE=no KERNEL_BTF=no KERNEL_GIT=shallow ENABLE_EXTENSIONS=grub-with-dtb GRUB_FDT_FILE=rockchip/rk3568
-rock-3a.dtb UEFISIZE=100

 

succesfully generates the desired image. However, without detail knowhow about grub config revert to normal Debian, not a workable solution as terminal I/O is muted and grub menu skipped. As my real rock3a is busy/used (and also there is no (UEFI) bootloader build with the image), I started the image in a KVM I call 'armbian64' just swapping normally used image with this new build. The method is then to hit edit in grub menu and ad-hoc remove the devicetree line as that is for HW rock3a and KVM does not need any, just all virtio. But no grub menu, so same as for real nanopineo revert to standard Debian grub config with a few edits like loglevel=7. Then all fine. Good thing is that also this time, my VM is know by my router, so after with a bit of ssh wiping I could login as root:1234 and immediately fix the grub and serial stuff.

 

I think the idea behind this terrible grub config (for me) is to have the same as U-Boot boot.scr: no debug scrolling, hopefully a logo and no kernel selection. That seems fine if the boards only option is UEFI and no U-Boot or free open source bootloder (e.g. RPI), but people use grub so they can make selections at boot/power-on, not only kernels, but also multiple OSses. Maybe not for tiny 10-year old SBC's, but certainly for high end like RK35xx.