2

Before proceeding I don't want to disable the Secure Boot option. I need a solution, not a workaround.

I have a humble setup using dnsmasq and the dnsmasq built-in tftp to give me a PXE server. I am trying to boot Ubuntu 22.04.

Setup:

I followed the official Ubuntu tutorial.

Initially I had problem with bootx64.efi as the NUC reported a boot violation, but the trick was to basically use the bootx64.efi.dualsigned to create the bootx64.efi. This is the result of sbverify on bootx64.

have a look here

This solved the problem of boot policy violation and the pxe boot process successfully starts grub. I don't know how as the sbverify fails on this file.

have a look here

After I select from grub which ISO to run this is the error message I get

have a look here

I don't know if this is the problem with grub or the actual signature of vmlinuz.

have a look here

Without turning off Secure Boot how do I sign the kernel image with the correct and update signature or the grubx64.efi to make this work? Is there a way to do this with sbattach command (don't I need the actual public certificate for that) where can I find this certificate?

karel
  • 122,292
  • 133
  • 301
  • 332
Mubeen
  • 41
  • 1
  • 1
  • 7

1 Answers1

2
  • The answer to your question is in the output of the various sbverify --list commands you ran.
  • As listed in the output of the command for vmlinuz, it is signed using Canonical Ltd. Secure Boot Signing (2017)
  • The grub loader is signed using the Canonical Ltd. Secure Boot Signing (2022 v1)
  • Sometime in 2022, Canonical started using Canonical Ltd. Secure Boot Signing (2022) to sign keys and revoked the Canonical Ltd. Secure Boot Signing (2017) key. This ended up being added to the DBX (Secure Boot Forbidden Signature Database) (which is part of the secure-boot storage in BIOS, and updated regularly).
  • To fix, you just need to update the kernel (and matching initrd) being served via tftp to one signed using Canonical Ltd. Secure Boot Signing (2022).
Samveen
  • 288