Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1019862 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#966575: grub-pc: error: symbol `grub_calloc' not found. Paul Menzel <pmenzel@molgen.mpg.de> - 2020-07-31 00:00 +0200
    Bug#966575: grub-pc: error: symbol `grub_calloc' not found. Paul Menzel <pmenzel@molgen.mpg.de> - 2020-07-31 06:40 +0200
    Bug#966575: I was affected as well Norbert Kiesel <nkiesel@gmail.com> - 2020-07-31 08:40 +0200
      Bug#966575: I was affected as well Steve McIntyre <93sam@debian.org> - 2020-07-31 15:30 +0200
    Bug#966575: Security update can break grub - grub_calloc not found Geoff Gibbs <g.gibbs42@gmx.co.uk> - 2020-07-31 13:00 +0200
      Bug#966575: Security update can break grub - grub_calloc not found Steve McIntyre <steve@einval.com> - 2020-07-31 15:40 +0200
        Bug#966575: Security update can break grub - grub_calloc not found Geoff Gibbs <g.gibbs42@gmx.co.uk> - 2020-07-31 16:10 +0200
          Bug#966575: Security update can break grub - grub_calloc not found Steve McIntyre <93sam@debian.org> - 2020-07-31 16:30 +0200
          Bug#966575: Security update can break grub - grub_calloc not found Colin Watson <cjwatson@debian.org> - 2020-08-01 01:10 +0200
    Bug#966575: grub-pc: error: symbol `grub_calloc' not found. Steve McIntyre <93sam@debian.org> - 2020-07-31 15:30 +0200
    Bug#966575: grub-pc: error: symbol `grub_calloc' not found Steve McIntyre <93sam@debian.org> - 2020-07-31 15:40 +0200
    Bug#966575: same error message here cacatoes@tuxfamily.org - 2020-07-31 23:00 +0200
    Bug#966575: grub-pc: error: symbol `grub_calloc' not found. Chad Phillips <thehunmonkgroup@gmail.com> - 2020-07-31 23:10 +0200
      Bug#966575: grub-pc: error: symbol `grub_calloc' not found. Colin Watson <cjwatson@debian.org> - 2020-08-01 01:00 +0200
        Bug#966575: grub-pc: error: symbol `grub_calloc' not found. Steve McIntyre <93sam@debian.org> - 2020-08-01 15:00 +0200
          Bug#966575: grub-pc: error: symbol `grub_calloc' not found. Colin Watson <cjwatson@debian.org> - 2020-08-01 15:40 +0200
            Bug#966575: grub-pc: error: symbol `grub_calloc' not found. Steve McIntyre <93sam@debian.org> - 2020-08-01 16:40 +0200
    Bug#966575: same error message here Colin Watson <cjwatson@debian.org> - 2020-08-01 01:10 +0200
    Bug#966575: grub-pc: error: symbol `grub_calloc' not found. MichaIng <micha@dietpi.com> - 2020-08-01 01:30 +0200
    Bug#966575: same error message here Colin Watson <cjwatson@debian.org> - 2020-08-01 02:10 +0200
    Bug#966575: Requested information about affected system (two disks, no raid) "Christoph K." <christoph@kobenetz.de> - 2020-08-03 14:10 +0200
    Bug#966575: How to fix LLVM/LUKS installs? Todd Howe <todhowe@sourcefire.com> - 2020-08-11 19:00 +0200
      Bug#966575: How to fix LLVM/LUKS installs? Colin Watson <cjwatson@debian.org> - 2020-08-11 19:10 +0200

Page 1 of 2  [1] 2  Next page →

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

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

[toc] | [next] | [standalone]

#1019889

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

[toc] | [prev] | [next] | [standalone]

#1019898 — Bug#966575: I was affected as well

[Multipart message — attachments visible in raw view] — view raw

 This is a laptop running Debain Unstable with 2 SSD and one spinning
disk.  After upgrade and install, system stopped with same error message
during boot.

I was able to reactivate using a live boot system.

[toc] | [prev] | [next] | [standalone]

#1019949 — Bug#966575: I was affected as well

Hi Norbert,

On Thu, Jul 30, 2020 at 11:26:15PM -0700, Norbert Kiesel wrote:
>This is a laptop running Debain Unstable with 2 SSD and one spinning disk. 
>After upgrade and install, system stopped with same error message during boot.
>
>I was able to reactivate using a live boot system.

