[Solved]Grub failing to boot - grub_calloc not found

Geoff 42 · 2020-07-30 18:21:23

After upgrading Beowulf, my desktop will not boot. It tries to run grub and reports

symbol grub_calloc not found
Entering rescue mode
grub rescue>

I have found a reference to this on an Ubuntu site :-

https://www.mail-archive.com/ubuntu-bug … 13006.html

which refers to :-

https://askubuntu.com/questions/1263125 … -not-found

I am trying to work my way through this, with

ls
ls (hd0,msdos5)
set boot=(hd0,msdos5)
set prefix=(hd0,msdos5)/grub
insmod normal

but the last line reports that grub_calloc is not found.

Geoff

Last edited by Geoff 42 (2020-08-01 10:59:56)

Head_on_a_Stick · 2020-07-30 18:30:32

Looks like you need to attempt a reinstallation of the bootloader.

Load up a beowulf live ISO image then

sudo -i
mount /dev/sdXY /mnt
apt update && apt install grub-pc
grub-install --boot-directory=/mnt/boot /dev/sdX
reboot

^ That presumes you have a non-UEFI system and /boot is on the main root partition, replace X & Y with the drive letter and root partition number.

Geoff 42 · 2020-07-30 18:34:50

Thank you for that, I will have a look at that.

The url for giving some grub rescue commands was :-

https://www.easytechstutorials.com/how- … -rescue-2/

Rather than the ones above!

It does sound as though the problem is quite widespread, so it may be a good idea to not do any upgrades involving grub...

Geoff

Head_on_a_Stick · 2020-07-30 18:39:24

Geoff 42 wrote:

The url for giving some grub rescue commands was :-
https://www.easytechstutorials.com/how- … -rescue-2/
Rather than the ones above!

I don't think you will be able to boot from the GRUB command line. Re-installing the bootloader should fix things.

See also https://bugs.launchpad.net/ubuntu/+sour … omments/16 (but my commands are simpler).

Geoff 42 · 2020-07-30 19:05:44

Thank you. I found a memory stick with Refracta Beowulf no dbus and managed to boot it and followed your commands.

I my case I mounted /dev/sda5 on /mnt.

As the problem seemed to be related to the update, I missed that step out, as well as the install grub-pc.
I did the

grub-install --boot-directory=/mnt /dev/sda
reboot

which worked. I gave the boot-directory as /mnt, because that partition is /boot rather than root.

I can now investigate things like grub versions etc.

Thank you again, helpful as ever

Geoff

Geoff 42 · 2020-07-30 19:34:34

Just for the record, looking in /var/log/apt/history.log, the latest upgrade was this morning :-

Start-Date: 2020-07-30 11:12:21
Commandline: apt full-upgrade
Upgrade: grub-common:amd64 (2.02+dfsg1-20, 2.02+dfsg1-20+deb10u1), grub-xen-bin:amd64 (2.02+dfsg1-20, 2.02+dfsg1-20+deb10u1), grub2-common:amd64 (2.02+dfsg1-20, 2.02+dfsg1-20+deb10u1), grub-pc:amd64 (2.02+dfsg1-20, 2.02+dfsg1-20+deb10u1), openjdk-11-jre-headless:amd64 (11.0.7+10-3~deb10u1, 11.0.8+10-1~deb10u1), grub-pc-bin:amd64 (2.02+dfsg1-20, 2.02+dfsg1-20+deb10u1), openjdk-11-jre:amd64 (11.0.7+10-3~deb10u1, 11.0.8+10-1~deb10u1), grub-xen-host:amd64 (2.02+dfsg1-20, 2.02+dfsg1-20+deb10u1), firefox-esr-l10n-en-gb:amd64 (68.10.0esr-1~deb10u1, 68.11.0esr-1~deb10u1), firefox-esr:amd64 (68.10.0esr-1~deb10u1, 68.11.0esr-1~deb10u1)
End-Date: 2020-07-30 11:13:33

So, I think that it was upgrading from the stable version to the stable-security version.

Geoff

Head_on_a_Stick · 2020-07-30 19:47:38

Yeah, the package was updated to fix https://nvd.nist.gov/vuln/detail/CVE-2020-10713 but it looks like it went a bit wrong.

Geoff 42 · 2020-07-30 19:52:07

