Support aarch64 for GRUB and Limine EFI installation

[steev]

On aarch64 both the GRUB and Limine installers assume x86 and fail.

GRUB names its EFI target 'arm64', but platform.machine() returns 'aarch64', so passing --target=aarch64-efi is rejected. Map aarch64 to the arm64 target name expected by grub-install.

Limine ships architecture-specific default EFI binaries: BOOTAA64.EFI on aarch64 versus BOOTIA32.EFI and BOOTX64.EFI on x86. Select the correct binaries in the three places that reference them: when copying them into the ESP, when building the pacman hook that refreshes them on update, and when choosing the 64-bit EFI boot menu loader path.

Tests and Checks

• I have tested the code!
  

[h8d13]

I think a lot of other pieces assume x86 ? Like mirror handling and such

[theironrobin]

@h8d13 You are correct that the current official mirrors assume x86.

But archinstall works on an Arch Ports AArch64 system with this patch applied. See https://ports.archlinux.page/aarch64/
So if you are using their repos it works.

[h8d13]

Yeah I've gone into this path on rasp pi 5-b.

But it seems that if archinstall adds arm64 support they would have to patch this (and other things). And the current way of booting these isn't really exactly plug-and-play. Also adding complexity to bootloader code...

For instance on the pi5-b you had to replace kernel and boot-loader and more shenanigans

[steev]

Yeah I've gone into this path on rasp pi 5-b.

But it seems that if archinstall adds arm64 support they would have to patch this (and other things). And the current way of booting these isn't really exactly plug-and-play. Also adding complexity to bootloader code...

For instance on the pi5-b you had to replace kernel and boot-loader and more shenanigans

This isn't about adding arm64 support, it's simply fixing the assumption baked into the currently-supported bootloaders so that grub and limine install the correct files on arm64.

To be clear, this targets UEFI-compatible aarch64 devices, the same standard EFI boot flow x86 already uses, just with the correct target and binary names. On that kind of hardware there's no kernel/bootloader swapping or other shenanigans; it boots the way you'd expect. Especially once @theironrobin's archiso work is merged, it'll be basically plug-and-play.

SBCs are a different beast. At this time I have no interest in extending archinstall to support every SBC out there. Instead, I'd expect the person who wants archinstall working on their SBC to submit the fixes needed. The Pi 5-b situation you hit is exactly the kind of thing that's out of scope here.

[h8d13]

Fair, I'm all for it.

I just think its worth noting that workaround for the mirrors (noted by theironrobin above) since Select Regions would hard fail on this architecture.

[theironrobin]

@h8d13 I'd be willing to take a look at the Select Regions issue in a followup PR

[steev]

Fair, I'm all for it.

I just think its worth noting that workaround for the mirrors (noted by theironrobin above) since Select Regions would hard fail on this architecture.

I had noticed it, and we definitely need to change the hard coded path on the mirror to $(uname -m) or something, but I am not entirely sure how the mirrors work in Arch. Full disclosure that I wrote the patch to help @theironrobin get the iso building and installing the bootloader properly but I am a former Gentoo, Kali and current ParrotOS dev, not an Arch user/dev (yet)

[h8d13]

If i remember correctly the issue is with paths

archinstall/archinstall/lib/mirror/mirror_handler.py

Line 148 in b0bfb43

url=url.removesuffix('$repo/os/$arch'),

Because these mirrors don't use the same structure IIUC https://archlinuxarm.org/about/mirrors

url = url.removesuffix('$repo/os/$arch').removesuffix('$arch/$repo')

not an Arch user/dev (yet)

Come to the dark side

[h8d13]

I've merged (slightly modified) patch on testing fork: h8d13/archinstoo@c417a37

(and the mirror change + reflector service).

I'd be curious to see if it works properly on different ISA (but do not have the hardware available or ARM isos).

[theironrobin]

@h8d13 i tested master branch of archinstoo with my x13s iso:https://paste.rs/yCDPe
I had to manually run mkfs.ext4 on my partition. archinstoo had trouble with wiping my root, but once i did that,
at the bottom you will see that grub installs without error.

[svartkanin]

Checks are failing otherwise looks fine

[steev]

Checks are failing otherwise looks fine

Will fix that up now that I'm back at a PC and could see the failure.