image build fails on grub-efi install

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.