Comment 10 for bug 1711203

> Curtin/MAAS will install the linux-image-generic kernel for the specific
> release unless otherwise specified by MAAS in their kernel config mapping.

It should be noted that there are changes pending to the kernel packaging, such that installing linux-image *always* gives you the UEFI-signed vmlinuz, and you don't have to worry about having two copies of vmlinuz (signed and unsigned) installed to /boot.

However, in the meantime it would be best if curtin always used linux-signed-image-generic when installing on any UEFI system, so that the system isn't rendered unbootable if the user enables SecureBoot post-install. This is the current behavior of ubiquity and d-i.

None of this explains the behavior of an unsigned kernel failing to boot post-install. The current boot process is:
 - boot shim
 - verify signature on grub and boot it
 - if kernel signature verifies, boot it
 - if kernel signature does not verify, call ExitBootServices() and boot it anyway

This *will* be changing, and in preparation for this we have begun building and signing a separate grub.efi image which enforces kernel signatures: http://archive.ubuntu.com/ubuntu/dists/artful/main/uefi/grub2-amd64/current/gsbx64.efi.signed

However, we don't even package this in grub-efi-amd64-signed, it's only available for download from the archive. If maas or curtin are pulling this binary in at install time, instead of using the grubx64.efi.signed from the package, that's definitely a bug.

And if nothing is pulling gsbx64.efi.signed, then the bug is somewhere else but I'm not sure where. It's worth checking whether this problem mysteriously resolves once linux-signed is being pulled in; if it does, then it's possible we have a bug in grub (enforcing signature when it's not supposed to) or simply a bug in firmware.