This upgrade is referred to in :-

https://www.debian.org/security/2020/dsa-4735

which refers to a problem with grub_malloc and was suggested somewhere as being replaced with grub_calloc.

Geoff

Marjorie · 2020-07-30 21:27:13

Very odd. I got the same version (2.02+dfsg1-20+deb10u1) of grub-common with unattended -upgrades (which is for security updates only) at 9:45 this morning and it works fine (legacy-bios, not EFI-signed).

Geoff 42 · 2020-07-31 05:00:58

It may be that it is related to my disk layout, where /boot is its own partition and maybe grub failed to do the grub-install correctly. When I can get to my desktop machine, I will check the output from apt to see if I missed an error message.

/boot is my only ext partition, the rest being handled by LVM, not encrypted.

Geoff

Last edited by Geoff 42 (2020-07-31 05:01:40)

Geoff 42 · 2020-07-31 09:52:26

I have now checked in /var/log/apt/term.log and I can see no error messages. The relevant part seems to be :-

Setting up grub-pc (2.02+dfsg1-20+deb10u1) ...
Installing for i386-pc platform.
Installation finished. No error reported.
Including Xen overrides from /etc/default/grub.d/xen.cfg
Generating grub configuration file ...
Found theme: /usr/share/desktop-base/grub-themes/desktop-grub-theme/theme.txt
Found background image: Lake_mapourika_NZ.tga

before it trawls through all of the kernels and other partitions and finally saying

done

Geoff

Marjorie · 2020-07-31 12:24:58

Logged on this afternoon and unattended-upgrade has just updated grub-common.

Start-Date: 2020-07-31  12:10:26                                       
Commandline: /usr/bin/unattended-upgrade
Requested-By: marjorie (1000)
Upgrade: grub-common:amd64 (2.02+dfsg1-20+deb10u1, 2.02+dfsg1-20+deb10u2)
End-Date: 2020-07-31  12:10:28

Maybe this fixes the problem?

https://linuxsecurity.com/advisories/de … e-17-52-37

Package        : grub2
Debian Bug     : 966554

The update for grub2 released as DSA 4735-1 caused a boot-regression
when chainloading another bootlaoder and breaking notably dual-boot with
Windows. Updated grub2 packages are now available to correct this issue.

For the stable distribution (buster), this problem has been fixed in
version 2.02+dfsg1-20+deb10u2.

We recommend that you upgrade your grub2 packages.

For the detailed security status of grub2 please refer to its security
tracker page at:
https://security-tracker.debian.org/tracker/grub2

Oddly 'grub-common' is the only grub package I have on this PC, my other (my mail server) has 'grub-common', 'grub2-common', 'grub-pc' and and 'grub-pc-bin'. Both were fresh Beowulf Beta installs.

Last edited by Marjorie (2020-07-31 12:33:05)

Geoff 42 · 2020-07-31 14:17:39

I have fed some info into the Debian bug report.

https://bugs.debian.org/cgi-bin/bugrepo … bug=966575

but the deb10u2 does look like the fix and is available now on my machine, but I will wait until I hear from them in case they want any further info.

Geoff

Last edited by Geoff 42 (2020-07-31 14:18:07)

Vernon · 2020-07-31 19:14:01

I have Devuan Beowulf installed on a Dell Vostro netbook with legacy bios and no other operating systems installed and I had/have no issues with either grub upgrades.

rub-common/now 2.02+dfsg1-20+deb10u1 i386 [installed,upgradable to: 2.02+dfsg1-20+deb10u2]
grub-pc-bin/now 2.02+dfsg1-20+deb10u1 i386 [installed,upgradable to: 2.02+dfsg1-20+deb10u2]
grub-pc/now 2.02+dfsg1-20+deb10u1 i386 [installed,upgradable to: 2.02+dfsg1-20+deb10u2]
grub2-common/now 2.02+dfsg1-20+deb10u1 i386 [installed,upgradable to: 2.02+dfsg1-20+deb10u2]

grub-common/stable-security,now 2.02+dfsg1-20+deb10u2 i386 [installed]
grub-pc-bin/stable-security,now 2.02+dfsg1-20+deb10u2 i386 [installed,automatic]
grub-pc/stable-security,now 2.02+dfsg1-20+deb10u2 i386 [installed]
grub2-common/stable-security,now 2.02+dfsg1-20+deb10u2 i386 [installed,automatic]

