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.

Boot log on bottom.

Greetings
Marc

Hi Marc,

OK, this is 99.9% certain to be a mismatch between the grub core image
and the modules installed in /boot/grub. 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?

U-boot logs seem to confirm it:

Without EFI variables, only the removable media path can be used.

If U-Boot loads GRUB from the EFI partition removable media path, it
means the copy of GRUB core image in /boot/efi/EFI/BOOT/ was not updated
after upgrading to the new GRUB version. It should be updated
automatically if grub2/force_efi_extra_removable is set to 'false' in
debconf. You can check with

debconf-show grub-efi-arm64

In addition, this system does not seem to use the monolithic signed
image (grub-efi-arm64-signed) which does not need external modules and
would avoid the module version mismatch (but if is not updated in the
boot location then the old version will still be used).

Hey Pascal,

Yup, that's exactly where I was going. Unfortunately, lots of people
just end up copying a grub binary into place once (whether by directly
copying, or by using grub-install manually) and that works *now* but
leaves them primed for a fall on future upgrades.

It's been a problem for years with BIOS boot, but we can't 100% solve
that due to the space limitations and needing a core images. Switching
to the monolithic image for EFI is possible, and it's time we just did
it.

Do you mean the size of the gap between the MBR and the first partition
or the BIOS boot partition (usually ~1MB) ? Do you have an idea of the
size of a grub-pc monolithic image ?

It would solve the core image vs module version mismatch but not the
fact that the active boot image is not updated, it would only make it
unnoticed.

Correct. I don't have an idea of the size of a monolithic grub-pc
image, it's not something we ever do.

Nod; the most important thing is that users don't end up with
unbootable systems on upgrade. It's not possible to fix the general
case here, IMHO.

After a few rounds of debugging, I concur that your assessment is
correct.

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

That is the case.

$ sudo ls -lR /boot/efi/EFI/
/boot/efi/EFI/:
total 8
drwxr-xr-x 2 root root 4096 May  5  2026 BOOT
drwxr-xr-x 2 root root 4096 May  5  2026 debian

/boot/efi/EFI/BOOT:
total 148
-rwxr-xr-x 1 root root 151552 May  5  2026 BOOTAA64.EFI

/boot/efi/EFI/debian:
total 5088
-rwxr-xr-x 1 root root     110 Mar 23 13:37 BOOTAA64.CSV
-rwxr-xr-x 1 root root  124920 Mar 23 13:37 fbaa64.efi
-rwxr-xr-x 1 root root     121 Mar 23 13:37 grub.cfg
-rwxr-xr-x 1 root root 3126720 Mar 23 13:37 grubaa64.efi
-rwxr-xr-x 1 root root  953040 Mar 23 13:37 mmaa64.efi
-rwxr-xr-x 1 root root  987432 Mar 23 13:37 shimaa64.efi

None of those files get updated when upgrading to grub 2.14 and doing
grub-install.

$ debconf-show grub-efi-arm64
   grub2/force_efi_extra_removable: false
   grub2/linux_cmdline:
   grub2/kfreebsd_cmdline:
   grub2/kfreebsd_cmdline_default: quiet
   grub2/linux_cmdline_default: quiet
   grub2/update_nvram: true
   grub2/enable_os_prober: false

btw, this is a debian live arm64 image that Roland Clobus helped me
build on Mini Debconf Hamburg.

Is the non-monolithic version still supported? Do you recommend
migrating to the monolithic version?

Greetings
Marc

This is the "removable media" (fallback) path.
According to the size, it can be a custom (non monolithic) GRUB core
image. According to the date, it was updated yesterday. However, in my
experience `ls -l` shows the year only if it does not match the current
year. What is the current system date ?

This is the default location for Debian EFI boot, but it cannot be used
by U-Boot EFI services without EFI variables.
The files names and sizes indicate that a signed monolithic GRUB image
was used with shim, for secure boot. Are shim-signed and
grub-efi-arm64-signed installed ?

The dates are older than in the fallback path. I expected the opposite.
By default, `grub-install` would update files in /boot/efi/EFI/debian
and not in /boot/efi/EFI/BOOT. How is GRUB_DISTRIBUTOR defined in
/etc/default/grub or /etc/default/grub.d/*.cfg ?

This is weird. Does `grub-install` exit with success ? Can you run it in
verbose mode (--verbose), record the output and check what it really
installs where ?

So I would expect that /boot/efi/EFI/debian is updated and
/boot/efi/EFI/BOOT is not.

Setting this parameter to 'false' would prevent `grub-install` from
trying and failing to update EFI boot variables. Anyway in my experience
this failure does not prevent updating the files in the ESP.

Do you mean you installed from a live image ? Or you are using a live
image (with persistence ?)

In your previous post I noticed that you used the same partition for
firmware and efi. I do not think it matters, AFAIK grub-install uses
what's mounted on /boot/efi and should not care if it is also mounted
elsewhere.

Hi Marc,

ACK.

You're ralking about grub-install here. Are you running that by hand,
or letting the system run it automatically during grub package upgrades?

Grub package upgrades *should* be handling this.

Ummm, that should be "true".

so this won't be working.

Sorry, I can't parse that - are you running the live image itself and
expecting it to update things, or have you *installed* from the live image?