UEFI CentOS 7 installs do not configure the shim

Bug #1788088 reported by Lee Trager
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Invalid
High
Lee Trager
curtin
Fix Committed
Wishlist
Lee Trager

Bug Description

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

Related branches

Changed in maas:
importance: Critical → High
Lee Trager (ltrager)
summary: - UEFI CentOS 7 installs do not configure the shim
+ UEFI CentOS 7 installs does not configure the shim
summary: - UEFI CentOS 7 installs does not configure the shim
+ UEFI CentOS 7 installs do not configure the shim
Revision history for this message
Lee Trager (ltrager) wrote :

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

Changed in maas:
milestone: 2.5.0alpha2 → 2.5.0beta1
Revision history for this message
Ryan Harper (raharper) wrote :

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)?

Revision history for this message
Ryan Harper (raharper) wrote :

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.

Changed in maas:
milestone: 2.5.0beta1 → 2.5.0beta2
Changed in maas:
assignee: nobody → Lee Trager (ltrager)
tags: added: sprint
Changed in maas:
milestone: 2.5.0beta2 → 2.5.0rc1
Changed in maas:
milestone: 2.5.0rc1 → 2.5.x
Ryan Harper (raharper)
Changed in curtin:
importance: Undecided → Wishlist
status: New → Triaged
Changed in maas:
milestone: 2.5.x → 2.6.0rc1
Changed in maas:
milestone: 2.6.0rc1 → 2.6.0rc2
Revision history for this message
Lee Trager (ltrager) wrote :

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

Changed in maas:
milestone: 2.6.0rc2 → 2.7.0alpha1
Changed in maas:
milestone: 2.7.0b1 → 2.7.0b2
Revision history for this message
Lee Trager (ltrager) wrote :

This should be fixed with the attached branch.

Changed in curtin:
assignee: nobody → Lee Trager (ltrager)
status: Triaged → In Progress
Changed in maas:
status: Confirmed → Invalid
Revision history for this message
Server Team CI bot (server-team-bot) wrote :

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

Changed in curtin:
status: In Progress → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.