Support root on software raid in UEFI mode

[Andrea Ieri]

[converted from a discourse RFE as after discussing this further internally, it's something that sits at the edge between feature request and bug]

Although /boot and / on mdraids pose no problem for grub, /boot/efi must be on a simple partition as UEFI firmware implementations are not expected to be able to understand anything else than FAT.
This is however effectively making UEFI and mdraid incompatible for root devices, because the loss of the "wrong" device would render the machine unbootable.

Some workarounds[0] exist, but I'm not aware of a canonical solution to this problem.

Given how legacy booting is, well, "legacy", I believe it is important to determine what the way forward for UEFI + root on sw raid should be:

1. can a safe official workaround be implemented within MAAS?
2. can a safe workaround be implemented, but should that be done by another product?
3. is it just technically impossible to support UEFI + root on sw raid?

If the conclusion were to be "3", MAAS should disallow the unsafe legacy boot + / on mdraid combination, and this bug should be closed with a clear 'won't fix' that we will be able to reference to when discussing cloud design with customers.

[0] https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/

[Michał Ajduk (majduk)]

At the moment following workaround is provided:
Install subordinate charm cs:~majduk/efi-manager on baremetal machines. The charm automates process described in [1].

[1] https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/

[Lee Trager (ltrager)]

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.

[Björn Tillenius (bjornt)]

I actually thinks that this do belong in the discourse post:

  https://discourse.maas.io/t/support-root-on-software-raid-in-uefi-mode/1079/2

I'm going to close this bug in favor of that, so that we keep the discussion in one place.

The way I see it, it's not much MAAS can/should do until the packages in Ubuntu fully support running with the EFI partition on software raid.