package grub-efi-amd64-signed 1.187.6+2.06-2ubuntu14.4 failed to install/upgrade: installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 32

[Gopinath Menon]

two ssd.
Ubuntu 22.04.3 LTSinstaller from ubuntu site
processor: Intel® Core™ i5 CPU 650 @ 3.20GHz × 4

ProblemType: Package
DistroRelease: Ubuntu 22.04
Package: grub-efi-amd64-signed 1.187.6+2.06-2ubuntu14.4
ProcVersionSignature: Ubuntu 6.2.0-33.33~22.04.1-generic 6.2.16
Uname: Linux 6.2.0-33-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
AptOrdering:
 grub-efi-amd64-signed:amd64: Install
 grub-efi-amd64-bin:amd64: Install
 NULL: ConfigurePending
Architecture: amd64
CasperMD5CheckResult: pass
Date: Wed Oct 4 08:53:08 2023
DuplicateSignature:
 package:grub-efi-amd64-signed:1.187.6+2.06-2ubuntu14.4
 Setting up grub-efi-amd64-signed (1.187.6+2.06-2ubuntu14.4) ...
 mount: /var/lib/grub/esp: bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program.
 dpkg: error processing package grub-efi-amd64-signed (--configure):
  installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 32
ErrorMessage: installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 32
InstallationDate: Installed on 2023-10-03 (0 days ago)
InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2)
Python3Details: /usr/bin/python3.10, Python 3.10.12, python3-minimal, 3.10.6-1~22.04
PythonDetails: N/A
RebootRequiredPkgs: Error: path contained symlinks.
RelatedPackageVersions:
 dpkg 1.21.1ubuntu2.2
 apt 2.4.10
SourcePackage: grub2-signed
Title: package grub-efi-amd64-signed 1.187.6+2.06-2ubuntu14.4 failed to install/upgrade: installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 32
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

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

[Julian Andres Klode (juliank)]

It seems you have configured additional ESPs for grub but they are not mountable.

Please include the output of

    sudo debconf-get-selections | grep grub-efi/install_devices
    sudo ls -lh /dev/disk/by-id
    sudo lsblk -P -O

To solve the issue on your system, run

    sudo dpkg-reconfigure shim-signed

and only select the partition mounted to /boot/efi.

[Karl Katzke (katzke)]

Julian, the problem is that on a working 22.04 system with only one boot partition, installing this version of shim-signed and grub-efi-amd64-signed causes an apt failure because even on a system with only one partition you have to manually reconfigure shim-signed. This is because there's no default selection made, even on a system with only one grub boot partition!

But, as requested --

sudo debconf-get-selections | grep grub-efi/install_devices
grub-common grub-efi/install_devices multiselect
grub-pc grub-efi/install_devices multiselect
grub-common grub-efi/install_devices_disks_changed multiselect
grub-pc grub-efi/install_devices_disks_changed multiselect
grub-common grub-efi/install_devices_empty boolean false
grub-pc grub-efi/install_devices_empty boolean false
grub-common grub-efi/install_devices_failed boolean false
grub-pc grub-efi/install_devices_failed boolean false

sudo ls -lh /dev/disk/by-id
total 0
lrwxrwxrwx 1 root root 10 Oct 4 12:28 dm-name-encrypted0 -> ../../dm-1
lrwxrwxrwx 1 root root 10 Oct 4 12:28 dm-name-ephemeral0-encrypted0 -> ../../dm-0
lrwxrwxrwx 1 root root 10 Oct 4 12:28 dm-name-ephemeral0encrypted-data0 -> ../../dm-2
lrwxrwxrwx 1 root root 10 Oct 4 12:28 dm-uuid-CRYPT-LUKS2-1cc4b405a9fc4c9c9c9fb18c002344c0-encrypted0 -> ../../dm-1
lrwxrwxrwx 1 root root 10 Oct 4 12:28 dm-uuid-LVM-eyZdm3i8bIFdDdkHTiMWBx3QV8W0mFvNKkYrNePL9ke7HmtpSyLkoEbUkkF8gSPy -> ../../dm-0
lrwxrwxrwx 1 root root 10 Oct 4 12:28 dm-uuid-LVM-k4UMnUZdbzRLJdEDUNjfMgtqmlh3d17ssvbwc8veu6b8wez3mg2tve6uvMiYo9ay -> ../../dm-2
lrwxrwxrwx 1 root root 10 Oct 4 12:28 lvm-pv-uuid-EAqIIC-lJH1-kVHG-Op99-f5rj-2Xnb-zqySKY -> ../../dm-1
lrwxrwxrwx 1 root root 13 Oct 4 12:28 lvm-pv-uuid-Pf5udp-B8Tu-sKRC-WIL6-KdRM-f88z-jEsloi -> ../../nvme1n1
lrwxrwxrwx 1 root root 13 Oct 4 12:28 nvme-Amazon_EC2_NVMe_Instance_Storage_AWS237E19714A9DF8906 -> ../../nvme1n1
lrwxrwxrwx 1 root root 13 Oct 4 12:28 nvme-Amazon_EC2_NVMe_Instance_Storage_AWS237E19714A9DF8906_1 -> ../../nvme1n1
lrwxrwxrwx 1 root root 13 Oct 4 12:27 nvme-Amazon_Elastic_Block_Store_vol0e9e52ee43cfdeab4 -> ../../nvme0n1
lrwxrwxrwx 1 root root 15 Oct 4 12:27 nvme-Amazon_Elastic_Block_Store_vol0e9e52ee43cfdeab4-part1 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 16 Oct 4 12:27 nvme-Amazon_Elastic_Block_Store_vol0e9e52ee43cfdeab4-part14 -> ../../nvme0n1p14
lrwxrwxrwx 1 root root 16 Oct 4 12:27 nvme-Amazon_Elastic_Block_Store_vol0e9e52ee43cfdeab4-part15 -> ../../nvme0n1p15
lrwxrwxrwx 1 root root 13 Oct 4 12:27 nvme-Amazon_Elastic_Block_Store_vol0e9e52ee43cfdeab4_1 -> ../../nvme0n1
lrwxrwxrwx 1 root root 15 Oct 4 12:27 nvme-Amazon_Elastic_Block_Store_vol0e9e52ee43cfdeab4_1-part1 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 16 Oct 4 12:27 nvme-Amazon_Elastic_Block_Store_vol0e9e52ee43cfdeab4_1-part14 -> ../../nvme0n1p14
lrwxrwxrwx 1 root root 16 Oct 4 12:27 nvme-Amazon_Elastic_Block_Store_vol0e9e52ee43cfdeab4_1-part15 -> ../../nvme0n1p15
lrwxrwxrwx 1 root root 13 Oct 4 12:28 nvme-nvme.1d0f-4157533233374531393731344139444638393036-416d617a6f6e20454332204e564d6520496e7374616e63652053746f72616765-00000001 -> ../../nvme1n1
lrwxrwxrwx 1 root root 13 Oct 4 12:27 nvme-nvme.1d0f-766f6c306539653532656534336366646...

