How to fix a grub boot error : "symbol 'grub_calloc' not found

Question

Just ran the latest batch of updates on 20.04 (Xubuntu), and now I'm getting a GRUB error:

symbol 'grub_calloc' not found

I'm dropped into the 'grub rescue' shell, but have no idea what to do there that might be useful. To me, 'symbol not found' implies some sort of build error with the grub package, but I don't really know how grub works. I noticed that this update also included 'firmware', not sure if that could be related. Is my best bet just to boot from a live CD and see if I can roll back the update to grub somehow?

Edited to add:

OK, thanks to lots of people ! Here's what I think I now understand.

1. On 'non-UEFI' systems, grub is installed in two separate parts. The first, most basic, part is the part that is started on bootup. But for most of it's functionality, it needs the second part. These parts must be aligned - neither part must require any functionality from the other part which is not actually there.

   The visible, run-time problem occurs when these parts are not aligned, and the function grub_calloc is not supplied. It's not 100% clear to me if grub_calloc belongs in the second, larger part or the first. I would have expected the second, but the grub build system is a work of considerable art, so I don't know :).

2. The root cause of the problem is that the grub update has not ensured that both parts have been updated. Ideally, failure to do this should cause grub installation to fail, and the system should be reverted to a safe state. This does not happen.

   This is actually still a bit of a mystery to me. All that the update needs to do by default is put each part where the current parts are, because obviously that worked. If the install locations/drives are configuration - driven, and one of these locations can't be reached, then somehow a mismatch has arisen between that configuration data and reality. This might not show up as a problem as long as no new dependency was introduced between the parts.

All flavours of solution involve reinstalling grub to ensure that the two parts are aligned. It's not actually necessary to go back to the previous version ( although that will work ), because it's not the grub runtime per se that is broken. There are numerous ways to achieve this, depending on your environment, but running the Boot-repair live disk worked for me.

It may be useful, for the purpose of avoiding such a misalignment in future, to ensure that the grub installer on your system is configured to install to the correct devices.

This update resolves some important bugs (See Ubuntu Security Notice 4432). If you have reverted grub to resolve this problem, be aware that you are exposed to these issues.

Answer 1

Using Linux Mint 19.3 bios grub setup in a simple 2 partition installation.

After GRUB2 update the machine crashed on reboot and entered rescue mode.

error: symbol 'grub_calloc' not found    

To restore GRUB I booted into Linux Mint 19.3 Live USB stick and issued the following commands in the terminal:

sudo mount /dev/sda1  /mnt    
sudo grub-install --root-directory=/mnt/  /dev/sda    

On reboot the desktop showed up nicely.

Answer 2

I was in the same boat as Rick N. 2 disks but they weren't in RAID. I used this tool https://sourceforge.net/p/boot-repair-cd/home/Home/

I found that tool from the Ubuntu Help page https://help.ubuntu.com/community/Boot-Repair

It appears to have installed some GUI features that weren't there before (this system has been CLI-only for as long as I can remember) but I'm running again, which is the important part.

Thanks to the others, here, for the guidance.

Answer 3

This is some of the work we did fixing this on our Azure Ubuntu 18.04 servers

Problem appears to be a failed attempt to upgrade grub. Problem happens with an unattended reboot after a security upgrade.

We then found these instructions from a comment posted on the Ubuntu bug for this problem: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509/comments/16

Note that I modified this slightly and below is my modified version that I mention in a later comment on the bug( https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509/comments/45 )

For Azure users (the same should work in any cloud, with small changes) that end up here while looking for this bug, the steps to recover are:

Deploy a recovery VM using AzCli or just attach a copy of the affected OS vm disk to a rescue VM. Once done, connected to rescue VM and:

$ sudo su -
# lsblk <-- this will identify the attached disk, usualy /dev/sdc, but can be /dev/sda or /dev/sdb
# mkdir /rescue
# mount /dev/sdc1 /rescue <-- this assumes /dev/sdc is the attached data disk
# for fs in {proc,sys,tmp,dev}; do mount -o bind /$fs /rescue/$fs; done
# cd /rescue
# chroot /rescue
# grub-install /dev/sdc <-- this assumes /dev/sdc is the attached data disk
# exit
# cd /
# for fs in {proc,sys,tmp,dev}; do umount /rescue/$fs; done
# umount /rescue
# rmdir /rescue

