Comment 7 for bug 1923268

When MAAS gets the TFTP/HTTP request for grub.cfg it doesn't know what the client architecture is. MAAS identifies the machine based on the requested URL. MAAS comes with a default grub.cfg[1] which tries loading /grub/grub.cfg-${net_default_mac} and if that fails /grub/grub.cfg-default-amd64. Machines which have been added to MAAS will match on grub.cfg-${net_default_mac} which already has the architecture defined in Postgres. During enlistment the machine is unknown so /grub/grub.cfg-default-amd64 is used. /grub/grub.cfg-default-amd64 always returns the kernel and initrd for AMD64.

This wasn't a problem previously on ARM64 because we were building an unsigned GRUB which embedded a grub.cfg that tried /grub/grub.cfg-${net_default_mac} then /grub/grub.cfg-default-arm64[2].

MAAS responds to the following:
1. grub/grub.cfg-<MAC> - MAC address in IEEE 802 colon-seperated format. There is a note in MAAS source that GRUB will only send MAC addresses in this format[1]. Due to this dash separated MAC is not supported.
2. grub/grub.cfg-default-<ARCH> - ARCH is a Debian architecture supported by MAAS(amd64, arm64, etc)
3. grub/grub.cfg - This simply tries 1 then 2.

While its possible to add support for other formats GRUB comes from the MAAS stream. We can't force existing users to upgrade.

[1] https://git.launchpad.net/maas/tree/src/provisioningserver/boot/uefi_amd64.py?h=2.9#n22
[2] https://git.launchpad.net/maas-images/tree/conf/bootloaders.yaml?id=10c44123886a03f828ee19675164ced83928ba27#n46