[Bug 1792575] Re: Boot failure with efi shims from 20180913.0

[Andres Rodriguez]

Just to provide some more context

1. Machines were deployed with Xenial and bootloders from image streams
version 20180906, which was using an older shim (versions as per "a"
below)

2. The shim has been updated in the ubuntu archive for cosmic and
bionic, but for xenial they still in -proposed (new version as per "b"
below).

3. MAAS automatically updated to newer bootloaders in 20180913 streams,
using the latest from bionic-proposed (see "b" below for details)

4. The machine was rebooted, upon reboot, the new boot fails were unable
to chain into the installed systems files. The installed system (in
Xenial) had older version of the shim, where as MAAS, had a newer
version of the shim (from Bionic).

Looking at the MAAS streams that provides the bootloaders [1] I can see
that:

 a) 20180906.0 is using bionic's grub2-signed (1.93.5+2.02-2ubuntu8.4) and shim-signed (1.34.9.2+13-0ubuntu2)
 b) 20180913.0 is using bionic's grub2-signed (1.93.5+2.02-2ubuntu8.4) but it is using a different shim-signed (1.37~18.04.1+15+1533136590.3beb971-0ubuntu1)


[1]: https://images.maas.io/ephemeral-v3/daily/streams/v1/com.ubuntu.maas:daily:1:bootloader-download.json

That said, I would have thought that:

1. using a newer shim/grub2-signed, it should be able to chainload into
an older shim/grub2-signed?

I'm adding a task for the 'shim' package to get this question answered
and find out whether a shim update should be able to chain into an older
shim version (or viceversa).

** Also affects: shim (Ubuntu)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to shim in Ubuntu.
https://bugs.launchpad.net/bugs/1792575

Title:
  Boot failure with efi shims from 20180913.0

Status in MAAS:
  New
Status in shim package in Ubuntu:
  New

Bug description:
  We have had several nodes that had been deployed on Sept. 12 and were
  booting correctly fail to boot.

  On the console and during tracing we could see they were getting dhcp
  and pxe information, but then errored out with "relocation failed",
  dropping into a fallback grub menu with a Local boot option.

  After copying over bootx64.efi grubx64.efi from
  https://images.maas.io/ephemeral-v3/daily/bootloaders/uefi/amd64/20180906.0/
  instead of 20180913.0/ and rebooting, boot would commence
  successfully.

  Hardware: Dell R640
  maas 2.3.5-6511-gf466fdb-0ubuntu1~16.04.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1792575/+subscriptions