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

[Paul Menzel]

Dear Steve,


I am sorry for the late reply, as I was on vacation.


Am 31.07.20 um 15:22 schrieb Steve McIntyre:


On Fri, Jul 31, 2020 at 06:39:20AM +0200, Paul Menzel wrote:

Am 31.07.20 um 06:30 schrieb Paul Menzel:


Am 30.07.20 um 23:54 schrieb Paul Menzel:

Package: grub-pc
Version: 2.04-9
Severity: grave



On a Acer TravelMate 5735Z with Debian Sid/unstable, upgrading the
package `grub-pc` causes GRUB to fail on next boot and drop into a
rescue shell.

  GRUB loading.
  Welcome to GRUB!

  error: symbol 'grub_calloc' not found.
  grub rescue>

It only seems to effects MBR installation.


I missed to report, that the system has a separate `/boot` partition and
a LUKS encrypted root `/`.


Sorry, please scratch that. I remembered incorrectly. It’s just one
unencrypted F2FS formatted partition.


How many disks do you have on your system, please?

*If* you have more than one, there's a potential for grub-install to
have not been run to install grub to all the MBRs, and then the BIOS
finds an old copy of the GRUB first-stage loader but tries to use
newer modules. this mis-match can cause all kinds of problems. :-/


There is only one disk in that laptop.


Kind regards,

Paul

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

[Karl Schmidt]

Triggered this with an apt upgrade dist-upgrade


APT::Default-Release "buster";

grub-pc   2.02+dfsg1-20+deb10u2

,.,.
This system had mirrored drives -

Had to boot off a thumbdrive - enter rescue -  when it asked for the boot drive - had to tell it to 
build raid - then select the raid ( /dev/md0) as the boot drive.


There then was a menu item to fix grub - wondered if it worked - so I entered a shell and did an 
update-grub2


After reboot all was well.

I don't know if this will repeat or not?



Be kind to the developers - it has been over a decade for a nasty like this to sneak by - which is 
amazing.



Karl Schmidt  EMail k...@lrak.net
3209 West 9th Street Ph (785) 979-8397
Lawrence, KS 66049

Politicians are authors of fiction that specialize in the genre of the false 
narrative. -kps

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

[Steve McIntyre]

>From conversation in IRC:

1. If the device(s) mentioned in grub-pc/install_devices multiselect
   don't exist when grub-install is run, it should stop and warn the
   user that there might be a problem

   DSA have this on a VM, for example:

   grub-pc grub-pc/install_devices 
multiselect/dev/disk/by-id/scsi-3600508b1001052395358323050350006

2. Warn if install_devices is empty?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane

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

[Steve McIntyre]

[ Dropping the CC to Chad here ]

On Sat, Aug 01, 2020 at 02:36:25PM +0100, Colin Watson wrote:
>On Sat, Aug 01, 2020 at 01:52:41PM +0100, Steve McIntyre wrote:
>>  * 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?
>
>Possibly.  I'd still be inclined to have a scan as a guard-rail in that
>case, since we'd need to have the code anyway, and the point is to try
>to discover the disk that the system booted from so by definition it
>must have GRUB there if it's to be valid.

Nod. Of course, it's a guess at best - we have ~no way to know *for
sure* which disk we actually booted off. It would be lovely if we did,
but there's no protocol for grub to pass on that information that I
can see.

>>  * (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?
>
>One concern I have is filtering out things like optical drives, which
>are BIOS-visible but not sensible grub-install targets.  I'm also
>slightly reluctant to add more invocations of os-prober while it's as
>slow as it can sometimes be.  I do see the utility of this though.

Nod. Can we not rely on os-prober already having been run once and use
that data? (Sorry, not sure of the ordering here.)

>>  * 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!)
>
>Unfortunately I believe this to be essentially infeasible.  As an
>illustration, this is the scan code which exists in the current postinst
>to support migration from GRUB Legacy, and believe me I didn't resort to
>this horror before trying to find more sensible alternatives:
>
>  # In order to determine whether we accidentally ran grub-install without
>  # upgrade-from-grub-legacy on versions older than 1.98+20100617-1, we need
>  # to be able to scan a disk to determine whether GRUB 2 was installed in its
>  # boot sector.  This is specific to i386-pc (but that's the only platform
>  # where we need it).
>  scan_grub2()
>  {
>if ! dd if="$1" bs=512 count=1 2>/dev/null | grep -aq GRUB; then
>  # No version of GRUB is installed.
>  return 1
>fi
>  
># The GRUB boot sector always starts with a JMP instruction.
>initial_jmp="$(dd if="$1" bs=2 count=1 2>/dev/null | od -Ax -tx1 | \
>   head -n1 | cut -d' ' -f2,3)"
>[ "$initial_jmp" ] || return 1
>initial_jmp_opcode="${initial_jmp%% *}"
>[ "$initial_jmp_opcode" = eb ] || return 1
>initial_jmp_operand="${initial_jmp#* }"
>case $initial_jmp_operand in
>  47|4b|4c|63)
># I believe this covers all versions of GRUB 2 up to the package
># version where we gained a more explicit mechanism.  GRUB Legacy
># always had 48 here.
>return 0
>  ;;
>esac
>  
>return 1
>  }
>
>The actual package version does get embedded in the boot loader, but
>only in the "normal" module, not anywhere that could be usefully
>discovered by a scan.  Otherwise the best we could do would basically be
>a big list of signatures, which I'm not enthusiastic about.

