#1021301 grub-pc: use persistent disk identifier stored in configuration file

Package:
grub-pc
Source:
grub-pc
Description:
GRand Unified Bootloader, version 2 (PC/BIOS version)
Submitter:
Ansgar
Date:
2023-10-20 07:30:02 UTC
Severity:
normal
#1021301#5
Date:
2022-10-05 07:48:39 UTC
From:
To:
Hi,

the upgrade to grub-pc 2.06-3~deb11u2 fails:

+---
| Setting up grub-pc (2.06-3~deb11u2) ...
| Installing for i386-pc platform.
| grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
| grub-install: error: embedding is not possible, but this is required for cross-disk install.
| You must correct your GRUB install devices before proceeding:
|
|   DEBIAN_FRONTEND=dialog dpkg --configure grub-pc
|   dpkg --configure -a
| dpkg: error processing package grub-pc (--configure):
|  installed grub-pc package post-installation script subprocess returned error exit status 1
| Errors were encountered while processing:
|  grub-pc
| Log ended: 2022-09-23  06:09:42
+---

The previous version installed successfully and the system was booting
without problems so far:

+---
| Setting up grub-pc (2.06-3~deb11u1) ...
| Installing for i386-pc platform.
| Installation finished. No error reported.
| Generating grub configuration file ...
| Found linux image: /boot/vmlinuz-5.10.0-17-amd64
| Found initrd image: /boot/initrd.img-5.10.0-17-amd64
| Found linux image: /boot/vmlinuz-5.10.0-16-amd64
| Found initrd image: /boot/initrd.img-5.10.0-16-amd64
| Warning: os-prober will be executed to detect other bootable partitions.
| Its output will be used to detect bootable binaries on them and create new boot entries.
| done
| Log ended: 2022-09-12  06:51:32
+---

/dev/sda uses GPT and has one partition /dev/sda1; it was created this
way by d-i (though it has the setting to use gpt enabled).

Ansgar

#1021301#10
Date:
2022-10-05 08:27:29 UTC
From:
To:
[...]
boot device is currently /dev/sdb. That still has a DOS disk label; the
systems using GPT for the boot device as well have a small 1M partition
for BIOS boot.

So grub-install shouldn't try to install to /dev/sda, but I find
nothing in /etc referencing /dev/sda at all (except for a comment in
/etc/fstab). So I'm not sure why the system tries to install grub
there.

I now also checked /var/log/installer/syslog and when installing the
system /dev/sda and /dev/sdb were the other way around. And it looks
like that was the case before the previous reboot as well.

So possibly one of the race conditions I read about? (FWIW, this is a
VM running under VMware.)

Ansgar

#1021301#17
Date:
2022-10-05 16:58:49 UTC
From:
To:
[ Cc'ed -release@ to notify them it's not a regression after all ]

- Currently the only place where the configuration where grub should be
installed is debconf, in particular grub-pc/install_devices.
This should be moved to a configuration file in /etc.

- grub should use a persistent device identifier instead of /dev/sda
and similar. Steve McIntyre said on #-devel:

| so we go to all the effort finding out the device details in a 
| sustainable way, then don't store it :facepalm:
| we should be using a persistent device identifier here
| and each time we run grub-install that should be re-resolved to a 
| /dev/*** reference
| for added cleverness, we should also warn users that disks have moved
| if we no longer find the disk(s) we expect to install ointo
| and prompt for an update
| so we pick up on disk replacement, etc.

I think one has to check that grub doesn't get confused as well: in my
case the device can be /dev/sda or /dev/sdb for Linux, but it should
always be (hd0) for grub.

Implementing this probably also requires changes to the grub-installer
package.

Ansgar

#1021301#26
Date:
2023-10-20 07:23:22 UTC
From:
To:
Hi

I've mentioned the same behavior in bug #1020777 in the past, and I can now confirm that the Debian 12 grub version still shows this same issue.

When we do an automated upgrade from grub 2.06-13 to grub 2.06-13+deb12u1, the install will error out when the /dev/sdX order has switched between initial install and current situation after a reboot.

Does anyone know whether this is something that's being worked on? As it really breaks our ability to easily patch our systems in an automated manner.

Kind regards,
Jeremy