grub version 2.04 in Eoan today won't boot windows.

[rhenwood-arm]

For reference: If you update to the Eoan today (Ubuntu 19.10), the version of grub you get (2.04) won't boot a windows partition if it is present on the laptop.

I fixed this using this PPA to install 2.02 version that is known to work: https://launchpad.net/~aarch64-laptops/+archive/ubuntu/grub

After a recent search, I see there is a 2.04 for Eoan from Xnox -- which I haven't tried but might be a better option. https://launchpad.net/~xnox/+archive/ubuntu/aarch64-laptops?field.series_filter=eoan

[lag-linaro]

I submitted a bug for this. It has been upgraded to critical.

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1839317

[cyphermox]

Bug was noted. I'll get to it as soon as possible (I just didn't really happen to have hardware on which I could test this, now I possibly do).

[lag-linaro]

Thanks @cyphermox - I'm also happy to help with testing now I'm back from vacation.

[lag-linaro]

With set debug="chain,secureboot,dl" added to the Grub menu entry, we get a flash of:

SecureBoot: 0
SetupMode: 0
linuxefi_secure_validate: 1
No shimlock protocol loader/efi/chainloader: Secure boot is not enabled

Looks like Grub is insisting on Secure Boot, which we need to disable in order to boot Linux.

[xeron]

Diff between disco and eoan affecting grub_linuxefi_secure_validate():

--- grub2-2.02+dfsg1/grub-core/loader/efi/linux.c   2019-10-29 00:23:53.000000000 +0000
+++ grub2-2.04/grub-core/loader/efi/linux.c 2019-10-29 00:10:44.000000000 +0000
@@ -23,6 +23,7 @@
 #include <grub/efi/efi.h>
 #include <grub/efi/pe32.h>
 #include <grub/efi/linux.h>
+#include <grub/efi/sb.h>

 #define SHIM_LOCK_GUID \
  { 0x605dab50, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23} }
@@ -40,6 +41,13 @@
   grub_efi_shim_lock_t *shim_lock;
   int status;

+  if (! grub_efi_secure_boot())
+    {
+      grub_dprintf ("linuxefi", "secure boot not enabled, not validating");
+      return 1;
+    }
+
+  grub_dprintf ("linuxefi", "Locating shim protocol\n");
   shim_lock = grub_efi_locate_protocol(&guid, NULL);
   grub_dprintf ("secureboot", "shim_lock: %p\n", shim_lock);
   if (!shim_lock)

efi chainloader depends on the value returned by grub_linuxefi_secure_validate() and if it's 1 it tries to secure boot windows image.

[lag-linaro]

Did you report this on the bug?

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1839317

[xeron]

@lag-linaro my investigation and testing of some possible fixes are under https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1845289 because my system is AMD64. TLDR @cyphermox mentioned there that even with grub_linuxefi_secure_validate returning 1 secureboot code path will still detect that SB is not available (and it does according to debug=all output) however grub_secureboot_chainloader_boot()'s call to grub_load_and_start_image() immediately sends grub back to the menu for me.

This is the last page of debug records before going to the menu:

[cyphermox]

With set debug="chain,secureboot,dl" added to the Grub menu entry, we get a flash of:

SecureBoot: 0
SetupMode: 0
linuxefi_secure_validate: 1
No shimlock protocol loader/efi/chainloader: Secure boot is not enabled

Looks like Grub is insisting on Secure Boot, which we need to disable in order to boot Linux.

This isn't GRUB insisting on Secure Boot, it's GRUB expecting that you first boot shim.

Furthermore, if there's any AMD64 system affected here; this doesn't strike me as the right place to bring it up -- aren't we looking specifically at the story for ARM64?

In either case, the supported way forward is to boot via shim first, which will then start grub; otherwise you can't have Secure Boot enabled unless you handle certificates yourself.

This gets more complicated on arm64, because there are currently bugs in shim that will prevent you from doing this -- I'm working on that.

[xeron]

arm64 bug reported here and under 1839317:

SecureBoot: 0
SetupMode: 0
linuxefi_secure_validate: 1
No shimlock protocol loader/efi/chainloader: Secure boot is not enabled

and then back to the menu.

amd64 bug I linked (1845289) and my output:

SecureBoot: 0
SetupMode: 1
linuxefi_secure_validate: 1
No shimlock protocol loader/efi/chainloader: Secure boot is not enabled

and then back to the menu.

I'm pretty sure it's the same bug in the same codebase.

[cyphermox]

I'm pretty sure it's the same bug in the same codebase.

The point is, the officially supported boot path for amd64 is to use shim, which you are not (otherwise you wouldn't have a "No shimlock protocol" message).

On arm64, you don't even have that option right now, because arm64 shim is broken.

It would be nice to fix booting without shim too, but I want to do it right.

[RussianNeuroMancer]

Fixed in grub from eoan proposed.