On Sat, 10 Jul 2021 23:15:15 +0100 Colin Watson <cjwat...@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
r...@thoryk.com
r...@tliquest.net
