© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
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:/
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).