Comment 11 for bug 1711203

I agree with Steve that installing linux-signed-image-generic as a default is best at the moment. Such kernels should boot whether or not Secure Boot is enabled, and AFAIK they'll even boot on BIOS-based computers (but I've not checked that, and there may be dependency issues on such systems). There is the caveat that this will increase the space used in /boot, which could cause out-of-space errors if /boot is a separate partition that's too small (see bug #1465050). I recommend 500 MB as a MINIMUM size for /boot these days.

If you want to detect whether Secure Boot is enabled, you can check the file /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c. If its sixth byte is 0x01, then Secure Boot is enabled. For instance:

$ hexdump /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
0000000 0006 0000 0001

Secure Boot is enabled on this system.

As Steve notes, though, the user might enable Secure Boot post-deployment, and if a signed kernel is not installed, the boot would then fail.

One more point: In the past, nodes deployed via MAAS have booted by MAAS's PXE server delivering GRUB to the node, and that GRUB then loading the GRUB on the hard disk. If this hasn't changed, it could be that Shim or GRUB is getting confused by this sequence. (Shim unloads itself after a handoff from one EFI program to another.)

If it would help for debugging this, I can give whoever needs it access to one of the affected systems.