Argh, yes. Basically what I expected, I'll be honest. Oh, hmmm -
that's the boot sector. Could we pick up on more from the embedded
binary "stage 1.5" lump? This is getting hairy, maybe, but
could/should be a wider thing to go upstream?

>>  * 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.
>
>I think I agree, though we should take that to a separate bug; I'd like
>to keep this one for the BIOS situation.

Agreed. Just something I thought to mention while it was in my
head. :-)

>>  * 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?
>
>Agreed in general terms; this has been on my to-do list for a long time.
>Of course we need to consider the migration path carefully.  In terms of
>specifics, I'm not sure I want to extend /etc/default/grub for this,
>though; that has configuration file management issues, and generally I
>don't really want to overload the upstream grub-mkconfig configuration
>file with packaging-specific things for grub-install.  I'd be inclined
>to go for /etc/default/grub-pc instead, or maybe something under
>/etc/grub/.

Sure. 

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

[Colin Watson]

On Sat, Aug 01, 2020 at 01:52:41PM +0100, Steve McIntyre wrote:
>  * 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?

Possibly.  I'd still be inclined to have a scan as a guard-rail in that
case, since we'd need to have the code anyway, and the point is to try
to discover the disk that the system booted from so by definition it
must have GRUB there if it's to be valid.

>  * (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?

One concern I have is filtering out things like optical drives, which
are BIOS-visible but not sensible grub-install targets.  I'm also
slightly reluctant to add more invocations of os-prober while it's as
slow as it can sometimes be.  I do see the utility of this though.

>  * 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!)

Unfortunately I believe this to be essentially infeasible.  As an
illustration, this is the scan code which exists in the current postinst
to support migration from GRUB Legacy, and believe me I didn't resort to
this horror before trying to find more sensible alternatives:

  # In order to determine whether we accidentally ran grub-install without
  # upgrade-from-grub-legacy on versions older than 1.98+20100617-1, we need
  # to be able to scan a disk to determine whether GRUB 2 was installed in its
  # boot sector.  This is specific to i386-pc (but that's the only platform
  # where we need it).
  scan_grub2()
  {
if ! dd if="$1" bs=512 count=1 2>/dev/null | grep -aq GRUB; then
  # No version of GRUB is installed.
  return 1
fi
  
# The GRUB boot sector always starts with a JMP instruction.
initial_jmp="$(dd if="$1" bs=2 count=1 2>/dev/null | od -Ax -tx1 | \
   head -n1 | cut -d' ' -f2,3)"
[ "$initial_jmp" ] || return 1
initial_jmp_opcode="${initial_jmp%% *}"
[ "$initial_jmp_opcode" = eb ] || return 1
initial_jmp_operand="${initial_jmp#* }"
case $initial_jmp_operand in
  47|4b|4c|63)
# I believe this covers all versions of GRUB 2 up to the package
# version where we gained a more explicit mechanism.  GRUB Legacy
# always had 48 here.
return 0
  ;;
esac
  
return 1
  }

The actual package version does get embedded in the boot loader, but
only in the "normal" module, not anywhere that could be usefully
discovered by a scan.  Otherwise the best we could do would basically be
a big list of signatures, which I'm not enthusiastic about.

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

I think I agree, though we should take that to a separate bug; I'd like
to keep this one for the BIOS situation.

>  * 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?

Agreed in general terms; this has been on my to-do list for a long time.
Of course we need to consider the migration path carefully.  In terms of
specifics, I'm not sure I want to extend /etc/default/grub for this,
though; that has configuration file management issues, and generally I
don't really want to overload the upstream grub-mkconfig configuration
file with packaging-specific things for grub-install.  I'd be inclined
to go for /etc/default/grub-pc instead, or maybe something under
/etc/grub/.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

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

[Steve McIntyre]

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

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

[Colin Watson]

On Sat, Aug 01, 2020 at 01:32:33PM +0200, Miklos Quartus wrote:
> I am reporting this bug here

