UEFI CentOS 7 installs do not configure the shim

[Lee Trager]

The shim [1] is used by many GNU/Linux distributions including Ubuntu, CentOS, and RHEL to allow GNU/Linux operating systems to boot in a UEFI secure boot environment[2]. When MAAS deploys Ubuntu Curtin configures the system with efibootmgr to boot using the shim if network booting fails in the event MAAS is down. Curtin is not doing this for CentOS or is it configuring the shim in anyway(its not in /boot/efi like it is in Ubuntu).

Curtin Actions:
Modify the builtin CentOS/RHEL curtin hooks to configure the shim from the shim-x64 package.

MAAS actions:
Chainload the CentOS/RHEL shim when localbooting.

[1] https://github.com/rhboot/shim
[2] https://wiki.ubuntu.com/UEFI/SecureBoot

[Lee Trager (ltrager)]

By installing the shim.x64 package in the image /boot/efi/EFI/BOOT/BOOTX64.EFI, /boot/efi/EFI/centos/shim.efi, and /boot/efi/EFI/centos/shimx64.efi are all created. Curtin only needs to ensure shim.x64 is installed and it configures the nvram with efibootmgr to fall back on /boot/efi/EFI/centos/shimx64.efi

[Ryan Harper (raharper)]

Do you happen to know what the fallback entry should look like or what the call to efibootmgr should be to specify shim as the fallback in case no other entries work (ie, the pxe entry fails when maas is offline)?

[Ryan Harper (raharper)]

Not super happy about this. Shim-x64 is installed and provides the efi file.

grub2-install on centos/redhat doesn't automatically select the shimx64.efi file as the loader.

AFAICT, the only way to make this happen is to do this via efibootmgr:

% efibootmgr -c -w -L centos -d /dev/vda -p 1 -l \\EFI\\centos\\shimx64.efi

Will do the right thing, but the intial grub2-install creates an entry which needs to be removed which means finding the entry, deleting and recreating one. Additionally while we do know the disk (it's the grub target disk we get passed) it's not immediately clear what partition EFI is on, efibootmgr defaults to 1 but in curtin we could have this anywhere on the GPT layout.

it's a real shame that grub2-install can't take a loader parameter when it's updating nvram.

We could pass the no-nvram update to grub2-install which would prevent creating the entry; but we still need to look up the right disk and partition values.

This will take a bit more time to sort out a clean way to do this.

[Lee Trager (ltrager)]

I was able to add grub2-efi-x64 and shim-x64 to a CentOS image and successfully deploy using MAAS 2.6.0-rc1. I confirmed that the signed boot loaders were used post deployment. I've been unable to test this in a secure boot enabled environment as turning on secure boot with the machines in our CI requires physical access[1].

grub2-efi-x64-modules are still being installed by Curtin even though they are not needed for secure boot. We need to decide whether Curtin should be patched to require the correct packages or if both should be included.

lp:maas-images creates one CentOS image for the v2 and v3 stream. We also need to validate this change will not break any older version of MAAS.

[1] https://support.hpe.com/hpsc/doc/public/display?docId=mmr_kc-0123776

[Lee Trager (ltrager)]

This should be fixed with the attached branch.

[Server Team CI bot (server-team-bot)]

This bug is fixed with commit 1be1cd71 to curtin on branch master.
To view that commit see the following URL:
https://git.launchpad.net/curtin/commit/?id=1be1cd71