Support multiple ESPs

[Johan Ehnberg]

Subiquity has the brilliant feature of supporting installing to multiple ESP's. See https://bugs.launchpad.net/subiquity/+bug/1817066 for details.

grub-install does not mirror this feature this out of the box, but updates the ESP on /boot/efi only by default on such an installation. Whenever efi potentially changes, this leaves the backup ESP without the update.

Adding this support would be coherent, since an admin may logically assume the install mode is supported beyond the installation phase.

[Ryan Harper (raharper)]

What commands are you running and what do you expect to happen that does not?

If you've installed via subiquity then you can use:

/usr/lib/grub/grub-multi-install

which is what it used during the install to mount and mirror the primary esp to secondary devices.

[Johan Ehnberg (johan-ehnberg)]

I ran 'grub-install', and expected both efi to be updated. It updates only the primary ESP.

Both 'dpkg-reconfigure grub-efi-amd64' and running 'grub-multi-install' directly update both ESPs. So on the package updates part it looks like we are good to go.

The part that I am missing, is making it somehow the default out of the box action for admins when updating efi on such systems. Here are some approaches to illustrate:
- put grub-multi-install in the path at the very least,
- use dpkg's alternatives to point grub-install at grub-multi-install or
- wrap grub-install with a warning if multiple ESP's are present,
- put a note somewhere where admins will be looking when trying to figure it out, such as on /boot/efi if the specs allow it

[Julian Andres Klode (juliank)]

IMO you should be running dpkg-reconfigure grub-efi-amd64-signed rather than grub-install or the grub-multi-install wrapper directly.

grub-install cannot know if there are multiple ESPs, as the ESPs are stored in debconf.

This is not different from BIOS systems, where grub-install also does not do the right thing.

[Julian Andres Klode (juliank)]

It's still not clear to me why you ran grub-install in the first place, though. What made you do that?

If you change configuration, the right tool to run is update-grub, there is no need to reinstall grub.

If you change the ESPs, you use dpkg-reconfigure, so you would not have stumbled across that.

I can't really imagine a reason to run grub-install.

[Johan Ehnberg (johan-ehnberg)]

The situation where this arose is in testing our Ubuntu 20.04 orchestration. Previously we used a script to ensure boot coherence. We use two mirrored system drives, mirroring everything to the extent that the system must be completely bootable after pulling a drive/having one drive fail completely.

The situation where it becomes tempting to re-run grub-install, is when such a drive is replaced with an empty one. Our previous setup simply copies the ESP over, so when the partition exists and is mounted, it simply works.

I am perfectly happy with doing this using dpkg. However, I do not see how it would recognize the new partition identifiers? 'dpkg-reconfigure grub-efi-amd64' only seems to offer existing GRUB EFI system partitions. Maybe documenting the intended workflow would help us admins in such cases.

For some reason, the installer also records the drives differently (both are 850 EVO), but in essence, I am guessing simply getting the new drive's partition registered here should do the trick:
$ sudo debconf-show grub-efi-amd64 | grep devices:
* grub-efi/install_devices: /dev/disk/by-id/scsi-1ATA_Samsung_SSD_850_EVO_250GB_S2R6NXAH352264N-part1, /dev/disk/by-id/wwn-0x5002538d40c10167-part1

So the issue boils down to the same point I made above: making admins able to utilize this great feature. Do admins need to first manually install grub or copy over the contents on that new partition for it to be recognized in dpkg-reconfigure? Where is it documented or visible?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Julian Andres Klode (juliank)]

It needs to be a valid ESP. probably it's just a fat32 partition, but not a valid ESP - wrong partition type set in got/mbr if it's not shown.