Now you should be able to swap back the repaired disk to affected VM.

First attempt at a fix

We found the following Azure documentation links useful:

• https://docs.microsoft.com/nl-nl/archive/blogs/mast/recover-azure-vm-by-attaching-os-disk-to-another-azure-vm
• https://docs.microsoft.com/en-us/azure/virtual-machines/scripts/virtual-machines-linux-cli-sample-create-vm-from-snapshot?toc=/cli/module/toc.json
• https://social.msdn.microsoft.com/Forums/azure/en-US/6bed5c4f-f5c3-4926-9ac5-05ce7b1efeac/create-copy-of-a-managed-disk?forum=windowsazuredata
• https://docs.microsoft.com/en-us/azure/virtual-machines/linux/snapshot-copy-managed-disk

Ok, step by step:

Deploy a recovery VM

What sort of VM is that? Attempted creating a regular Ubuntu 18.04 LTS VM. This is what you want - to create a recovery VM that matches the servers that are broken

All normal except for connecting to an existing disk. Looks like you can't attach to a disk unless you first somehow move it from another machine (detach it) first.

attach a copy of the affected OS vm disk to a rescue VM.

To create a copy, you can take a read only snapshot of the disk and then create a new Managed Disk based on the snapshot.

The only disk you need a snapshot of is the OS disk, not the data disk.

You can create the recovery VM without a data disk, just the OS disk that automatically gets created.

You can then add the Managed Disk OS snapshot to the recovery VM as a data disk.

Then you can log into the recovery VM and follow the steps above.

All the steps completed without error - we could copy and paste the exact messages

The critical line is running grub-install you should see the following:

root@recoveryVM:/# grub-install /dev/sdc
Installing for i386-pc platform.
Installation finished. No error reported.

Then log out and stop the VM.

You can then go into the broken VM and under the Disks section of the VM select 'Swap OS Disk'.

Reddit mini thread explaining the mounts required: https://www.reddit.com/r/Ubuntu/comments/i0vlf0/repair_grub_boot_error_symbol_grub_calloc_not/

Repeating the steps

1. Make a snapshot of 'broken' OS disk (postfix _snap)
2. Create a Managed Disk from the snapshot - this must be the same grade as the old OS disk as we are going to fully replace the old OS disk with this one (postfix _recovery) - source type snapshot and use the just created snapshot
3. Attach Managed OS Disk to recovery VM (stop/start of recoveryVM not required)
4. Login via SSH, run recovery steps, logout again
5. Detach Managed OS Disk from recovery VM (edit the VM disks and detach the recovery OS Disk)
6. Stop the 'broken' VM (possibly not necessary as the OS Disk swap stops it)
7. In the 'broken' VM Disks click 'Swap OS Disk' and select the recovery OS Disk as the replacement
8. Start the 'recovered' VM
9. Clean up the snapshot - but leave the broken OS disk for now - reminder for a month or so to remove it too

Finally turn off the recovery VM and delete that in a month too

Problems with some servers

We hit a problem that the two server's fixes didn't work. All commands completed successfully - but we get the same grub error when starting the VM.

Further investigation showed up that the /dev/sda, /dev/sdb and /dev/sdc had changed on the recovery VM. I don't know why this happened.

This is what you should get when running lsblk in sudo (but non-chroot) mode (note sda is recovery VM OS, and sdc is attached data disk to be recovered):

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda       8:0    0   30G  0 disk
├─sda1    8:1    0 29.9G  0 part /
├─sda14   8:14   0    4M  0 part
└─sda15   8:15   0  106M  0 part /boot/efi
sdb       8:16   0   16G  0 disk
└─sdb1    8:17   0   16G  0 part /mnt
sdc       8:32   0   30G  0 disk
├─sdc1    8:33   0 29.9G  0 part
├─sdc14   8:46   0    4M  0 part
└─sdc15   8:47   0  106M  0 part
sr0      11:0    1  628K  0 rom