Based on browsing the Internet, I believe the grub bug only effects UEFI systems with multiple operating systems installed. Please don't hesitate to provide corrections.

Geoff 42 · 2020-08-01 09:41:45

It does depend on your set-up, but is not just UEFI as my machine which broke has dos type disk labels.
I'm not sure whether it needs both multi-disk and/or multi-OS.
I have one SSD and one HDD and have the remnants of Win 7 although I haven't booted that for a very long time.
I also use Xen for trying out OSs, so have several on the HDD in their own partitions, under LVM.

Geoff

Geoff 42 · 2020-08-01 10:28:25

Via the Debian bug report 966575 I got a message from Colin Watson saying :-

You should use "dpkg-reconfigure grub-pc" to update the system's idea of
which disk(s) to install to in future, or this problem may recur in a
future upgrade.

So I tried :-

debconf-show grub-pc
  grub2/update_nvram: true
  grub-pc/install_devices_failed_upgrade: true
  grub2/kfreebsd_cmdline:
  grub-pc/chainload_from_menu.lst: true
  grub-pc/kopt_extracted: false
  grub-pc/install_devices_empty: false
  grub-pc/timeout: 5
  grub-pc/mixed_legacy_and_grub2: true
  grub-pc/postrm_purge_boot_grub: false
* grub2/linux_cmdline_default: earlyprintk=vga,keep vsyscall=emulate init=/sbin/openrc-init
  grub-pc/hidden_timeout: false
  grub-pc/partition_description:
* grub-pc/install_devices: /dev/disk/by-id/ata-WDC_WD10EZRX-00A8LB0_WD-WCC1U2741701
  grub-pc/install_devices_disks_changed:
  grub2/kfreebsd_cmdline_default: quiet
  grub-pc/install_devices_failed: false
* grub2/linux_cmdline:
  grub2/device_map_regenerated:
  grub2/force_efi_extra_removable: false
  grub-pc/disk_description:

dpkg-reconfigure grub-pc

which asked 3 questions, 2 about the command line and then about where to install.
It had selected /dev/sdb and I added /dev/sda (with the spacebar) :-

 The grub-pc package is being upgraded. This menu allows you to select which devices you'd like grub-install to be automatically run for, if any.
 Running grub-install automatically is recommended in most situations, to prevent the installed GRUB core image from getting out of sync with GRUB modules or grub.cfg.
 If you're unsure which drive is designated as boot drive by your BIOS, it is often a good idea to install GRUB to all of them.
 Note: it is possible to install GRUB to partition boot records as well, and some appropriate partitions are offered here. However, this forces GRUB to use the blocklist
 mechanism, which makes it less reliable, and therefore is not recommended.
 GRUB install devices:
    [*] /dev/sda (240057 MB; Corsair_Force_GS)
    [ ] - /dev/sda5 (262 MB; /boot)
    [ ] /dev/sda6 (239685 MB; LVM PV O44JvK-Gagl-jJ0w-aWwi-3qn0-Y2no-fbwG8Q on /dev/sda6)
    [*] /dev/sdb (1000204 MB; WDC_WD10EZRX-00A8LB0)
    [ ] /dev/sdb6 (882340 MB; LVM PV p10DED-cZEt-K24W-0Ov2-itdA-HOI8-EquJNg on /dev/sdb6)
    [ ] /dev/dm-0 (21474 MB; SSD0-root)
                                                                                   <Ok>

It then continues

Installing for i386-pc platform.
Installation finished. No error reported.
Installing for i386-pc platform.
Installation finished. No error reported.
Including Xen overrides from /etc/default/grub.d/xen.cfg
Generating grub configuration file ...
Found theme: /usr/share/desktop-base/grub-themes/desktop-grub-theme/theme.txt
Found background image: Lake_mapourika_NZ.tga
Found linux image: /boot/vmlinuz-4.19.0-9-amd64
... several kernels later ...
Found Windows 7 on /dev/sda1
Found Windows 7 on /dev/sdb1
...
Found Debian GNU/Linux jessie/sid on /dev/mapper/HDD0-xenguest1--disk
done