ACK. Same thing applies as I suggested to Paul - maybe an inconsistent
set of updates. Have you *fixed* the problem by using the live boot?

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
There's no sensation to compare with this
Suspended animation, A state of bliss

[toc] | [prev] | [next] | [standalone]

#1019926 — Bug#966575: Security update can break grub - grub_calloc not found

apt update
apt full-upgrade

grub upgrades

from 2.02+dfsg1-20
to 2.02+dfsg1-20+deb10u1

no errors were spotted.

When rebooted :-

symbol grub_calloc not found
Entering rescue mode
grub rescue>


I had to boot off a memory stick and then :-

sudo -i
mount /dev/sda5 /mnt
grub-install --boot-directory=/mnt /dev/sda
reboot

This worked and the system now boots.

/boot is the only ext type file system, the others are all handled by LVM

Geoff

[toc] | [prev] | [next] | [standalone]

#1019951 — Bug#966575: Security update can break grub - grub_calloc not found

Hi Geoff,

On Fri, Jul 31, 2020 at 11:54:20AM +0100, Geoff Gibbs wrote:
>apt update
>apt full-upgrade
>
>grub upgrades
>
>from 2.02+dfsg1-20
>to 2.02+dfsg1-20+deb10u1
>
>no errors were spotted.
>
>When rebooted :-
>
>symbol grub_calloc not found
>Entering rescue mode
>grub rescue>
>
>
>I had to boot off a memory stick and then :-
>
>sudo -i
>mount /dev/sda5 /mnt
>grub-install --boot-directory=/mnt /dev/sda
>reboot
>
>This worked and the system now boots.
>
>/boot is the only ext type file system, the others are all handled by LVM

I'm guessing - do you have multiple disks on your system? If so, try
"grub-install <disk>" on each of the bootable disks and that should
fix your problem.

I think we need a proper fix for this in the longer term, but that's
not going to happen overnight.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me 

[toc] | [prev] | [next] | [standalone]

#1019956 — Bug#966575: Security update can break grub - grub_calloc not found

On Fri, 31 Jul 2020 14:30:14 +0100
Steve McIntyre <steve@einval.com> wrote:

> I'm guessing - do you have multiple disks on your system? If so, try
> "grub-install <disk>" on each of the bootable disks and that should
> fix your problem.

As I mentioned,

mount /dev/sda5 /mnt
grub-install --boot-directory=/mnt /dev/sda

has fixed the problem for me.

fdisk -l reports :-

Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors
Disk model: Corsair Force GS
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: 0xc1920bad

Device     Boot  Start       End   Sectors   Size Id Type
/dev/sda1  *      2048    206847    204800   100M  7 HPFS/NTFS/exFAT
/dev/sda2       210942 468860927 468649986 223.5G  5 Extended
/dev/sda5       210944    722943    512000   250M 83 Linux
/dev/sda6       724992 468860927 468135936 223.2G 8e Linux LVM


Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC WD10EZRX-00A
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xc1920ba9

Device     Boot     Start        End    Sectors   Size Id Type
/dev/sdb1  *         2048  209717247  209715200   100G  7 HPFS/NTFS/exFAT
/dev/sdb2       209721342 1953523711 1743802370 831.5G  5 Extended
/dev/sdb5       209721344  230201343   20480000   9.8G 82 Linux swap / Solaris
/dev/sdb6       230203392 1953523711 1723320320 821.8G 8e Linux LVM

Partition 2 does not start on physical sector boundary.

And then there is a list of partitions handled by LVM (many for Xen)
but including :-

Disk /dev/mapper/SSD0-root: 20 GiB, 21474836480 bytes, 41943040 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/HDD0-var: 9.3 GiB, 9999220736 bytes, 19529728 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/mapper/SSD0-home: 38.6 GiB, 41473277952 bytes, 81002496 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

Geoff

[toc] | [prev] | [next] | [standalone]

#1019960 — Bug#966575: Security update can break grub - grub_calloc not found

