🚨 Linux Error: 'error: symbol 'grub_calloc' not found' — Cause, Fix, and Troubleshooting Guide

Overview

error: symbol 'grub_calloc' not found at boot means GRUB’s installed core image (in the MBR/boot sector or the EFI binary) is a different version from the modules under /boot/grub. The core image tries to call a function — grub_calloc — that exists in one GRUB version but not the module it just loaded, so the load fails and boot stops. This is almost always the aftermath of a partial GRUB upgrade: the package on disk updated /boot/grub/*.mod, but the core image embedded in the boot sector was never refreshed to match (or vice versa).

error: symbol 'grub_calloc' not found
Entering rescue mode...
grub rescue>

It is especially common on Ubuntu/Debian after an interrupted grub-pkg upgrade, an image restore, or booting a disk whose boot sector predates the modules on its /boot. The durable fix is to reinstall GRUB so the core image and the /boot/grub modules come from the same version again.

Symptoms

• Boot fails immediately with error: symbol 'grub_calloc' not found, usually dropping to grub rescue>.
• It started right after a system upgrade, a grub package update, an OS clone/restore, or moving a disk between machines.
• Other symbol '...' not found variants (e.g., grub_verify_string, grub_efi_get_secureboot) appear for the same underlying reason — a core/module version mismatch.
• Booting from a live USB, the installed /boot/grub looks intact — only the on-disk boot code is stale.

Common Root Causes

Common production causes first:

1. Partial GRUB upgrade — apt/dpkg updated /boot/grub/*.mod but grub-install never ran, so the boot-sector core image is older than the modules (the classic Ubuntu cause).
2. Modules updated, core not re-embedded — a kernel/GRUB update refreshed files under /boot/grub without re-writing the MBR or EFI binary.
3. Cloned/restored disk — the image carried a new /boot/grub onto a disk whose boot sector still holds an old core image.
4. Boot from the wrong disk — firmware boots a disk with an old GRUB core that then reads another disk’s newer modules.
5. Interrupted upgrade — a reboot or power loss mid-grub upgrade left core and modules out of sync.

How to diagnose

You usually cannot fix this from the grub rescue> prompt reliably (the mismatched modules are what is failing), so recover from a live USB. First confirm the mismatch.

# From a live USB, identify the installed system's disk/partitions
sudo blkid
lsblk -f
# e.g. /dev/sda2 = root, /dev/sda1 = EFI (UUID=1111-2222)

# Mount and inspect the installed GRUB modules
sudo mount /dev/sda2 /mnt
ls -l /mnt/boot/grub/x86_64-pc/            # BIOS modules, or:
ls -l /mnt/boot/efi/EFI/ubuntu/            # EFI binary location
cat /mnt/boot/grub/grub.cfg | head         # confirm it references current kernels

If /boot/grub holds a full, current module set but the machine still fails at the symbol error, the on-disk core image is the stale half. The fix is to re-embed a matching core with grub-install.

Fixes

The reliable path is: boot a live USB, chroot into the installed system, then reinstall GRUB so the core image and modules are rebuilt together from the same package version.

Step 1 — set up a chroot from a live USB

sudo mount /dev/sda2 /mnt            # root
sudo mount /dev/sda1 /mnt/boot/efi   # EFI partition (UEFI systems)
# If /boot is its own partition, also: sudo mount /dev/sdaN /mnt/boot
for d in dev proc sys; do sudo mount --bind /$d /mnt/$d; done
sudo mount --bind /run /mnt/run      # helps apt/os-prober inside chroot
sudo chroot /mnt

Step 2 — resync the core image and modules

Warning: grub-install writes a disk’s boot area. On BIOS, pass the whole disk (/dev/sda), never a partition (/dev/sda1). On UEFI, do not pass a disk device at all — the EFI directory is the target. Confirm the boot disk with lsblk and efibootmgr -v first; the wrong target can leave the machine unbootable.

# BIOS (legacy) — Debian/Ubuntu
grub-install /dev/sda
update-grub

# UEFI — Debian/Ubuntu (EFI partition mounted at /boot/efi)
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
update-grub

# RHEL / Rocky equivalents
grub2-install /dev/sda                                   # BIOS
grub2-mkconfig -o /boot/grub2/grub.cfg                   # BIOS config
grub2-mkconfig -o /boot/efi/EFI/rocky/grub.cfg           # UEFI config

grub-install re-embeds a core image built from the same /boot/grub modules that are on disk, so grub_calloc (and every other symbol) resolves again. update-grub then rewrites grub.cfg for the current kernels.

Step 3 — if the GRUB package itself is broken, reinstall it first

A partial upgrade can leave the grub package half-configured. Reinstall it inside the chroot before running grub-install:

# Debian / Ubuntu
apt-get install --reinstall grub-efi-amd64 grub-common grub2-common
# (use grub-pc instead of grub-efi-amd64 on BIOS systems)
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
update-grub

Secure Boot / grub-efi notes

• On UEFI with Secure Boot enabled, Ubuntu boots a signed shim (shimx64.efi) that chain-loads a signed grubx64.efi. Reinstall grub-efi-amd64-signed (and shim-signed) so the signed binaries match:

  apt-get install --reinstall grub-efi-amd64-signed shim-signed
  grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu

• Do not switch a Secure Boot machine to an unsigned grub-install; firmware will refuse the unsigned image. Keep the signed packages, or disable Secure Boot in firmware only as a deliberate, temporary step.

• After reinstalling, verify the EFI boot entry points at the right disk with efibootmgr -v.

What to watch out for

• Never fix this from grub rescue> alone — the modules that fail to load are the ones the rescue prompt would use. A live-USB grub-install is the reliable path.
• Match BIOS vs UEFI: passing /dev/sda on a UEFI system, or omitting the disk on a BIOS system, installs the wrong flavor. Check for /sys/firmware/efi — if it exists, you are on UEFI.
• Same package version: the whole point is that core image and modules come from one version. Do not manually copy .mod files between systems.
• Cloned images: after restoring an image, always run grub-install + update-grub on the target so its boot sector matches its /boot/grub.
• Secure Boot: use the -signed packages; an unsigned GRUB silently fails to load under Secure Boot even after a “successful” install.

Related

• grub rescue> … no such device
• error: no such partition.
• Kernel panic - not syncing: VFS: Unable to mount root fs

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.