Please could you file this as a *new* bug report, *not* as a followup to
#966575 which I would much rather keep for just the more common BIOS
case?  Ideally you would do this by typing "reportbug grub-efi-amd64"
and following the prompts from there; this will automatically include
some more information about your system that you haven't yet provided.

If reportbug doesn't work for some reason, you can send email to
sub...@bugs.debian.org with this paragraph at the top of your email:

Package: grub-efi-amd64
Version: 2.02+dfsg1-20+deb10u2

... and we can ask for more information from there.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

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

[cacatoes]

Hello,

My case was indeed a disk switch from USB to internal.

I probably had invoked directly grub-install (dunno if it'd make sense
to warn about the mismatch with debconf there?), now I know I should
rather use dpkg-reconfigure instead.

# debconf-get-selections |grep 'grub-pc/install_devices'
grub-pc grub-pc/install_devices_disks_changed   multiselect
/dev/disk/by-id/usb-KINGSTON_SA400S37240G_AB12362D-0:0
grub-pc grub-pc/install_devices_failed_upgrade  boolean true
grub-pc grub-pc/install_devices_failed  boolean false
grub-pc grub-pc/install_devices_empty   boolean false
grub-pc grub-pc/install_devices multiselect
/dev/disk/by-id/usb-KINGSTON_SA400S37240G_AB12362D-0:0

# ls /dev/disk/by-id/usb-KINGSTON_SA400S37240G_AB12362D-0:0
ls: impossible d'accéder à
'/dev/disk/by-id/usb-KINGSTON_SA400S37240G_AB12362D-0:0': Aucun
fichier ou dossier de ce type

# ls /dev/disk/by-id/ata-KINGSTON_SA400S37240G_50026B7683315755 
/dev/disk/by-id/ata-KINGSTON_SA400S37240G_50026B7683315755@

# dpkg-reconfigure grub-pc

# debconf-get-selections |grep 'grub-pc/install_devices'
grub-pc grub-pc/install_devices_failed  boolean false
grub-pc grub-pc/install_devices multiselect
/dev/disk/by-id/ata-KINGSTON_SA400S37240G_50026B7683315755
grub-pc grub-pc/install_devices_disks_changed   multiselect
/dev/disk/by-id/ata-KINGSTON_SA400S37240G_50026B7683315755
grub-pc grub-pc/install_devices_empty   boolean false
grub-pc grub-pc/install_devices_failed_upgrade  boolean true

Thanks for the explanations!

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

[Colin Watson]

On Sat, Aug 01, 2020 at 01:23:30AM +0200, MichaIng wrote:
> we face the same issue whenever a ready-to-run image has been created and
> booted from a different device.
> 
> From what we found, the Debian installer (or the grub install/config
> scripts) stores the hardware ID of the drive to debconf database, if one is
> available. Of course on a different machine this identifier and the related
> /dev/disk/by-id/ path is invalid. On VirtualBox and non-virtual PCs this is
> usually the case, on VMware on the other hand, ho hardware identifier
> exists, hence /dev/sda is stored there which is still valid when importing
> the same image to other VMware machines.

Indeed.

> I suggest to do the grub target check on `preinst` and skip/fail with error
> code if the debconf entry is invalid. It is better to skip or break the
> package upgrade and force admins to check/run manually then letting them
> running into a unbootable system.

That's fairly close to one of my suggestions in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966575#102.  It's not
necessary to move things to the preinst to make this work; it just needs
to be checked a bit more thoroughly before the postinst runs
grub-install.

> Otherwise elegant would be a scan to find the matching grub instance, but
> not sure how easy this is. At least the bootloader locations are fixed?

In principle it's impossible.  In practice it may be possible to do some
degree of guesswork; that's one of my other suggestions in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966575#102. :-)  We do
have to be pretty conservative though, as going overboard is likely to
break some multiboot setups.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

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

[Chad Phillips]

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'm guessing this is a fairly standard disk layout in their build:

# fdisk -l
Disk /dev/sda: 64 GiB, 68719476736 bytes, 134217728 sectors
Disk model: VBOX HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1b8eb89d

Device Boot  Start   End   Sectors  Size Id Type
/dev/sda1  *  2048499711497664  243M 83 Linux
/dev/sda2   501758 134215679 133713922 63.8G  5 Extended
/dev/sda5   501760 134215679 133713920 63.8G 8e Linux LVM


Disk /dev/mapper/debian--10--vg-root: 62.8 GiB, 67385688064 bytes,
131612672 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/debian--10--vg-swap_1: 1 GiB, 1073741824 bytes, 2097152
sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

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

Chad

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

