users shoot themselves in the foot by removing /boot/efi from /etc/fstab; u-r-u should warn and refuse to let them upgrade

From the POV of "u-r-u shouldn't be a dumping ground for quirking upgrade issues we can fix in packages", shouldn't this check be in preinsts for the packages that twiddle /boot/efi, not in the upgrader?

Also, can we do better here (like we do with non-mounted bootloader partitions, like PReP) and somehow automatically detect the correct partition and mount it before attempting to use it?

On Wed, Jun 07, 2017 at 06:08:25PM -0000, Adam Conrad wrote:
> >From the POV of "u-r-u shouldn't be a dumping ground for quirking
> upgrade issues we can fix in packages", shouldn't this check be in
> preinsts for the packages that twiddle /boot/efi, not in the upgrader?

No, because the preinst is also run in the middle of the upgrade and causes
the upgrade overall to fail.

> Also, can we do better here (like we do with non-mounted bootloader
> partitions, like PReP) and somehow automatically detect the correct
> partition and mount it before attempting to use it?

If you detect multiple ESPs, how do you decide which one to mount?

(It's possible that yes, we could work this out based on things like current
efibootmgr settings, but I think it would be somewhat error prone and you
would still want to detect it all before starting the dist-upgrade.)

blkid -t PARTUUID=$(efibootmgr -v | awk '/^Boot..... ubuntu\t/ { print $NF }' | cut -f3 -d,)

Patch, needs review (especially of the new strings), and some testing - I only checked the function externally.

For completeness we should also check that the filesystem mounted at /boot/efi is of type vfat.

+ _("The UEFI Boot partition of your system "
+ "is not mounted on /boot/efi. "
+ "Please ensure that it is properly configured "
+ "and retry."))

Suggested wording:

Your EFI System Partition (ESP) is not mounted at /boot/efi. Please ensure that it is properly configured and try again.

+ else:
+ self._view.error(_("UEFI Boot partition not usable"),
+ _("The UEFI Boot partition of your system "
+ "(/boot/efi) is not writable. "
+ "Please ensure that it is properly configured "
+ "and retry."))

The EFI System Partition (ESP) mounted at /boot/efi is not writable. Please mount this partition read-write and try again.

Checking for vfat seems fragile. You could, like systemd does upstream, also mount it as an autofs with a short timeout.

But yeah, the texts are better than mine. Though I do fear that people do not know what an EFI system partition is.

This bug was fixed in the package ubuntu-release-upgrader - 1:18.04.6

---------------
ubuntu-release-upgrader (1:18.04.6) bionic; urgency=medium

  * DistUpgradeFetcherKDE.py:
    - ensure theming is correct across all Qt versions and Plasma versions
    - drop unused openUrl helper (replaced by QUrlOpener)
  * QUrlOpener.py:
    - make sure to pass --set-home to sudo when dropping back to user, prevents
      browsers from getting confused which HOME to use
  * DistUpgradeViewKDE.py:
    - force KDE theming for Qt5
    - fix icon & pixmap lookup by running them throw a compatibility helper
      using either Qt3/4 static lookup or Qt5 theme-based lookup (theme is
      determined by the QPA ideally)
    - let name mangling use os-release' PRETTY_NAME if present
    - do not resize windows, adjustsize() them (same as resize albeit readable)
    - introduce an override for QWidget.adjustSize() which prevents adjustment
      iff the window is maximized. as noted in the documentation adjusting a
      maximized yields unexpected results due to a control mismatch between
      X11 window managers and Qt (in short: Qt cannot unmaximize, so adjustsize
      does nothing useful in this case and in fact causes only part of the
      window to be marked dirty by Qt causing sever rendering artifacts)

 -- Harald Sitter <email address hidden> Fri, 19 Jan 2018 13:34:32 +0100

The changelog entry is the wrong one but it's fixed. String improvements are queued in bzr but some tests fail and need fixing :(