Grub_calloc not found

[ruben]

It does nothing though. Tried to change boot order, verified running efibootmgr again, but as soon as I shutdown and turn on, same problem, and when I chroot to see the output of efibootmgr, it is as if I changed nothing.

[ricklinux]

How are you changing the boot order

efibootmgr

[ruben]

sudo efibootmgr -o 0005,0009,0000,000A,0001,0002,0003,0004,0006,0008

[ricklinux]

Not sure why that won’t change it? If it were me i would remove the following entries first. See if that works?
0002, 0003, 0008, 000A

Then run efibootmgr.

[ruben]

Tried, works until I shut down, then it kind of resets, no idea why.

[ricklinux]

Well if it’s a fresh install what you could do is reinstall it but this time i would use manual partitioning in the installer. You can use the partition that EOS is installed on and you would have to select the windows /efi partition and don’t format it but use the edit to set it & to flag it as /boot.

Edit: It will show a check box on the windows /efi to not format it.

[ruben]

With manual partitioning, is it enough to set the esp as /boot mount point, and the enOS partition as /root? Would I have to dk anything else? I did the automatic thing because I was unsure on how to correctly do it.

[ricklinux]

Yes you can set the whole partition as root and flag it as such and then select the windows /efi and edit but do not format it and set it as /boot/efi /boot. Not sure if it has both?

Edit: You can always add a swap file after the fact if needed, Or you could create a swap partition on the existing if you redo it all.

[jonathon]

@ruben

then it kind of resets

It might be worth resetting the BIOS/UEFI back to factory defaults, then repairing GRUB. (Windows will still appear in the UEFI boot loader because it’s Windows.)

[ruben]

Done. Same result.

[petsam]

@petsam

If nothing is found, install grub from chroot, using USB installer and add --removable parameter in grub installation command.
https://wiki.archlinux.org/title/GRUB#Installation_2

You missed this.
It is supposed to be the solution to those bad firmware that won’t/can’t change the default boot (because of winOS…). That’s why you were advised(?) from Manjaro to replace the Windows UEFI entry to point to Manjaro efi file (or do they do it automatically with Calamares now??).
Using the --removable parameter with grub installation command, grub efi file is copied to the default UEFI boot entry (like on removable drives installations), which is also suggested in Archwiki as one of the workarounds.

Just read about grub troubleshooting in the Book (I posted the link in my post…).

@ruben

No manual was ever given to me.

Is the hardware stolen?
Isn’t there any vendor website with the user manuals? (not that it may have useful info, but going to the manual should become a habit to everyone IMHO )

[ruben]

I am trying that right now.

The hardware wasn’t stolen, obviously, but it was a pre-built I purchased from an electronics chain store here, and first of all it came with no manuals inside the box, and second of all, I can find nothing online, aside from some simple “Press this button to turn the pc on”.

[ruben]

Here I am documenting every single step I am taking.

First of all, this is my drive:

where the p1 is the efi partition, the p2 and p3 are Windows partitions, and p5 is the EnOS install.
The most recent install I made, I did a manual partitioning, setting the p5 as /, flag root, and the p1 flag boot (without formatting it).

Mounting and chrooting:

mount /dev/nvme0n1p5 /mnt
mount /dev/nvme0n1p1 /mnt/boot/efi
arch-chroot /mnt

As described by the Arch Wiki link, I proceed with the grub installation:

[root@EndeavourOS /] grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=EndeavourOS-grub --removable
Installing for x86_64-efi platform.
Installation finished. No error reported.

Then, the config:

[root@EndeavourOS /] grub-mkconfig -o /boot/grub/grub.cfg 
Generating grub configuration file ...
Found theme: /boot/grub/themes/EndeavourOS/theme.txt
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/amd-ucode.img /boot/initramfs-linux.img
Found fallback initrd image(s) in /boot:  amd-ucode.img initramfs-linux-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
grub-probe: error: cannot find a GRUB drive for /dev/sdb1.  Check your device.map.
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done

Then I exit, umount, and shutdown.

Same result.

[pebcak]

What shows your current:

efibootmgr -v

now?

[ruben]

[root@EndeavourOS /]# efibootmgr -v
BootCurrent: 0009
Timeout: 0 seconds
BootOrder: 0009,0000,000A,0001,0002,0003,0004,0005,0006,0007,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.4.7.9.5.}...&................
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)
Boot0007  endeavouros-7345	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

[pebcak]

At a glance, that looks like exactly the same as before.
It’s quite strange why the changes won’t get “registered”.

This is a wild guess, but I wonder if this might be one of those failing CMOS battery occasions. See this topic for example:

I get “Boot Fail” every time after installing EOS BSPWM (solved)

Try resetting the firmware to factory defaults. One way to check if it is a CMOS battery issue is to shutdown the system. Remove powercord and remove battery. Wait a few minutes then power up without the battery. Enter the firmware - check the clock - if it is e.g. 2000-01-01 then you know the battery is causing your issues.

You might want to investigate it further perhaps.

[ricklinux]

Maybe clear the nvram of all the entries.

sudo rm /sys/firmware/efi/efivars/*

[ruben]

Should I run that whilst chrooted? And then?

Anyway, I managed to boot into a Mint live, which allowed me to run boot-repair, but even that one failed.

It managed to make my error different, in the grub_rescue, saying a normal.mod file was not found, instead of grub_calloc, but then again, as soon as I either try to grub-install or reinstall the distro altogether, back to the grub_calloc.

[ricklinux]

I take it you have secure boot turned off? Not sure why it won’t write the file to the Windows /efi? Either it’s too small or Nvram is full? It’s obvious it’s creating the entry when you reinstalled grub as it’s listed boot 0007.

[pebcak]

@ricklinux

It’s obvious it’s creating the entry when you reinstalled grub. as it’s listed boot 0007.

But the form seems to be defect as it doesn’t point to any file:

Boot0007  endeavouros-7345	VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)

The normal form would be something like:

Bootxxxx GnuLinuxOS HD(1,GPT,df8fcd65-e20f-4b8b-9840-3cbae8d2ea59,0x800,0x32000)/File(\efi\GnuLinux\grubx64.efi)