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

[Steven Clarkson]

[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.

[Steve Langasek (vorlon)]

At a glance, it appears to me that grub-efi-amd64-signed is missing a dependency on grub-efi-amd64 | grub-pc, which I believe was discussed as a requirement but seems not to have been fixed in the version that was SRUed.

[Łukasz Zemczak (sil2100)]

Yes, this dropped from my radar completely. The dependency chain change required us to make installer-related changes (in both grub-installer and ubiquity) that made sure the right packages aren't purged from the system. But what I did miss is adding the new deps to the grub2-signed package in case someone would be pulling in the new grub packages from the archive during installation.

So actually the bug here is that *old* images are failing to install on UEFI systems when automatic download of updates is switched on. This is why it was not noticed - I only tested the changes on both the dailies for bionic and cosmic.

[Launchpad Janitor (janitor)]

This bug was fixed in the package grub2-signed - 1.97

---------------
grub2-signed (1.97) cosmic; urgency=medium

  * debian/control: add a dependency of grub-efi-amd64 | grub-pc to
    grub-efi-amd64-signed to make sure the grub postinst is triggered even for
    cases of old iso (without the fixed installer) installations with
    automatic download of updates enabled (LP: #1780897).

 -- Łukasz 'sil2100' Zemczak <email address hidden> Tue, 10 Jul 2018 19:00:59 +0200

[Steve Langasek (vorlon)]

Hello Steven, or anyone else affected,

Accepted grub2-signed into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2-signed/1.93.2 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 and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. 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!

[Steven Clarkson (sclarkson)]

Worked for me.

System booted correctly after install. /etc/default/grub properly configured.

dpkg --list | grep grub

ii grub-common 2.02-2ubuntu8.1 amd64 GRand Unified Bootloader (common files)
ii grub-efi-amd64 2.02-2ubuntu8.1 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 version)
ii grub-efi-amd64-bin 2.02-2ubuntu8.1 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 binaries)
ii grub-efi-amd64-signed 1.93.2+2.02-2ubuntu8.1 amd64 GRand Unified Bootloader, version 2 (EFI-AMD64 version, signed)
ii grub2-common 2.02-2ubuntu8.1 amd64 GRand Unified Bootloader (common files for version 2)

[Launchpad Janitor (janitor)]

This bug was fixed in the package grub2-signed - 1.93.2

---------------
grub2-signed (1.93.2) bionic; urgency=medium

  * debian/control: add a dependency of grub-efi-amd64 | grub-pc to
    grub-efi-amd64-signed to make sure the grub postinst is triggered even for
    cases of old iso (without the fixed installer) installations with
    automatic download of updates enabled (LP: #1780897).

 -- Łukasz 'sil2100' Zemczak <email address hidden> Tue, 10 Jul 2018 20:36:23 +0200

[Steve Langasek (vorlon)]

The verification of the Stable Release Update for grub2-signed has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Łukasz Zemczak (sil2100)]

Sanity-tested the package that got published to -updates just now using the ubuntu-18.04-desktop-amd64.iso image and was able to get a bootable UEFI system afterwards. In comparison, with the previous grub-efi-amd64-signed package it was not working for me as well.

I will do a sanity-test with the daily image tomorrow.

[Łukasz Zemczak (sil2100)]

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.

[Jeremy (wa113y3s)]

How does anyone explain the recent bugs https://launchpad.net/ubuntu/+source/grub2-signed/+bugs?orderby=-id&start=0 if this is actually fixed?

[Steve Langasek (vorlon)]

On Wed, Jul 18, 2018 at 10:11:59PM -0000, Jeremy wrote:
> How does anyone explain the recent bugs
> https://launchpad.net/ubuntu/+source/grub2-signed/+bugs?orderby=-id&start=0
> if this is actually fixed?

There are a variety of other reasons that a package installation may fail
that have nothing to do with this bug.

[Jeremy (wa113y3s)]

Steve to tell you the truth, some of these bugs make me wonder if some people are switching to local repos that are out of date before they install. I just installed Ubuntu 18.04 using UEFI with updates enabled and it worked fine

[Launchpad Janitor (janitor)]

This bug was fixed in the package grub2-signed - 1.167~16.04.1

---------------
grub2-signed (1.167~16.04.1) xenial; urgency=medium

  * Use debhelper-compat 9 for ease of SRUs to Bionic and earlier. LP:
    #1920008

grub2-signed (1.167~16.04.0) xenial; urgency=medium

  * grub-efi-amd64-signed: add depends on grub2-common with support for
    R_X86_64_PLT32 relocations. LP: #1920008

 -- Dimitri John Ledkov <email address hidden> Tue, 23 Mar 2021 11:01:58 +0000