Bug#966575: grub-pc: error: symbol `grub_calloc' not found.

Colin Watson cjwatson at debian.org
Fri Jul 31 23:49:06 BST 2020


On Fri, Jul 31, 2020 at 02:06:53PM -0700, Chad Phillips wrote:
> This bug appears to affect a standard Vagrant install of Debian Buster as
> well. After booting, upgrading, and rebooting, I'm faced with the error.
> 
> The Vagrant base box is a fairly common one:
> https://app.vagrantup.com/bento/boxes/debian-10

I can reproduce this, but it only happens if you upgrade grub-pc
noninteractively, or if you upgrade it interactively and explicitly
choose to ignore the relatively insistent prompts about installing GRUB
somewhere.

You can see the problem here, after "vagrant init bento/debian-10" and
"vagrant up", before running the upgrade:

  vagrant at debian-10:~$ sudo debconf-show grub-pc | grep grub-pc/install_devices:
  * grub-pc/install_devices: /dev/disk/by-id/ata-VBOX_HARDDISK_VB9a8a894f-9374ac8c
  vagrant at debian-10:~$ ls -l /dev/disk/by-id
  total 0
  lrwxrwxrwx 1 root root  9 Jul 31 22:24 ata-VBOX_HARDDISK_VBeefaa213-4b33f182 -> ../../sda
  lrwxrwxrwx 1 root root 10 Jul 31 22:24 ata-VBOX_HARDDISK_VBeefaa213-4b33f182-part1 -> ../../sda1
  lrwxrwxrwx 1 root root 10 Jul 31 22:24 ata-VBOX_HARDDISK_VBeefaa213-4b33f182-part2 -> ../../sda2
  lrwxrwxrwx 1 root root 10 Jul 31 22:24 ata-VBOX_HARDDISK_VBeefaa213-4b33f182-part5 -> ../../sda5
  lrwxrwxrwx 1 root root 10 Jul 31 22:24 dm-name-debian--10--vg-root -> ../../dm-0
  lrwxrwxrwx 1 root root 10 Jul 31 22:24 dm-name-debian--10--vg-swap_1 -> ../../dm-1
  lrwxrwxrwx 1 root root 10 Jul 31 22:24 dm-uuid-LVM-AHa0Cuw3bi6DXPasmzrqEr387MQdhJrwITlGZz1P8nfxOHl0uLYcTkF0r0sDcIlc -> ../../dm-0
  lrwxrwxrwx 1 root root 10 Jul 31 22:24 dm-uuid-LVM-AHa0Cuw3bi6DXPasmzrqEr387MQdhJrwvb35YFl6T9W6Vy8Gh8qyNGl96xAtCwRz -> ../../dm-1
  lrwxrwxrwx 1 root root 10 Jul 31 22:24 lvm-pv-uuid-CP04tS-xWMP-4zmQ-WbUt-U8JQ-bIHD-IuGjp0 -> ../../sda5

It looks like the base VM image provided by bento/debian-10 hardcodes
some details of how it was built that don't carry over to other systems
booting the same image, and this causes problems.

debian/buster64 has a similar problem, but with different details.  It
has:

  vagrant at buster:~$ sudo debconf-show grub-pc | grep grub-pc/install_devices:
  * grub-pc/install_devices: /dev/vda

But when I booted that in virtualbox, /dev/vda doesn't exist.  Upgrading
grub-pc suggested that I install to /dev/sda instead.  (I suspect
/dev/vda would have worked with libvirt; I haven't used vagrant before
and haven't yet managed to get its libvirt provider to work with some
quirks of the libvirt setup on my laptop.)

> I'm using the (admittedly insecure) solution  of "sudo apt-mark hold grub*"
> shown here: https://askubuntu.com/a/1263204

As several comments there note, a better fix is "sudo dpkg-reconfigure
grub-pc".

This is in some ways the most interesting subtype of this bug, because
it's one we can easily reproduce!  It falls into the category of "error
in a cloning process"; but it also makes it relatively straightforward
to experiment with ways to mitigate the problem further.

We could at minimum make this be an upgrade error in the noninteractive
case, ensuring that it doesn't touch modules if the target device is
just plain missing: the upgrade error might be a bit rough for some
people, but it would be better than a boot failure.

A refinement of this might be that if the system only has one disk, and
that disk appears to have GRUB installed on it (by relatively crude boot
sector scanning), then we could assume that this is the common case of a
disk having been swapped out and automatically change
grub-pc/install_devices to point to that instead.  With appropriate
guard rails, I think that could help quite a lot of the people affected
by this sort of problem.

-- 
Colin Watson (he/him)                              [cjwatson at debian.org]



More information about the Pkg-grub-devel mailing list