On Fri, Jul 31, 2020 at 03:07:58PM +0100, Geoff Gibbs wrote:
>On Fri, 31 Jul 2020 14:30:14 +0100
>Steve McIntyre <steve@einval.com> wrote:
>
>> I'm guessing - do you have multiple disks on your system? If so, try
>> "grub-install <disk>" on each of the bootable disks and that should
>> fix your problem.
>
>As I mentioned,
>
>mount /dev/sda5 /mnt
>grub-install --boot-directory=/mnt /dev/sda
>
>has fixed the problem for me.

Yup. Sorry - I saw that. Trying to respond to lots of people atm...

>fdisk -l reports :-
>
>Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors
>Disk model: Corsair Force GS
>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: 0xc1920bad
>
>Device     Boot  Start       End   Sectors   Size Id Type
>/dev/sda1  *      2048    206847    204800   100M  7 HPFS/NTFS/exFAT
>/dev/sda2       210942 468860927 468649986 223.5G  5 Extended
>/dev/sda5       210944    722943    512000   250M 83 Linux
>/dev/sda6       724992 468860927 468135936 223.2G 8e Linux LVM
>
>
>Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
>Disk model: WDC WD10EZRX-00A
>Units: sectors of 1 * 512 = 512 bytes
>Sector size (logical/physical): 512 bytes / 4096 bytes
>I/O size (minimum/optimal): 4096 bytes / 4096 bytes
>Disklabel type: dos
>Disk identifier: 0xc1920ba9
>
>Device     Boot     Start        End    Sectors   Size Id Type
>/dev/sdb1  *         2048  209717247  209715200   100G  7 HPFS/NTFS/exFAT
>/dev/sdb2       209721342 1953523711 1743802370 831.5G  5 Extended
>/dev/sdb5       209721344  230201343   20480000   9.8G 82 Linux swap / Solaris
>/dev/sdb6       230203392 1953523711 1723320320 821.8G 8e Linux LVM
>
>Partition 2 does not start on physical sector boundary.
>
>And then there is a list of partitions handled by LVM (many for Xen)
>but including :-
>
>Disk /dev/mapper/SSD0-root: 20 GiB, 21474836480 bytes, 41943040 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/HDD0-var: 9.3 GiB, 9999220736 bytes, 19529728 sectors
>Units: sectors of 1 * 512 = 512 bytes
>Sector size (logical/physical): 512 bytes / 4096 bytes
>I/O size (minimum/optimal): 4096 bytes / 4096 bytes
>
>Disk /dev/mapper/SSD0-home: 38.6 GiB, 41473277952 bytes, 81002496 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

ACK. I tend to do "fdisk -l /dev/sd?" to avoid that behaviour on my
md/lvm machine here. :-)

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

[toc] | [prev] | [next] | [standalone]

#1020012 — Bug#966575: Security update can break grub - grub_calloc not found

On Fri, Jul 31, 2020 at 03:07:58PM +0100, Geoff Gibbs wrote:
> mount /dev/sda5 /mnt
> grub-install --boot-directory=/mnt /dev/sda
> 
> has fixed the problem for me.

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.

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

[toc] | [prev] | [next] | [standalone]

#1019950

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.                                steve@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

[toc] | [prev] | [next] | [standalone]

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

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
<disk>" 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.                                steve@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back

[toc] | [prev] | [next] | [standalone]

#1020001 — Bug#966575: same error message here

[Multipart message — attachments visible in raw view] — view raw

Package: grub-pc
Version: 2.02+dfsg1-20+deb10u2

Dear Maintainers,

Don't know if it's useful but contributing infos I collected on this,
since I ran into the same error message on a Lenovo Thinkpad T510
running Debian Stable.

Some specifics are :
- I use unattended-upgrades, so it might be I missed something
- Install was made with no root password set, but I set one recently.
- It has a LUKS partition but it's secondary and not a system mount
  point.
- It runs a kernel from the backports.

What happened :

Start-Date: 2020-07-30  09:09:13
Commandline: /usr/bin/unattended-upgrade
Upgrade: grub-common: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), grub-pc-bin:amd64
(2.02+dfsg1-20, 2.02+dfsg1-20+deb10u1)
End-Date: 2020-07-30  09:09:25

Start-Date: 2020-07-30  09:09:27
Commandline: /usr/bin/unattended-upgrade
Upgrade: firefox-esr-l10n-fr: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  09:09:38

