[Bug 1814575] Re: Updates failing because "db is empty"

Mathieu Trudel-Lapierre mathieu.tl at gmail.com
Fri Feb 8 20:47:17 UTC 2019


Verification-done on cosmic with grub2/2.02+dfsg1-5ubuntu8.2,
grub2-signed/1.110.2:

Upgrading grub in the presence of an unsigned kernel (copied existing
vmlinuz and ran 'sbattach --remove') leads to a failing upgrade, as
expected. Despite 'mokutil --export --db' returning an error "db is
empty", if all kernels present are correctly signed the upgrade
completes without issues.

** Tags removed: verification-needed verification-needed-cosmic
** Tags added: verification-done-cosmic

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

Title:
  Updates failing because "db is empty"

Status in grub2 package in Ubuntu:
  Fix Released
Status in grub2-signed package in Ubuntu:
  Fix Released
Status in grub2 source package in Bionic:
  Fix Released
Status in grub2-signed source package in Bionic:
  Fix Released
Status in grub2 source package in Cosmic:
  Fix Committed

Bug description:
  [SRU Justification]
  There is a behavior regression on some EFI systems with specific firmwares (right now, Lenovo, X230 and newer are known to be affected), where mokutil --export --db returns "db is empty" and can lead to no .der certificates being exported at all. Further steps in grub-check-signatures would thus error out.

  [Test case]
  Run at least once on a Lenovo T450 (cyphermox).

  1. Install a system using UEFI mode.
  2. Reboot
  3. Fully upgrade system.
  4. Run 'sudo /usr/share/grub-check-signatures'; verify that it fails (openssl errors and "db is empty").
  5. Install grub* from -proposed.
  6. Verify that the upgrade completes successfully.

  [Regression potential]
  The test case is sufficient to verify all possible paths work correctly after the SRU, provided it is run on both non-affected systems and affected systems.

  Fix this:

  On some Thinkpads (up to now, no other manufacturers appear to show
  this), db can be reported to be empty even though it's not. It seems
  to be a firmware issue, but it's one we can work around.

  So, fix this type of failure:

  Setting up grub-efi-amd64-signed (1.112+2.02+dfsg1-5ubuntu10) ...
  db is empty
  Can't open *.der for reading, No such file or directory
  140033418155072:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:72:fopen('*.der','rb')
  140033418155072:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:79:
  unable to load certificate
  dpkg: error processing package grub-efi-amd64-signed (--configure):
   installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
  dpkg: dependency problems prevent processing triggers for shim-signed:
   shim-signed depends on grub-efi-amd64-signed | grub-efi-arm64-signed; however:
    Package grub-efi-amd64-signed is not configured yet.
    Package grub-efi-arm64-signed is not installed.

  dpkg: error processing package shim-signed (--configure):
   dependency problems - leaving triggers unprocessed
  Errors were encountered while processing:
   grub-efi-amd64-signed
   shim-signed
  E: Sub-process /usr/bin/dpkg returned an error code (1)

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



More information about the foundations-bugs mailing list