[Bug 1864223] Re: shim 15+1552672080.a4a1fbe-0ubuntu1 fails to load fwupd

[Mario Limonciello]

>From your circumstances I don't believe there is any evidence to support
that shim attempted to load fwupd, nor evidence that boot entry was even
used.

The only way to prove this would be to look at what "BootCurrent" was
set to after a "failed" attempt.  If it's set to Boot0001 then your
firmware did not respect BootNext or at least felt that the Boot0000 was
not a valid entry.

If it's set to Boot0002 or Boot0000 then that means that shim loaded,
but didn't load the correct binary.

The reason that I think upstream fwupd should look at this is because the behavior here did change slightly in fwupd 1.3.8.  Previously the entries were deleted after flashing firmware, but now in 1.3.9 they're supposed to be re-used.
You can see this commit that removed the behavior of deleted entries:
https://github.com/fwupd/fwupd/commit/60373e03fd0668d379ba0d7b90a6f02ba7d87478#diff-2f5c39c775e4cac7ebbeabed4cefca6a

So I have a hypothesis that your Boot0002 entry was not selected sounds
by a combination of both a firmware bug (handling duplicate entries) and
a fwupd bug (not viewing it as a valid entry since Boot0000 was empty).

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

Title:
  shim  15+1552672080.a4a1fbe-0ubuntu1 fails to load fwupd

Status in OEM Priority Project:
  New
Status in shim package in Ubuntu:
  In Progress

Bug description:
  The latest shim upload does not seem able to load fwupd. Selecting
  fwupd in BIOS boot menu seems to go directly to grub.

  Probably not a signing issue of fwupd, as we don't get a security
  violation error. Need to investigate more.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1864223/+subscriptions