I've managed to create a procedure that duplicates this problem without
the involvement of MAAS, except for one file pulled from MAAS. The
procedure is awkward, but it reproduces the problem. Here's the

1) Ensure that Secure Boot is enabled.
2) Install Ubuntu. (I used 20.04 LTS server.)
3) Retrieve shimx64.efi from a MAAS server
   (/var/lib/maas/boot-resources/current/grubx64.efi). I'm appending
   a copy of the file I used to this bug report.
4) sudo mkdir /boot/efi/EFI/foo
5) sudo cp /boot/efi/EFI/ubuntu/shimx64.efi /boot/efi/EFI/foo/
6) Copy the grubx64.efi retrieved from step #3 to /boot/efi/EFI/foo.
7) sudo efibootmgr -c -l \\EFI\\foo\\shimx64.efi -L "Secondary GRUB"
8) Reboot. A grub> prompt should appear, from shimx64.efi in the EFI/foo
   directory on the ESP.
9) Type "set root='(hd0,gpt1)'"
10) Type "chainloader /EFI/ubuntu/shimx64.efi"
11) Type "boot". The messages noted in the initial bug report should
    appear and the system should halt.

Note that some disk references may need to be adjusted on some systems
-- (hd0,gpt1) is the ESP, and the efibootmgr command assumes the ESP is
/dev/sda1 from within Ubuntu.

Interestingly, substituting grubx64.efi for shimx64.efi in step #10
results in a successful boot, which may be a simple workaround from
within MAAS -- if MAAS's configuration is changed to bypass the second
shimx64.efi, it may work better.

** Attachment added: "grubx64.efi from a MAAS server"

You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

  Chainbooting from grub over the network to local shim breaks chain of

To manage notifications about this bug go to:

ubuntu-bugs mailing list

Reply via email to