Grub_calloc not found

I’ll try and explain in most details I can, because I have asked for help to countless people, but all hope seems lost to be honest.
So, I have an Acer pre-built, with Ryzen CPU and AMD GPU. I had a dual boot of W10 and Manjaro, which was working perfectly.
Wanted to replace Manjaro with EnOS, so I did: booted up the live USB, checked it was working fine, proceeded to installation, replacing the Manjaro partition with the EnOS (the replace partition method in the installer).

At reboot, a message on screen, saying grub_calloc not found, so I’m stuck in grub rescue.

Now, here is what I tried:

  • Booting up to the live USB, mounted root partition and efi partition to /mnt/boot/efi, done a grub-install with all the parameters, grub-mkconfig etc., including chroot, and also different parameters and stuff.


  • Chrooted and reinstalled grub, then grub-install and so on


  • Tried to boot manually from the grub rescue using some instructions I found online as to set prefix and so on, but doesn’t work, insmod returns command not found.


I also tried using a live USB of boot-repair-disk, from sourceforge, which a lot of people do recommend, but apparently, the only live environment which seems to boot up is the EnOS USB I first made. No other USB I seem to make ever works, not with different USBs, not in different ports, just as if they weren’t plugged in.

So yeah, I think this is it, nothing seems to work, I also tried reinstalling EnOS, but yeah, nothing much on that side, as you can imagine.
Problem mainly is that I would want the Windows install to stay.

Any advice?

Are you installing GRUB to the correct place (disk/partition/…?).

Did you change anything else, e.g. enable Secure Boot?

Secure Boot is always disabled, I manually checked it to be sure.

As far as GRUB goes, I think, yeah. Both W10 and Linux are in the same disk, with separate partitions.
I am doing as suggested here

Using a chroot to reinstall GRUB should be the correct fix (which you’ve already done).

The only other things I can think of are

  1. GRUB didn’t actually reinstall when you told it to; try with --recheck;
  2. Your system is in a partially upgraded state and/or somehow the GRUB package itself is broken; try an -Syu within the chroot and reinstalling the GRUB package, then reinstall the GRUB loader.

If none of this works, if you could paste some information about your system and its partition layout that might be handy as a reference point.

1 Like
  1. Tried also with the --recheck
  2. Tried chrooting and running sudo pacman -Syy grub, and afterwards all the aforementioned grub-install stuff.

Ok, so, the SSD is partitioned as follows:
/dev/nvme0n1 as the device
/dev/nvme0n1p1 as the 100M efi ESP
/dev/nvme0n1p2 as the 16M Windows thingy (Microsoft reserved partition)
/dev/nvme0n1p3 as the 150ish G Windows partition
/dev/nvme0n1p4 is a 1G ntfs labelled Recovery, and called Basic data partition (I actually don’t know what this is, but it was already there)
/dev/nvme0n1p5 80G root Manjaro partition into which I installed EnOS.

That’s a partial upgrade.

(Maybe unlikely to be the reason, but it’s worth ruling out)

Oh, ok.


So, I would go about:

  • chroot
  • pacman -Syu and reinstalling grub
  • grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=EndeavourOS-grub
  • grub-mkconfig -o /boot/grub/grub.cfg
    Is this correct? Should I invert the last two?

First of all, welcome to the community. :rocketa_purple:

Did you chroot before try the grub repair?

Sorry, didn’t see your last answer.

Followed that exact link!

Thank you for the welcome :slight_smile: and sorry for my newbiety!

This is not uncommon. Some systems with bad firmware fail on reboot. Try cold boot (shutdown first and then power on). If it still fails, try to use BIOS quick boot menu, if it shows installed systems (some firmware only show disk drives).
If your BIOS has ability to manually add a boot entry, it should work. Read the user manual!

If nothing is found, install grub from chroot, using USB installer and add --removable parameter in grub installation command.

Done a reinstall, no luck.

Cold boot doesn’t work.
UEFI boot menu shows only the Windows, and yet, still brings me back to the grub error.
No possibility to add a boot entry manually as far as I know or tinkered with. No manual was ever given to me.

What does

efibootmgr -v


Also perhaps it would be helpfull to see your disk layput:

sudo parted -l

