On 7/17/21 8:18 AM, Steve McIntyre wrote:
On Sat, Jul 17, 2021 at 07:57:48AM -0500, Ryan Thoryk wrote: EFI/debian is *NOT* wrong, it's the correct location for a system that has working firmware which supports setting UEFI boot variables. If you *also* need to write a copy of grub (etc.) to the removable media location (EFI/boot) then that's supported as well by the Debian packaging - run "dpkg-reconfigure grub-efi-arm64" and say yes when the system asks about that.
Thanks for that suggestion, that explains the correct procedure in resolving the issue. What I'm trying to point out though (I tried this), is that if you spin up a new Debian ARM VM on AWS, and run "grub-install" *without* doing a dpkg-reconfigure, it results in an unbootable system. To recover the system, you have to attach the disk on a different VM and replace the old boot loader image with the new one, then it boots again. After running the dpkg-reconfigure command though like you suggested, it copied over the EFI boot image to the "BOOT" folder, and also set the nvram variables to apparently boot from the "debian" folder, so that solved the problem for me. After doing that, the system comes up after a reboot with the newer grub modules.
With others on here, the issue might have to do with the system executing an older EFI boot image resulting in a module mismatch, like what happened to me. Your dpkg-reconfigure suggestion might fix their issues too.
-- Ryan Thoryk r...@thoryk.com r...@tliquest.net
