Comment 55 for bug 1711203

On Thu, Feb 22, 2018 at 11:06:51PM -0000, Jeff Lane wrote:
> > Is /efi/ubuntu/grubx64.efi on your EFI System Partition definitely the
> > Canonical-signed image from grub-efi-amd64-signed?

> I presume so? dpkg says it is:

> ubuntu@xwing:/boot/efi/EFI/ubuntu$ dpkg -S grubx64.efi
> grub-efi-amd64-signed: /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed

That doesn't establish that /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed
and /boot/efi/EFI/ubuntu/grubx64.efi match. Can you please verify that they
do?

> > Which version of Ubuntu's grub are you booting via pxe?

> ubuntu@xwing:/boot/efi/EFI/ubuntu$ dpkg -l |grep grub|awk '{print $2": "$3}'
> grub-common: 2.02~beta2-36ubuntu3.16
> grub-efi-amd64: 2.02~beta2-36ubuntu3.16
> grub-efi-amd64-bin: 2.02~beta2-36ubuntu3.16
> grub-efi-amd64-signed: 1.66.16+2.02~beta2-36ubuntu3.16
> grub-pc: 2.02~beta2-36ubuntu3.16
> grub-pc-bin: 2.02~beta2-36ubuntu3.16
> grub2-common: 2.02~beta2-36ubuntu3.16

> That is what is installed on the node.

Sorry, I was asking about the other end of this: what version of
grubnetx64.efi is being served by maas?

(But it is also good to confirm what version of grub is installed on the
node's disk.)

> So I re-enabled SecureBoot and removed all NICs from the boot order. I
> added in the HDD (since this is an EFI boot, the HDD is an entry called
> "Ubuntu" under "OTHER" in the boot order)

> This fails to boot, I get an error from the system:

> Error 1962: No operating system found. Boot sequence will automatically
> repeat.

> Because I have no NICs listed in the boot order, this just churns as it
> keeps retrying the HDD entry.

> So next, I went back and disabled SecureBoot once more. It immediately
> booted straight from the HDD.

> I also just tried a USB install with Secure Boot enabled. I was able to
> install bionic from USB, but it too fails to boot with the same error.

> To be fair at this point, given that this does work elsewhere, I'm
> suspicious that this is possibly an issue with my server.

Agreed. Something is wrong with the boot configuration of this node, which
is independent of the question of whether we have a viable workaround for
the netboot chainloading bug.