package grub-efi-amd64-signed 1.140+2.04-1ubuntu24 failed to install/upgrade with mount: /var/lib/grub/esp: special device /, does not exist

What does debconf-get-selections | grep grub-efi say?

From bug#1872097

Ran sudo dpkg-reconfigure grub-efi-amd64-signed
response was confusing .. but I approved the install and everything appears to boot normally.

after installing debconf-utils ran command from comment#2 above.

sudo debconf-get-selections | grep grub-efi
grub-pc grub-efi/install_devices multiselect /dev/disk/by-id/ata-Samsung_SSD_860_EVO_1TB_S599NE0MB00487K-part2
grub-pc grub-efi/install_devices_empty boolean true
grub-pc grub-efi/install_devices_disks_changed multiselect /dev/disk/by-id/ata-Samsung_SSD_860_EVO_1TB_S599NE0MB00487K-part2
grub-pc grub-efi/install_devices_failed boolean false

Unfortunately if you have already run dpkg-reconfigure before running debconf-get-selections, the information about the previous debconf state has been lost and we may or may not be able to debug this further.

on a fresh install on a new partition of focal fossa (03/28) on upgrading during the first boot into the install came across the same error

did not "continue the install of grub-efi" so the disk was not altered

installed debconf-utils then ran debconf-get-selections | grep grub-efi

gave the following output:

grub-pc grub-efi/install_devices_empty boolean true
grub-pc grub-efi/install_devices_disks_changed multiselect
grub-pc grub-efi/install_devices_failed boolean false
grub-pc grub-efi/install_devices multiselect

Hope this helps.

going back to the previous partition (trying to make it the default again)
I ran the following:

 grub-install /dev/sda
Installing for x86_64-efi platform.
grub-install: warning: disk does not exist, so falling back to partition device /dev/sda2.
grub-install: warning: disk does not exist, so falling back to partition device /dev/sda2.
grub-install: warning: disk does not exist, so falling back to partition device /dev/sda2.

is this related or did I use the incorrect command?

opps dropped a line at the end:

grub-install: error: disk `hostdisk//dev/sda2' not found.

ok: grub-install --target=x86_64-efi /dev/sda
works properly... sorry for the noise

Why are you passing a device? grub does not care about that, it installs to /boot/efi.

I still don't understand what's going on here?

- Was your /boot/efi mounted when you upgraded grub?
- Did you get a prompt for install locations?

Did you just do a clean install and reboot, and upgrade during first boot - manual or unattended?

When I pass the device it shuts up..

OKAY .. my initial report was bug 1872097 my original and still existing install partition (sda5) for focal ( dec 2019) I used dpkg-reconfigure there and of course then debconf-get-selections did not give the correct info ..

So I created a new partition (sda6) on the drive using existing free space and manually installed focal there as a second instance using a recent (03/28) iso (xubuntu). This was a not connected to network install as my wireless net work driver is not on the install disk (rtl8821ce-dkms) (installed via a brief chroot prior to first boot)

also on the drive are windows 10 partitions at sda1,sda3,sda4 plus sda2 which is the /boot/efi (EFI) partition. (always mounted to /boot/efi so far as I know by default)

SDA6-order of events:

I booted into the fresh install (after network driver was installed). I did the first upgrade on sda6 using the software updater after running the language updater which appeared first.

During this install the grub-efi-amd64-signed setup threw up a window complaining the partition sda2 had changed or did not exist.. It had one check box for proceeding .. and a continue button .. then a second message appeared with some thing that looked like this:

 grub-efi /dev/sda2 device ?? parition ?? changed or does not exist

hovering over this gave a message about systems without a bios or in a vm being etc. grub not being needed also that I might not be able to boot if I did install

There were two buttons to continue or not-install(?).. I chose to not install .. so the /boot/efi entries remained the same as first installed.

Then I installed debconf-utils and then ran debconf-get-selections as directed in comment #2
output as in comment #5

Then I rebooted to partition sda5 and tried to reinstall it as the primary start-up Comments 6,7,8) trying to overwrite the /boot/efi (/dev/sda2 [EFI]) partition so my normal boot would be directly into the main xubuntu install on sda5.

output in comments #6 most of output) and #7 (with the omitted last line)

I then ran the commands in comment #8 .. checked the time stamps on the /boot/efi partition and they had changed ..

I hope this clarifies things.

so it is easy to reproduce this bug .. with and older fresh install of ubuntu (xubuntu) focal
just do it networkless on a computer with a windows 10 install

Multiple installations of Ubuntu (and Ubuntu-derived distributions) on the same device are not supported. I don't understand the rest you're writing, really.

The ?? are another issue that needs fixing, but it's cosmetic.

FWIW, device meaning PC, not disk.

I was try to reproduce the bug on the same computer .. by adding another install .. on another partition .. that worked .. bug was reproducible ..

having multiple real installs on a computer of different versions of linux (ubuntu spins, lts, development versions) allows testing in a real environment .. as opposed to a vm .. was a standard practise prior to vm's existing

I uploaded grub2 a few hours ago with fixed /boot/efi -> debconf migration logic, and fix for the ??? and /dev warnings. This should hopefully deal with this issue, though I'm not sure why people got errors as opposed to just the question.

@Derk You can't really have multiple Ubuntu installations working correctly bootloader wise, as they

(1) all install to EFI/ubuntu on the ESP(s)
(2) remove any other installations from the boot options and boot menu

So you're basically flip flopping the installation in /boot/efi between different Ubuntu installations (and, possibly other distros, in the removable path EFI/boot/bootx64.efi).

In any case, I don't believe your input is useful here. The debconf values for your new install are distracting - they don't tell us what went wrong, just that you chose not to install anything.

Hello Tom, or anyone else affected,

Accepted grub2 into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2/2.04-1ubuntu26 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

This bug was fixed in the package grub2 - 2.04-1ubuntu26

---------------
grub2 (2.04-1ubuntu26) focal; urgency=medium

  [ Julian Andres Klode ]
  * Move /boot/efi -> debconf migration into wrapper, so it runs everywhere
    (LP: #1872077)
  * Display disk name and size in the ESP selection dialog, instead of ???

  [ Sebastien Bacher ]
  * debian/patches/gettext,
    debian/patches/rules:
    - backport upstream patches to fix the list of translated strings,
      reported on the ubuntu-translators mailing list. The changes would
      be overwritten by autoreconf so applying from a rules override.

 -- Julian Andres Klode <email address hidden> Wed, 15 Apr 2020 13:31:27 +0200

I can confirm the fix. Re-installed OS via same build iso, selected proposed, and no warnings or unexpected windows popped up. Thanks for all the hard work.

I'm having this same issue with 1.142.9+2.04-1ubuntu26.7.

Setting up grub-efi-amd64-signed (1.142.9+2.04-1ubuntu26.7) ...
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
Installation finished. No error reported.
mount: /var/lib/grub/esp: mount point 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

The esp flag is set properly to the /boot/efi partition. Does this require a new bug report?

Nevermind, this solved my problem:

sudo apt-get purge grub\*
sudo apt-get install grub-efi
sudo apt-get autoremove
sudo update-grub