On Tue, May 05, 2026 at 11:34:05AM +0100, Steve McIntyre wrote:
On Tue, May 05, 2026 at 12:05:00PM +0200, Marc Haber wrote:
Package: grub-efi-arm64
Version: 2.14-2
Severity: normal
X-Debbugs-Cc: [email protected]
Hi,
I'm running Debian unstable on a Raspberry PI 4. The firmwware loads
u-boot, u-boot loads grub-efi-arm64, grub-efi-arm64 drops me on a grub
rescue shell with "error: symbol `grub_memcpy' not found.". Going back
to grub-efi 2.12-9+deb13u1 from trixie works without other changes to
the system.
The information given below originates from the system after doing the
downgrade.
OK, this is 99.9% certain to be a mismatch between the grub core image
and the modules installed in /boot/grub.
After a few rounds of debugging, I concur that your assessment is
correct.
If you're on a Pi, then it's
very likely you're booting using the removable media path. Could you
give us the output of "ls -lR /boot/efi" as root please?
I use the raspi firmware partitions as ESP and mount them as /boot/efi.
Grub is thus accessible as /boot/efi/EFI/debian/grubaa64.efi and you're
right that the grub 2.12 image that is placed there does not get updated
when I do grub-install. Hence, the boot with the 2.14 modules in
/boot/grub fails; setting prefix to the backup copy /boot/grub-works
helps here.
The efivars error message that other people noticed is due to the fact
that the Raspberry Pi 4 doesn't have persistent efivars.
Can this cause the grubaa64.efi to not be replaced during grub-install?
Which software component in the stack is supposed to update
/boot/efi/EFI on grub-update?
Whatever that component is, it does not seem to do its job.
Greetings from Mini Debconf Hamburg
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
