[Bug 1780897] Re: Installation failure on UEFI systems using older images with automatic download of updates enabled

[Łukasz Zemczak]

I have just performed a sanity install of ubuntu-desktop daily bionic.
The install resulted in a bootable system - therefore I consider all
test cases performed successfully.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2-signed in Ubuntu.
https://bugs.launchpad.net/bugs/1780897

Title:
  Installation failure on UEFI systems using older images with automatic
  download of updates enabled

Status in grub2-signed package in Ubuntu:
  Fix Released
Status in grub2-signed source package in Bionic:
  Fix Released
Status in grub2-signed source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

  Recent grub2-signed dependency chain changes required some changes to
  be made to the installer parts to make sure the end system is
  bootable. However, older isos (like, release images for bionic) do not
  have these installer changes, so users using those with automatic
  download of updates enabled on UEFI systems will end up with a broken
  system.

  [Test Case]

  Checking if the bug has been fixed:

   * Download an older iso (for bionic, let it be the 18.04 release image)
   * Prepare an UEFI-based VM
   * Install Ubuntu with automatic download of updates enabled
   * Reboot and make sure the system is bootable

  Checking if no regressions have been introduced for the installer:

   * Download the latest daily server iso
   * Prepare an UEFI-based VM
   * Install Ubuntu
   * Reboot and make sure the system is bootable

  [Regression Potential]

  There should be no real regression potential here as we are basically
  adding dependencies that should otherwise be installed when using a
  newer image. All potential regressions would be made visible during
  the installation tests from the test case.

  [Original Description]

  Regression caused by
  https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1778848

  Steps to reproduce

  1) Install ubuntu-18.04-desktop-amd64.iso in a VM using QEMU and OVMF
  2) Reboot the VM
  3) See GRUB shell instead of GDM

  The system can be rescued by running

  configfile (hd0,gpt2)/boot/grub/grub.cfg

  at the GRUB shell

  Installing grub-efi-amd64 in the rescued system then makes it
  bootable.

  Previously grub-efi-amd64-signed depended on grub-efi-amd64, and the
  system was bootable immediately after installation.

  Additionally, the removal of this dependency has resulted in a very
  sparse /etc/default/grub after installation.

  I've attached a simple script for installation with QEMU and OVMF.

  I suspect that installs are broken on actual hardware with SecureBoot
  disabled, but I'm not able to test that right now.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1780897/+subscriptions