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
}
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1711203/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