Start-Date: 2020-07-31  10:41:26
Commandline: /usr/bin/unattended-upgrade
Upgrade: grub-common:amd64 (2.02+dfsg1-20+deb10u1,
2.02+dfsg1-20+deb10u2), grub2-common:amd64 (2.02+dfsg1-20+deb10u1,
2.02+dfsg1-20+deb10u2), grub-pc:amd64 (2.02+dfsg1-20+deb10u1,
2.02+dfsg1-20+deb10u2), grub-pc-bin:amd64 (2.02+dfsg1-20+deb10u1,
2.02+dfsg1-20+deb10u2)
End-Date: 2020-07-31  10:41:36

Reboot on 2020-07-31 @ 22:00:00, then same error message than OP.

Fixed situation by rebooting on a USB key with Debian installer, rescue
mode, reinstalling grub on /dev/sda.

More system infos in attachment.

[toc] | [prev] | [next] | [standalone]

#1020002

[Multipart message — attachments visible in raw view] — view raw

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  *      2048    499711    497664  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

[toc] | [prev] | [next] | [standalone]

#1020010

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@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@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@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@debian.org]

[toc] | [prev] | [next] | [standalone]

#1020053

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

[toc] | [prev] | [next] | [standalone]

#1020057

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)                              [cjwatson@debian.org]

[toc] | [prev] | [next] | [standalone]

#1020063

[ 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. The exact setup is something we can work out. But of course (?)
we *should* be dealing with this properly as a user-facing config
file. What's the problem with /etc/default/grub, OOI?

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis

[toc] | [prev] | [next] | [standalone]

#1020011 — Bug#966575: same error message here

On Fri, Jul 31, 2020 at 11:27:18PM +0200, Miklós Quartus wrote:
> The same here. You should be more careful when upgrading or fixing a
> security issue in the boot loader.

We do take considerable care - the fact that sometimes problems slip
through doesn't mean we weren't careful.  (In general, this type of
problem relates to oddities of particular people's systems.)

> It currently breaks a Debian Buster system, which is production. The
> suggested grub reinstall method did _not_ work for me. I booted from a
> USB stick into rescue mode and had to downgrade grub-common package (I
> don’t have grub2 on my system) and reinstall all dependent packages
> again. After downgrading grub-common/grub2-common to version
> 2.02+dfsg1-20, my system boots and works fine.

Unlike other folks reporting this bug, you seem to be using UEFI.  That
means that you have a completely different problem, even though it
presents with similar symptoms.

Could you please file a *separate* bug report with details of the
problem you encountered?  We're also likely to need to know the
disk/partition/filesystem layout of your system, whether you're using
UEFI Secure Boot, and anything else that might be interesting about how
your machine boots.  This isn't the same thing as the other problems in
this bug, and we'll need to investigate it separately.

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

[toc] | [prev] | [next] | [standalone]

#1020013

Hey guys,

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.

Since there is no software ID for non-fs disks like a UUID, the 
behaviour to use the hardware ID seems reasonable, to not rely on the 
bid unpredictable /dev/sd* path. However that this easily leads to 
unbootable systems when doing such trivial thing like booting a disk 
image and run some automated package upgrades on a new machine is a 
serious issue.

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.

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?

Proactive fix, where "/dev/sda" needs to be replaced in case:
-------
debconf-set-selections <<< 'grub-pc grub-pc/install_devices multiselect 
/dev/sda'
-------
Or of course use the hardware identifier path found in /dev/disk/by-id/.

Best regards,
Micha

[toc] | [prev] | [next] | [standalone]

#1020014 — Bug#966575: same error message here

Control: severity -1 grave

On Fri, Jul 31, 2020 at 10:40:34PM +0100, Colin Watson wrote:
> I'm going to downgrade this to non-release-critical.  It is absolutely a
> problem that we need to deal with (somehow ... it may be that in some
> cases we need to refuse to continue the upgrade instead, which would be
> a different kind of bug that would tend to be filed as release-critical
> too!), but given that it's a latent problem that would have been exposed
> by any change of a similar magnitude, I don't think it makes sense for
> it to block migration of this new version to testing.

On second thoughts, I'm going to leave this as RC for now.  I made some
specific suggestions in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966575#102 that I
think could probably be implemented without taking too long, and if we
do that before this reaches testing then that would reduce the number of
people with unbootable systems.

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.bugs.dist

csiph-web