Answer 4

I had the same error and unbootable system after I installed Lubuntu 20.04 earlier today (on an old laptop, Bios install, not EFI) and let it do the upgrade. It came up with a very confusing dialog about wanting to update GRUB on my first partition as well as my Lubuntu partition. It appeared to suggest updating both partitions, which I did. And then, on reboot, it crashed before loading the DE.

Anyway, I found more of a workaround than a fix to this. Since GRUB appears to be the problem (for whatever reason), I re-installed Lubuntu and when it booted up for the first time, I opened up a terminal window and manually did the upgrade, and excluded the updates to grub:

sudo apt update

sudo apt list --upgradable |grep grub

Which showed:

grub-common/focal-updates 2.04-1ubuntu26.1 amd64 [upgradable from: 2.04-1ubuntu26]
grub-pc-bin/focal-updates 2.04-1ubuntu26.1 amd64 [upgradable from: 2.04-1ubuntu26]
grub-pc/focal-updates 2.04-1ubuntu26.1 amd64 [upgradable from: 2.04-1ubuntu26]
grub2-common/focal-updates 2.04-1ubuntu26.1 amd64 [upgradable from: 2.04-1ubuntu26]

I then put these grub updates "on hold" with this:

sudo apt-mark hold grub*

..and then went ahead with the upgrade:

sudo apt full-upgrade

I rebooted the machine, and it came back up into the desktop without error.

I don't know what ill effects might occur by not updating GRUB, but so far, it's acting normally in the desktop sessions..

Answer 5

Same here with linux mint 20 cinnamon and bios (as opposed to EFI) grub setup.

Anyone could provide some help?

Editing: I found the root cause for my problem and the solution. The root cause in my case is that I have a RAID5 built out of 4 disks and, I supose, the automatic grub-install during the package upgrade only updated "disk2". As my bios is booting out of "disk1" it had an older grub and therefore it was unable to boot. I changed the bios to boot from each of the disks at a time (i.e.: "disk1", "disk2", "disk3", "disk4" ) and the only one working was "disk2".

To solve the problem I just booted from "disk2" and executed:

sudo grub-install /dev/sda  
sudo grub-install /dev/sdc  
sudo grub-install /dev/sdd  
# ("disk2" is /dev/sdb and it was already working properly so I didn't install grub in that disk)  
sudo update-grub  
sudo reboot  

And then reconfigured my BIOS to boot back from "disk1". This way, each time grub is updated I will got a similar problem and this will be reminded to grub-install, grub-update the rest of the disks.

I hope this helps other people in the same situation.

Answer 6

Using Linux Mint here and the same happened to me. Seems like its caused by a security update recently, as I couldn't find anything else on Google other than this update announcement.

Solved by booting into a Mint Live USB and using Timeshift to restore to a point in time before I updated grub2.

Answer 7

I definitely solved the problem.

1. Go to the page, click here and download BOOT-REPAIR-DISK.

2. Burn it to the DVD disk or make a USB Bootable no more than 4GB and USB 2.0 (I recommend the DVD disk 4 GB).

3. Power on the PC with the DVD disk or USB bootable inserted.

4. Once the screen displays the title "Boot-Repair-Disk", there are two options that you have to choose. Click the first, the upper 64bit session.

   

5. Once the screen displays the desktop, it will display about the updating Boot-Repair-Disk, click NO because it's not necessary.

6. Once the screen displays two options that you have to choose as the following picture displays, click the first Recommended repair (repairs most frequent problems)

   

7. Once finished the process, reboot the PC and it must boot up the Ubuntu OS.

That's all. Good Luck!

More information, here: https://help.ubuntu.com/community/Boot-Repair

Answer 8

We had many production Systems which had this exact Problem: (the following steps are done with a Debian DVD but should be pretty similar or applicable on ubuntu)

1. Start with a rescue Disk
2. Just click through the questions
3. Ignore network
4. select your root disk to be mounted
5. select also /boot to be mounted
6. drop a shell into the selected root disk
7. grub-install DISKNAMEWITHOUTPARTITION ( but without the partition id (1,2,3....)) e.g grub-install /dev/sda
8. reboot

