Although /boot and / on mdraids pose no problem for grub, /boot/efi must be on a simple partition. This effectively makes UEFI and mdraid incompatible for root devices, because the loss of the “wrong” device would make the machine unbootable.
Some workarounds exist, but I’m not aware of a canonical solution to this problem.
I think maas should evaluate possible workarounds and implement one of them if believed to be solid enough, or at the very least try to prevent users from shooting themselves in the foot by being very clear that the combination / on mdraid and EFI booting is not recommended.
This is an issue for all operating systems no matter how they are installed, not just Ubuntu on MAAS.
On Linux systems the files in /boot/efi come from two packages, shim and grub. On Ubuntu these packages place their files in /usr/lib and grub-install moves them into /boot/efi. Under RHEL/CentOS shim and grub place their files in /boot/efi. Even if MAAS/Curtin copies these files the installed operating system has to have a way to keep the second copy insync when shim and grub are updated.
While the solution[1] above states “Luckily my UEFI boots without NVRAM entries, and I can disable the NVRAM writing via the “Update NVRAM variables to automatically boot into Debian?” debconf prompt when running: dpkg-reconfigure -p low grub-efi-amd64” we can’t rely on that. We need to ensure that EFI entries are properly set for both the primary and secondary /boot/efi locations.
Ubuntu always uses grub-install to install the shim and grub into /boot/efi. We could look into patching grub to allow the installation to target multiple paths. MAAS/Curtin would just have to create the mount points and add them to /etc/default/grub.
That being said I think this needs a larger cross team discussion so we can at least solve this for however Ubuntu is installed.