Comment 4 for bug 1792575

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).