group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1930742@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package shim-signed - 1.33.1~16.04.10

---------------
shim-signed (1.33.1~16.04.10) xenial; urgency=medium

  * Update to shim 15.4-0ubuntu7:
    - Fix load option parsing, and thus fwupd execution (LP: #1929471) (PR #379)
    - Fix occasional crashes in _relocate() on arm64 (LP: #1928010) (PR #383)
    - Fix accidental deletion of RT variables (LP: #1934506) (PR #387)
    - mok: relax the maximum variable size check (LP: #1934780) (PR #369)

shim-signed (1.33.1~16.04.9) xenial; urgency=medium

  * Do not build a dual-signed shim (fixing regression from ~16.04.7), and
    disable verifying fbx64.efi and mmx64.efi certificates as xenial's
    sbverify is unable to (impish works fine)
  * Clean up debhelper log file accidentally imported into git during 16.04.7
    import.

shim-signed (1.33.1~16.04.8) xenial; urgency=medium

  * debian/*.postinst: Unconditionally call grub-install with
    --force-extra-removable, so that the \EFI\BOOT removable path as used in
    cloud images receives the updates.  LP: #1930742.
  * Update to shim 15.4-0ubuntu5:
    - Stop addending vendor dbx to MokListXRT during MokListX mirroring. This
      is causing systems to run out of EFI storage space, or just hang up
      when trying to write it (LP: #1924605) (LP: #1928434)
    - Further relax the check for variable mirroring on non-secureboot systems
      avoiding boot failures on out of space conditons (pull request #372)
    - Don't unhook ExitBootServices() when EBS protection is disabled
      (LP: #1931136) (pull request #378)

shim-signed (1.33.1~16.04.7) xenial; urgency=medium

  * New upstream release 15.4.  LP: #1921134
  * Update packaging to pull fb and mm from shim-signed package as in
    later releases, dropping the runtime dependency on shim.
  * Add download-signed script from linux-signed package
  * Add a versioned dependency on the mokutil that introduces --timeout, and
    call mokutil --timeout -1 so that users don't end up with broken systems
    by missing MokManager on reboot after install.  LP: #1856422.
  * Add versioned dependencies on grub-efi-amd64-signed and grub2-common,
    to ensure we have SBAT-compatible grub.efi and grub 2.04-compatible
    grub-install present when we are installing new shim to the ESP.
  * Include reworked Makefile from devel to better assert the integrity of
    the executables.

 -- Julian Andres Klode <juliank@xxxxxxxxxx>  Fri, 16 Jul 2021 13:04:57
+0200

** Changed in: shim-signed (Ubuntu Xenial)
       Status: Fix Committed => 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/1930742

Title:
  cloud images in xenial do not get their boot path updated because we
  don't call grub-install --force-extra-removable

Status in grub2-signed package in Ubuntu:
  Fix Released
Status in grub2-unsigned package in Ubuntu:
  Fix Released
Status in shim-signed package in Ubuntu:
  Invalid
Status in grub2-signed source package in Xenial:
  Fix Released
Status in grub2-unsigned source package in Xenial:
  Fix Released
Status in shim-signed source package in Xenial:
  Fix Released
Status in grub2-signed source package in Bionic:
  Fix Released
Status in grub2-unsigned source package in Bionic:
  Fix Released
Status in shim-signed source package in Bionic:
  Invalid

Bug description:
  [Impact]
  Verification of the previous SRU, bug #1928674, exposed that we have a regression on xenial/arm64 cloud images because they boot from the removable media path, which is not updated by the maintainer scripts in those images; and because we have never supported the monolithic signed EFI executable on xenial/arm64, there is an ABI mismatch between the updated contents of /boot/grub and the not-updated contents of \EFI\boot\bootaa64.efi.

  The fact that \EFI\boot is not updated on xenial cloud images is ALSO
  an issue on amd64 - it doesn't lead to a boot failure there because we
  do support secureboot on xenial/amd64, so the bootloader doesn't
  depend on loading modules from /boot/grub; however, \EFI\boot not
  being uploaded means that the systems still do not benefit from the
  updated grub, AND are subject to boot failures in the future due to
  the fact that the old shim has been revoked by Microsoft and these
  revocations may propagate to the cloud instance's revocation database
  in nvram, one way or another.

  [Test Case]
  - Boot an arm64 Ubuntu image in AWS
  - Enable -proposed
  - Upgrade the grub-efi-amd64 package
  - Reboot
  - Verify that the system comes up

  - Boot an amd64 Ubuntu image in GCE
  - rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
  - touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
  - Enabled -proposed
  - Upgrade the grub-efi-amd64-signed package
  - Reboot
  - Verify that the system comes up
  - rm /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
  - touch /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/grubx64.efi
  - Upgrade the shim-signed package
  - Reboot
  - Verify that the system comes up

  [Where problems could occur]
  Because there were no provisions in the cloud images at the time they were built for updates to \EFI\boot, the only practical way to fix this for existing images (which is where the upgrade bug is an issue) is by unconditionally installing to the removable media path on all systems as part of the upgrade.  This means that non-cloud systems, which do not normally boot Ubuntu via \EFI\boot, will have the contents of \EFI\boot replaced when this was not previously the case (and contrary to the debconf setting).  In newer Ubuntu releases, we install to \EFI\boot unconditionally; but this is a behavior change in a stable series.  If a user has something other than Ubuntu grub+shim installed to \EFI\boot, this may be an unexpected behavior change from an SRU.

  The risk of this causing a problem for users is mitigated on bionic by
  the fact that all the most recent install media for Ubuntu 18.04 also
  install shim+grub to the removable path, so this is already the
  default behavior.

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