[Bug 1747889] Re: System not booting after update

[Steve Langasek]

> I suspect this has something to do with the update to shim-signed
1.33.1~17.10.1

We know that some Acer systems have non-compliant UEFI firmware
implementations, and do not honor boot options configured via efibootmgr
from the OS.  It sounds like this is the case for your system, and that
as a result, your system is being booted via \EFI\BOOT\BOOTX64.EFI,
which is indeed part of shim; and that this triggers fbx64.efi, the
"fallback" behavior, to try to recover the contents of the Boot*
variables based on the provided information in \EFI\*\BOOTX64.CSV (in
this case, probably only \EFI\ubuntu\BOOTX64.CSV).

But because the Acer firmware is broken, after fbx64.efi "successfully"
repopulates the Boot* variables and reboots, the firmware again boots to
fallback instead of to the correct boot entry.

I don't think there is anything we can do to detect or fix this in
Ubuntu.  The primary bug here is that the Acer system is booting
\EFI\BOOT\BOOTX64.EFI which it should never do (and which Ubuntu did not
configure it to do).  I think your change to boot "EFI File Boot 0" is
(despite the poor boot option naming) the correct fix for your system.

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

Title:
  System not booting after update

Status in shim-signed package in Ubuntu:
  Confirmed

Bug description:
  After installing the latest updates for Ubuntu 17.10, my computer
  (Acer Aspire V3-372) was no longer able to boot. It got stuck in a
  loop, displaying the following error message for a few milliseconds,
  then restarting again:

  System BootOrder not found. Initializing defaults.
  Creating boot entry "BootXXXX" with label "ubuntu" for file "\EFI\ubuntu\shimx64.efi"

  I suspect this has something to do with the update to shim-signed
  1.33.1~17.10.1 as "Failure to boot or validate validly signed EFI
  binaries" is listed as a potential regression on
  https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1708245/+editstatus

  There was also a very similar bug reported for Fedora 27:
  https://bugzilla.redhat.com/show_bug.cgi?id=1512410

  Selecting any (new) UEFI files as trusted did not solve the issue,
  neither did disabling secure boot or resetting the secure boot option
  in BIOS to factory default and it's still not working after adding
  EFI/ubuntu/shimx64.efi to trusted files again.

  The workaround I've found for now, is selecting "EFI File Boot 0"
  (which is the previously added trusted file) as primary boot device.
  But that's just a workaround, I think I should be able to just boot
  from my SSD as before.

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