Comment 36 for bug 1711203

That's not going to change anything -- grub is doing exactly what it should: ask shim to validate the image it tries to chainload; and the image *does* validate successfully. The chain of trust is technically preserved, but shim doesn't manage to make sense of things, and refuses to continue loading.

This is a "bug" in shim, in that it's not a use case that was anticipated. Shim makes sense of the shim->fallback->shim->grub case because in that case things do go through the steps of calling load_image() and start_image() in firmware.

It also seems to me like a bug in grub because we ought to be loading things in such a way that shim would be able to make sense of it -- currently, that's not quite the case because some relocations and other image mangling needs to happen. I have an idea of a hack to fix this, but I think the "right" fix would be in shim.

What happens is that given that load_image() isn't called directly, when the second shim runs it doesn't uninstall the protocols and we end up validating against the first loaded shim when we try to verify the kernel's signature. This is effectively a variation on an issue that was fixed in shim for the fallback EFI binary.

In the meantime, there's also a valid workaround: you should be able to chainload *grub* rather than shim from the disk, and thus maintain the chain of trust for Secure Boot:

menuentry 'Local' {
 echo 'Booting local disk...'
 search --set=root --file /efi/ubuntu/grubx64.efi
 chainloader /efi/ubuntu/grubx64.efi
}