>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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1864223 Title: shim 15+1552672080.a4a1fbe-0ubuntu1 fails to load fwupd To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1864223/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