My system can still boot ;-) but looks as though it will now install onto both disks.

debconf-show grub-pc now reports :-

* grub-pc/install_devices: /dev/disk/by-id/ata-Corsair_Force_GS_133379020000987300E8, /dev/disk/by-id/ata-WDC_WD10EZRX-00A8LB0_WD-WCC1U2741701

Geoff

Geoff 42 · 2020-08-01 10:44:00

Colin Watson writes in the bug report :-

This is a long-standing problem: we get a scattering of reports of the
same general kind with every GRUB upgrade that changes the binary
interface between GRUB's core image and modules in some way, although
the exact details depend on the upgrade in question. The situation
certainly needs to be improved.
However, the problem is not with the actual changes made in this version
of GRUB. Rather, it's a latent configuration problem on your system
(and on the systems of other people affected by this) that is triggered
by the act of making *any* change to GRUB that causes new modules in
/boot/grub not to be compatible with old core images in the boot sector
that your firmware jumps to when booting your machine. This problem
happens on systems that are configured to run grub-install to a target
device that is not actually the one that your firmware uses to boot your
computer.
This configuration error is normally the result of something like
changing disks around without telling the GRUB packaging about it, so it
continues to install to an old device without realising it isn't the one
that your firmware is configured to boot from any more. Sometimes it's
the result of a bug in some kind of installation or cloning process
instead. Unfortunately it is rarely possible to tell exactly what
caused it from any information that still exists on the systems in
question; sometimes the affected users have an idea what might have
happened and sometimes they don't. The packaging tries to detect some
problems along these lines - I did considerable work on this way back in
2010 to try to improve the situation - and the volume of reports of this
kind is much lower than it used to be as a result, but it still happens
sometimes.

It is also mentioned that this is not a UEFI problem, although someone with UEFI was reporting a(nother) problem.

Geoff

Geoff 42 · 2020-08-01 10:57:01

Following the dpkg-reconfigure grub-pc I have now upgraded grub to the deb10u2 version and it still boots.

Geoff

uther · 2020-08-07 13:57:14

I've encountered the same problem as OP. However I have /boot on separate partition, and the rest part of the OS is encrypted.
Will this method work or should I change anything? I don't want to reinstall the whole system, as this is my main work machine.
I can boot in with live-iso. Thanks in advance.

sudo -i
mount /dev/sdXY /mnt
apt update && apt install grub-pc
grub-install --boot-directory=/mnt/boot /dev/sdX
reboot

So I've mounted /boot on /mnt and tried reinstall grub, but apt install grub-pc failes on nvme on which /boot partition is located.

root@devuan:~# grub-install --root-directory=/mnt/ /dev/nvme0n1
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.

I'm not very familiar with GRUB nor UEFI/BIOS internals. I found that above issue can be solved by creating small partition and flagging it with 'bios_grub:
https://blog.hostonnet.com/grub-install … e-possible
https://askubuntu.com/questions/671809/ … -partition

How to do it if all disc space is already taken? I have LUKS FDE on entire drive beside /boot. Should I cut part of /boot partition then? Also I have amd64 system and grub installer is i386 - is it normal?

Last edited by uther (2020-08-07 20:07:59)

fsmithred · 2020-08-07 17:57:59