[Koen Roggemans (koen-roggemans)]

Thank you for the provided info in this ticket!

We have 600+ student laptops with this problem (battery drains in a matter of hours because of this)

At the moment we fix them using following set of commands

sudo killall dpkg grub-multi-inst
sudo dpkg-reconfigure shim-signed
sudo update-grub

We control them using Saltstack and searching for a fix for all at once - probably something with debconf-set-selections

[Matthew Giassa (mgiassa)]

Dupe: https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/2038526

I tried out variations of @Koen's fix above, but in my case, automated/unattended jobs (e.g. Hcp Packer builds of AMIs, QCOWS, etc.) just die with the same errors in the posts above.

I recall a similar issue w/ "shim-signed" happening every few months and "debconf-set-selections" could be used as a temporary stopgap hack, but in this case, the usual workarounds don't seem to work.

For now I can just manually create baseline AMIs/QCOWs/etc.; run "apt dist-upgrade", and tweak my build jobs to inherit these new baseline images instead of the upstream Canonical images, but it's a less-than-desirable workaround.

[Koen Roggemans (koen-roggemans)]

Don't get me wrong - we couldn't get it working automated. I distributed the above as a script and instruct the users via email how to run it. Now just hoping they do...

[Julian Andres Klode (juliank)]

@Karl Your comment #4 is misleading. I asked the submitter for more information on their bug. In your case, you do not have any /boot/efi mounted so it's quite obviously going to have to ask you as there is no /boot/efi to migrate into the deconf setting.

I can't speak to the other users but it's entirely possible everyone here has different bugs, or just misconfigured systems - like removing /boot/efi from fstab or not automounting it.

[Koen Roggemans (koen-roggemans)]

Thank you for this clarification, Julian.

For your info: here is fstab of one of my problem devices:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/nvme0n1p2 during installation
UUID=f02fe823-8605-48f6-823f-c20a5133ae8d / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=4480-184B /boot/efi vfat umask=0077 0 1
/swapfile none swap sw 0 0

mount and grep for "boot" gives me
root@8RZ1PL3:~# mount | grep "boot"
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

So /efi/boot is there and mounted

Background info: the devices were installed with a "minimal" installation, created an OEM, captured and distributed using fog. They only contain one disk. I don't change any disk / boot settings I'm aware of.

I would be very happy to check any other possible problems to find the root of this problem and avoid it happening in the future.

[Koen Roggemans (koen-roggemans)]

I updated a device through the graphical interface (they all do automatic cli upgrades, which fail).

I got a screen, showing the help pop up:

"The GRUB boot loader was previously installed to a disk that is no longer present, or whose unique identifier has changed for some reason. It is important to make sure that the installed GRUB core image stays in sync with GRUB modules and grub.cfg. Please check again to make sure that GRUB is written to the appropriate boot devices."

And then only /dev/nvme0n1p1 to choose from to install grub.

Am I correct that the system expects to find grub on another location, can't find it, and then suggests the only possible location?

Probably something changed in the process of imaging. Is there a way to make this more robust?

[Launchpad Janitor (janitor)]

[Expired for grub2-signed (Ubuntu) because there has been no activity for 60 days.]