[Steve McIntyre]

Hi John,

On Fri, Jul 31, 2020 at 09:29:43AM +0100, John Lines wrote:
>I have the same error, on a DNUK Workstar 700, dating back to 2014, so
>upgraded from squeeze on up to buster.It is possible this legacy which
>has resulted in something unusual in the grub configuration. 
>
>I upgraded grub yesterday, and am working on recovering now. Posting
>from another system.

ACK. Same thing applies as I suggested to Paul - maybe an inconsistent
set of updates. Do you have multiple disks? If so, try "grub-install
" on all the bootable disks and that may fix your problem. If
not, please get back to us ASAP and we'll try to debug the problem
here.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back

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

[Steve McIntyre]

Hi Paul,

On Fri, Jul 31, 2020 at 06:39:20AM +0200, Paul Menzel wrote:
>Am 31.07.20 um 06:30 schrieb Paul Menzel:
>
>> Am 30.07.20 um 23:54 schrieb Paul Menzel:
>> > Package: grub-pc
>> > Version: 2.04-9
>> > Severity: grave
>> 
>> > On a Acer TravelMate 5735Z with Debian Sid/unstable, upgrading the
>> > package `grub-pc` causes GRUB to fail on next boot and drop into a
>> > rescue shell.
>> > 
>> >  GRUB loading.
>> >  Welcome to GRUB!
>> > 
>> >  error: symbol 'grub_calloc' not found.
>> >  grub rescue>
>> > 
>> > It only seems to effects MBR installation.
>> 
>> I missed to report, that the system has a separate `/boot` partition and
>> a LUKS encrypted root `/`.
>
>Sorry, please scratch that. I remembered incorrectly. It’s just one
>unencrypted F2FS formatted partition.

How many disks do you have on your system, please?

*If* you have more than one, there's a potential for grub-install to
have not been run to install grub to all the MBRs, and then the BIOS
finds an old copy of the GRUB first-stage loader but tries to use
newer modules. this mis-match can cause all kinds of problems. :-/

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

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

[John Lines]

I have the same error, on a DNUK Workstar 700, dating back to 2014, so
upgraded from squeeze on up to buster.It is possible this legacy which
has resulted in something unusual in the grub configuration. 

I upgraded grub yesterday, and am working on recovering now. Posting
from another system.

John Lines

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

[Paul Menzel]

Dear Debian folks,


Am 31.07.20 um 06:30 schrieb Paul Menzel:


Am 30.07.20 um 23:54 schrieb Paul Menzel:

Package: grub-pc
Version: 2.04-9
Severity: grave


On a Acer TravelMate 5735Z with Debian Sid/unstable, upgrading the 
package `grub-pc` causes GRUB to fail on next boot and drop into a 
rescue shell.


 GRUB loading.
 Welcome to GRUB!

 error: symbol 'grub_calloc' not found.
 grub rescue>

It only seems to effects MBR installation.


I missed to report, that the system has a separate `/boot` partition and 
a LUKS encrypted root `/`.


Sorry, please scratch that. I remembered incorrectly. It’s just one 
unencrypted F2FS formatted partition.


Is there a way to boot the system using the rescue shell, or is a live 
system needed?



Sorry for the noise. Kind regards,

Paul


PS: The Ubuntu report is #1889509 [1].


[1]: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509

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

[Paul Menzel]

Dear Debian folks,


Am 30.07.20 um 23:54 schrieb Paul Menzel:

Package: grub-pc
Version: 2.04-9
Severity: grave


On a Acer TravelMate 5735Z with Debian Sid/unstable, upgrading the 
package `grub-pc` causes GRUB to fail on next boot and drop into a 
rescue shell.


     GRUB loading.
     Welcome to GRUB!

     error: symbol 'grub_calloc' not found.
     grub rescue>

It only seems to effects MBR installation.


I missed to report, that the system has a separate `/boot` partition and 
a LUKS encrypted root `/`.


Is there a way to boot the system using the rescue shell, or is a live 
system needed?



Kind regards,

Paul



PS: The Ubuntu report is #1889509 [1].


[1]: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509

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

[Paul Menzel]

Package: grub-pc
Version: 2.04-9
Severity: grave

Dear Debian folks,


On a Acer TravelMate 5735Z with Debian Sid/unstable, upgrading the 
package `grub-pc` causes GRUB to fail on next boot and drop into a 
rescue shell.


GRUB loading.
Welcome to GRUB!

error: symbol 'grub_calloc' not found.
grub rescue>

It only seems to effects MBR installation.

Is there a way to boot the system using the rescue shell, or is a live 
system needed?



Kind regards,

Paul


PS: The Ubuntu report is #1889509 [1].


[1]: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509