Boot with live-iso, shrink the /boot partition and make a new partition. Do not format the new partition with a filesystem. (Unformatted is the last choice in gparted's dropdown list of formats.) Give it bios_grub flag (or type ef02 if you use gdisk).

You need at least 1MB for the bios_grub partition. I usually give it 2MB so I don't have to worry about what kind of MB I'm using.

uther · 2020-08-07 18:45:07

Thank you fsmithred. That fixed the issue.

Last edited by uther (2020-08-07 20:07:34)

Head_on_a_Stick · 2020-08-07 20:42:55

uther wrote:

So I've mounted /boot on /mnt and tried reinstall grub, but apt install grub-pc failes on nvme on which /boot partition is located.

root@devuan:~# grub-install --root-directory=/mnt/ /dev/nvme0n1
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.

My instructions were non-UEFI specific and if you have a GPT disk then you almost certainly had a UEFI system so you should have used

# apt update
# apt install grub-efi-amd64 # or grub-efi-ia32 for 32-bit UEFI implementations
# mount /dev/sdXY /mnt
# mkdir /efi
# mount /dev/sdXZ /efi
# grub-install --target=x86_64-efi --efi-directory=/efi --boot-directory=/mnt/boot
# umount /efi
# rmdir /efi
# reboot

Replace X with the drive letter, replace Y with the root partition number (or the /boot partition if that is separate, in which case omit /boot from the --boot-directory switch) and replace Z with the number for the EFI system partition.

uther wrote:

How to do it if all disc space is already taken?

I use sectors 34-2047 for BIOS boot partitions, that space should be free in a correctly-aligned disk.

uther wrote:

Also I have amd64 system and grub installer is i386 - is it normal?

The i386-pc bit refers to the non-UEFI bootloader rather than the system architecture.

jaromil · 2020-08-28 10:19:12

Head_on_a_Stick wrote:

Looks like you need to attempt a reinstallation of the bootloader.
Load up a beowulf live ISO image then
sudo -i
mount /dev/sdXY /mnt
apt update && apt install grub-pc
grub-install --boot-directory=/mnt/boot /dev/sdX
reboot
^ That presumes you have a non-UEFI system and /boot is on the main root partition, replace X & Y with the drive letter and root partition number.

I have stumbled into this horrible Grub bug myself and tried recovery from the Devuan Live 3.0 Beowulf image.

It worked! but for those in my same situation is worth knowing this slight variation:

I do not have EFI (and do not like to use UEFI) but the latest Grub keeps selecting it by default.

In my case this command worked:

 grub-install --target=i386-pc --boot-directory=/mnt/boot /dev/sdX

Else I kept receiving an error message from grub-install mentioning the boot directory "is not an EFI partition".

As you mentioned later in this thread, i386-pc does not relate to the CPU architecture, this is also required for AMD64 platforms.

The officially official Devuan Forum!

#1 2020-07-30 18:21:23

[Solved]Grub failing to boot - grub_calloc not found

#2 2020-07-30 18:30:32

Re: [Solved]Grub failing to boot - grub_calloc not found

#3 2020-07-30 18:34:50

Re: [Solved]Grub failing to boot - grub_calloc not found

#4 2020-07-30 18:39:24

Re: [Solved]Grub failing to boot - grub_calloc not found

#5 2020-07-30 19:05:44

Re: [Solved]Grub failing to boot - grub_calloc not found

#6 2020-07-30 19:34:34

Re: [Solved]Grub failing to boot - grub_calloc not found

#7 2020-07-30 19:47:38

Re: [Solved]Grub failing to boot - grub_calloc not found

#8 2020-07-30 19:52:07

Re: [Solved]Grub failing to boot - grub_calloc not found

#9 2020-07-30 21:27:13

Re: [Solved]Grub failing to boot - grub_calloc not found

#10 2020-07-31 05:00:58

Re: [Solved]Grub failing to boot - grub_calloc not found

#11 2020-07-31 09:52:26

Re: [Solved]Grub failing to boot - grub_calloc not found

#12 2020-07-31 12:24:58

Re: [Solved]Grub failing to boot - grub_calloc not found

#13 2020-07-31 14:17:39

Re: [Solved]Grub failing to boot - grub_calloc not found

#14 2020-07-31 19:14:01

Re: [Solved]Grub failing to boot - grub_calloc not found

#15 2020-08-01 09:41:45

Re: [Solved]Grub failing to boot - grub_calloc not found

#16 2020-08-01 10:28:25

Re: [Solved]Grub failing to boot - grub_calloc not found

#17 2020-08-01 10:44:00

Re: [Solved]Grub failing to boot - grub_calloc not found

#18 2020-08-01 10:57:01

Re: [Solved]Grub failing to boot - grub_calloc not found

#19 2020-08-07 13:57:14

Re: [Solved]Grub failing to boot - grub_calloc not found

#20 2020-08-07 17:57:59

Re: [Solved]Grub failing to boot - grub_calloc not found

#21 2020-08-07 18:45:07

Re: [Solved]Grub failing to boot - grub_calloc not found

#22 2020-08-07 20:42:55

Re: [Solved]Grub failing to boot - grub_calloc not found

#23 2020-08-28 10:19:12

Re: [Solved]Grub failing to boot - grub_calloc not found

Board footer