Comment 22 for bug 1871963

We're seeing this one too, on Ubuntu 20.04. I think something interesting to note is the disk layout which might be causing it to happen.

During apt upgrade or forced grub package installation, I get:

    mount: /var/lib/grub/esp: special device /dev/sda1 does not exist.
    dpkg: error processing package grub-efi-amd64-signed (--configure):
     installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 32

It seems like the install script is looking for /dev/sda1 to install GRUB updates to.

When checking /etc/fstab, I can see a line which states:

    # /boot/efi was on /dev/sda1 during curtin installation

It's a VMware VM which was installed to a single emulated SCSI root VMDK, which will have been /dev/sda during installation. But /dev/sda1 no longer exists because new disks have been added to this system since then.

It seems like when assigning letters (as per the /dev/sd* schema), the SAS disks get assigned letters first, followed by the SCSI boot drive, which ends up being /dev/sdq (meaning the partition GRUB originally installed to is now all the way down at /dev/sdq1).

The disk that ends up being allocated to /dev/sda is one of many in a RAID array, and these are encrypted using LUKS across the entire disk (no partition). So there is no /dev/sda1 at all anymore as far as the GRUB installer is concerned.

Is there any way I can force GRUB to find the correct /boot/efi location? (Running lsblk confirms it is definitely at /dev/sdq1 now).