[root@EndeavourOS /]# efibootmgr -v
BootCurrent: 0009
Timeout: 0 seconds
BootOrder: 0009,0000,000A,0001,0002,0003,0004,0005,0006,0008
Boot0000* Windows Boot Manager	HD(1,GPT,df8fcd65-e20f-4b8b-9840-3cbae8d2ea59,0x800,0x32000)/File(\efi\Manjaro\grubx64.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.}...&................
Boot0001  rEFInd Boot Manager	VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0002  rEFInd Boot Manager	VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0003  Manjaro	VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0004  endeavouros	VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0005  EndeavourOS-grub	VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0006  endeavouros-1076	VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0008  rEFInd Boot Manager	VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0009* UEFI: Lexar USB Flash Drive 1100	PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/USB(6,0)/CDROM(1,0x35e500,0x32298)..BO
Boot000A* UEFI: Lexar USB Flash Drive 1100, Partition 2	PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/USB(6,0)/HD(2,MBR,0x49c1b403,0x35e500,0x32000)..BO

[root@EndeavourOS /]# sudo parted -l
Model: ATA ST1000DM010-2EP1 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name                  Flags
 1      1049kB  1000GB  1000GB  ntfs         Basic data partition  msftdata

Model: Lexar USB Flash Drive (scsi)
Disk /dev/sdb: 15.6GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size   Type     File system  Flags
 2      1808MB  1913MB  105MB  primary  fat16        esp

Model: KINGSTON RBUSNS8154P3256GJ1 (nvme)
Disk /dev/nvme0n1: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size    File system  Name                          Flags
 1      1049kB  106MB  105MB   fat32        EFI system partition          boot, esp
 2      106MB   123MB  16.8MB               Microsoft reserved partition  msftres
 3      123MB   171GB  170GB   ntfs         Basic data partition          msftdata
 5      171GB   255GB  84.4GB  ext4         root
 4      255GB   256GB  1074MB  ntfs         Basic data partition          hidden, diag

Your boot entries look quite messy to me :blush:

A couple of entries for rEfind, for EnOS, one for Manjaro etc.

Personally I would begin to remove those entries that are not needed anymore.

Here is an article for how to use efibootmgr to manipulate boot entries:

Read through it. In case of doubt, ask here.

Just don’t remove the entry for Windows Boot Manager!!

Also post:

sudo blkid

And from inside chroot:

cat /etc/fstab

Also I am a bit confounded about your Windows Boot Manager:

Boot0000* Windows Boot Manager	HD(1,GPT,df8fcd65-e20f-4b8b-9840-3cbae8d2ea59,0x800,0x32000)/File(\efi\Manjaro\grubx64.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.}...&.

Not sure why it points to


Perhaps someone dualbooting with Windows could look into it?

Have you tried changing the boot order to 0005 or 0006. I suspect one of those might be the correct one.

[root@EndeavourOS /]# blkid
/dev/nvme0n1p5: UUID="963d33a8-fbcd-486c-96a3-a538253bed8b" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="root" PARTUUID="04d78a42-423e-bc42-9a74-6a59d16700d8"
/dev/nvme0n1p3: LABEL="Acer" BLOCK_SIZE="512" UUID="04F88FECF88FDA76" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="0c05b871-3517-499f-a6d8-b5e0cbff0535"
/dev/nvme0n1p1: LABEL_FATBOOT="ESP" LABEL="ESP" UUID="7057-97EC" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="df8fcd65-e20f-4b8b-9840-3cbae8d2ea59"
/dev/nvme0n1p4: LABEL="Recovery" BLOCK_SIZE="512" UUID="8066B3C666B3BB6C" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="eca93809-9067-4440-8e49-8140d1f3c2c8"
/dev/nvme0n1p2: PARTLABEL="Microsoft reserved partition" PARTUUID="f0efca9d-e087-42fe-8929-0046c2775af9"
/dev/sdb2: SEC_TYPE="msdos" LABEL_FATBOOT="ARCHISO_EFI" LABEL="ARCHISO_EFI" UUID="86A6-7D35" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="49c1b403-02"
/dev/sdb1: BLOCK_SIZE="2048" UUID="2022-04-08-09-58-31-00" LABEL="EOS_202204" TYPE="iso9660" PARTUUID="49c1b403-01"
/dev/loop0: TYPE="squashfs"
/dev/sda1: LABEL="DATA" BLOCK_SIZE="512" UUID="7A2E00C62E007D7F" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="e3347c5f-6ece-4a50-8277-bd2c659cddae"

[root@EndeavourOS /]# cat /etc/fstab
# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=7057-97EC                            /boot/efi      vfat    defaults,noatime 0 2
UUID=963d33a8-fbcd-486c-96a3-a538253bed8b /              ext4    defaults,noatime 0 1

1 Like

I am actually trying to do the things described in the article, for example setting the 0005 boot as active, and then changing the order, but it doesn’t do anything, and even though whilst I’m in the chroot I see the changes, as soon as I exit and shutdown, it looks like the changes are reverted. Next boot and chroot, and it shows the same output.

Did you also try 0006 instead and see.