Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)

[Ryan Thoryk]

On Sat, 10 Jul 2021 23:15:15 +0100 Colin Watson <cjwatson at debian.org> wrote:
> In general, this means that grub-install is not installing to the place
> that your firmware is actually booting from, which causes the core image
> (installed to a file under /boot/efi/ on UEFI systems) to be out of sync
> with the modules (installed to a subdirectory of /boot/grub/).  This is
> much rarer on UEFI systems than on BIOS systems, but it's still possible
> in some misconfigured cases.
>
> Could you please attach the output of "sudo grub-install --debug", "sudo
> efibootmgr -v", and "sudo find /boot/efi -ls"?
>

Thanks for looking into this issue.

I did some investigating this morning for my situation, and found the 
problem.  Your suggestion is what helped me.

The test case I had was that if you start a new Debian ARM VM on AWS, 
and run grub-install on it, future boots fail, where they stop at the 
rescue prompt and an "insmod normal" shows the error message.  In other 
words, "grub-install" was breaking grub, which is pretty bad.

After some investigating I found that grub-install was writing the EFI 
boot loader image (grubaa64.efi) to the wrong location on the system. 
It should be installing into /boot/efi/EFI/BOOT but is putting it into 
/boot/efi/EFI/debian.  Future boots fail because the loader image that 
executes (the one in BOOT) is the older version and is out of sync with 
the modules.

I tried deleting the /boot/efi/EFI/BOOT folder to see what would happen, 
wondering if it would try to use the "EFI/debian" one, and after 
rebooting the system was stuck in an EFI shell (couldn't find a boot 
loader), so the "EFI/debian" folder is clearly wrong.  This could be 
similar to what's happening with others on here.

-- 
Ryan Thoryk
ryan at thoryk.com
ryan at tliquest.net