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).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871963
Title:
dpkg fails to install grub-efi-amd64 signed and shim-signed
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1871963/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