We did the Update noninteractively. Interactively it reports the following:

grub-install: error: cannot find a GRUB drive for /dev/vda. Check your device.map.

even though the disk should be xvda not vda in our case. It breaks the MBR which resides in a special Place on the Harddisk, this is why you have to put in the disk without partitionnumber.

Ubuntu Bug Report

Debian Bug Report

Answer 9

The Surprise:

After a recent update, I got the same error:

error: symbol grub_callocnot found .
Entering rescue mode ...
grub rescue> _

Points of Difference:

What is different in my case, compared to all the other answers listed here, as well as the points mentioned in the OP's post under Edit, was, I have UEFI!

Also, I have a dual boot system with Windows 10 and with Debian 10 (and not Ubuntu, I know, this forum is askubuntu but it is one of the first hits upon searching on the web for 'grub_calloc not found' error).

The fixes:

• I read all the discussion about the grub being in two parts, etc etc, both on this forum and other places. I reinstalled grub (and grub-common, and grub-efi-amd64-bin and grub-efi-amd64-bin-signed and grub2-common), hoping for some 'realignment'. grub-pcwas not installed on my system before, so I installed it also for good measure. Still nothing changed for me.

• Installing to MBR was not an option for me. Windows 10 is installed with UEFI on this laptop.

• I have no RAID, no LVM setup. Don't even know what those things are. So none of the other answers helped me.

Boot From EFI-File:

I was hoping for a bug fix to come soon, as this bug leaves the system unbootable and unusable. Meanwhile, I could still boot both into Windows 10 and Debian 10, by,

1. going into "'BIOS' setup" by pressing ESCAPE when the laptop is started,
2. and then selecting the option "Boot from EFI file" instead of "Boot from OS Manager",
3. and then from the folders Boot, debian, HP and Microsoft going into debian,
4. and then selecting the grubx64.efi file,

which would bring up the usual grub menu with the usual OS choices listed. Maybe this option is something specific to my laptop, I cannot say. (Something similar could be arrived at, through the use of a Live USB/CD as well, I guess).

The Fix that worked:

Anyways, after waiting for a week or so, for the bug fix, I got tired of this routine of going through the BIOS Setup to boot the laptop every morning. After booting up into Debian 10, this morning, I did the following:

1. I looked into what is in the Boot folder under EFI, where I found only one file bootx64.efi.
2. I made a backup of the bootx64.efi file ---> bootx64.efi.bak placed in the same folder.
3. Then I copied over the grubx64.efi from the debian folder, into the Boot folder as the new bootx64.efi.
4. Rebooted the laptop and up came the grub menu, clean and clear, without any jumps through any hoops.

I guess the same could be done from a live USB/CD also.

I dunno, how safe or hacky this solution is (or if it is even a solution for everyone with UEFI).

---

• Booting before the Fix.

Answer 10

I hit this error upgrading a bunch of servers from Ubuntu 16.04 to 18.04. In my case one machine had a separate boot volume that was on /dev/md0 (mdraid array) which used /dev/sda1 and /dev/sdb1 as RAID volumes. The fix was:

• Boot from an 18.04 USB stick into "LiveCD" mode.
• Use blkid to find the volume UUIDs and drives. Identified /dev/md127 as the mdraid array that usually appeared as /dev/md0.
• Then:

  apt install grub2-common grub-pc
  mkdir -p /mnt/root/boot
  mount /dev/md127 /mnt/root/boot
  

• Install MBR on both physical drives so either will work after a failure

  grub-install --root-directory=/mnt/root /dev/sdb
  grub-install --root-directory=/mnt/root /dev/sda
  

• Verify that there are new grub files in /mnt/root/boot/grub:

  ls -alR /mnt/root
  

• Reboot

After that the server came back up.

Answer 11

Like Juan Fra - I have 2 disks, but not RAID. I suspect GRUB was on both. I'm on Ubuntu so booted from CD, installed "boot-repair" (instructions available online) and it updated all grub partitions. All good now.