← Back to team overview

kernel-packages team mailing list archive

[Bug 1528345] Re: grub or kernel update broke Secure Boot by putting grubx64.efi instead of shimx64.efi in EFI boot order

 

Will users that have only the -security pocket enabled run into this
issue until we publish a corresponding grub2-signed package into the
-security pocket? Can the packages in -updates in wily, vivid, and
trusty be binarycopied into the -security pocket?

What steps need to be taken to publish future grub2 security updates?

Thanks

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1528345

Title:
  grub or kernel update broke Secure Boot by putting grubx64.efi instead
  of shimx64.efi in EFI boot order

Status in One Hundred Papercuts:
  Confirmed
Status in grub2 package in Ubuntu:
  Triaged
Status in linux package in Ubuntu:
  Invalid

Bug description:
  I've been running Ubuntu on a Lenovo ThinkPad X240.  I initially
  installed 14.10 when I got the machine in January.  I then upgraded to
  15.04, and on Monday evening (late December 14) I upgraded to 15.10.
  I rebooted once right after the update to make sure some postfix and
  opendkim configuration changes I made worked correctly after
  rebooting.

  Then between Monday evening and Friday evening (December 19) there
  were a bunch of system updates that I installed.  On Friday evening I
  decided to reboot to boot into the updated kernel.  (There were also
  grub updates in that interval.)

  When I rebooted, the laptop said:

  Secure Boot
  Image failed to verify with *ACCESS DENIED*
  Press any key to continue.

  See the image (posted by somebody else) of this error in
  http://askubuntu.com/questions/710146/how-to-fix-secure-boot-error-
  image-failed-to-verify-with-access-denied-on-st

  I had to disable secure boot to make the system boot.

  
  Based on the discussion in http://askubuntu.com/questions/710146/how-to-fix-secure-boot-error-image-failed-to-verify-with-access-denied-on-st it appears that the problem is that the updates caused it to try to boot directly to grub (File(\EFI‌​\ubuntu\grubx64.efi)) rather than via the shim (File(\EFI‌​\ubuntu\shimx64.efi)).  I don't know for sure what sequence of events caused that, nor did I verify for certain that it was booting via the shim before.  However, I know that this reboot on Friday was the first time I had a secure boot failure since installing Ubuntu on the laptop (and using only Ubuntu; no other OSes involved) in January.

  I'll attach a list of the system updates that were applied in the
  interval between the successful boot and the failed one from
  /var/log/dpkg.log .  Note that the log is in UTC but my description
  above ("evening", etc., is in UTC-8, so the evening of December 14 is
  actually around 07:00 UTC on December 15).  Note that this log
  contains a grub update, two kernel updates, and the removal of the
  first of those kernel updates via apt-get autoremove.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.10
  Package: grub-common 2.02~beta2-29ubuntu0.2
  ProcVersionSignature: Ubuntu 4.2.0-22.27-generic 4.2.6
  Uname: Linux 4.2.0-22-generic x86_64
  ApportVersion: 2.19.1-0ubuntu5
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Mon Dec 21 15:39:21 2015
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-01-25 (330 days ago)
  InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1)
  SourcePackage: grub2
  UpgradeStatus: Upgraded to wily on 2015-12-15 (6 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/hundredpapercuts/+bug/1528345/+subscriptions


Follow ups