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 <x...@ubuntu.com> Tue, 23 Mar 2021 11:01:58 +0000 ** Changed in: grub2-signed (Ubuntu Xenial) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs 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 Xenial: 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 _______________________________________________ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp