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? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1876974 Title: Support multiple ESPs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1876974/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
