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

Steve McIntyre 93sam at debian.org
Sat Aug 1 13:52:41 BST 2020


On Fri, Jul 31, 2020 at 11:49:06PM +0100, Colin Watson wrote:

...

>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

Ah!

>> 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".

Definitely!

>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.

Yes, definitely. Let's have a chat about how to do stuff. I was
thinking about some topics here:

 * Do we need to scan? if grub is installed and doing an upgrade and
   there is only one disk of an appropriate type (BIOS with DOS, or
   UEFI with GPT), then always install there?

 * (Maybe) we could add an option for grub-pc to always grub-install
   to *all* the BIOS-visible disks? Yes, I know there's a potential
   for breakage there with multi-boot systems. Maybe only do this on
   systems where os-prober has not found anything but the Debian
   installation?

 * If we do add the code to scan boot sectors, maybe check all the
   BIOS-visible disks and flag any that look like they have GRUB, but
   are not our version? (Not sure how feasible this is without
   digging!)

 * For UEFI, I'd love to switch to using the monolithic GRUB image
   even for non-signed use. It makes a lot of the issues go away if
   ~all the modules necessary for boot are always built-in.

 * Finally, we should also stop using debconf as a registry like we
   are. It's annoying the DSA folks (at least). By all means use
   debconf to help manage things, but we should be storing the lasting
   config in a config file that people can edit. We already store some
   of our stuff in /etc/default/grub, let's push more of our config
   there?


-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
          note stuck to the mini-bar saying "Paul: This fridge and
          fittings are the correct way around and do not need altering"



More information about the Pkg-grub-devel mailing list