Comment 4 for bug 1578837

I've done some more experiments. After booting in the normal MAAS way with Secure Boot disabled, I created an entry with efibootmgr to boot directly from the local hard disk, bypassing MAAS and its PXE boot. The system booted fine with this configuration, even after enabling Secure Boot. Thus, this is not a blanket Secure Boot issue; it has something to do with the handoff through multiple programs used by the MAAS configuration. (I expected this to be the case because the first GRUB delivered by MAAS booted OK; however, I know of at least one computer that ignores Secure Boot for network boots.)

I then modified /boot/grub/grub.cfg to add entries to chainload from the disk-based GRUB to itself, both directly and via the on-disk shimx64.efi. Both these entries failed, with the same message noted earlier:

/EndEntire
file path: /ACPI(a0341d0,0)/PCI(0,1)/PCI(0,0)/Ctrl(0)/SCSI(0,0)
/HD(15,800,100000,ae01bc523f0af546,2,2)/File(\efi\ubuntu)/File(shimx64.efi)/EndEntire
error: cannot load image.

(In the case of booting GRUB directly, of course, the message referenced grubx64.efi, not shimx64.efi.)

I then installed rEFInd on the system. This starts fine, and can redirect to grubx64.efi, which also starts fine and can launch a kernel; however, if rEFInd boots shimx64.efi, although a GRUB menu appears, GRUB refuses to load the kernel, with the following message:

Bootloader has not verified loaded image.
System is compromised. halting.

rEFInd can also directly launch a signed Linux kernel, but not an unsigned one. This is normal and expected behavior for rEFInd.

Thus, this appears to be a problem with shim verifying a second or subsequent image and/or with something in the way GRUB is launching chainloaded EFI programs. I ran into a similar problem with shim 0.8 and rEFInd, which I worked around with an ugly hack in rEFInd 0.9.2; however, I'm also reminded of bug 1091464, which has existed for much longer and that may be related to this problem. In that bug, GRUB is unable to chainload to Windows when Secure Boot is active. As the broken point here seems to be GRUB launching shim, the problem seems analogous.