> leading to different code paths being taken on non-secureboot systems, and fwupd being broken if you intercept the reboot and turn on secure boot.
This is intentional behavior based upon: 1. If there are shim bugs with chainloading firmware updates are TOTALLY broken if you always rely upon shim for the upgrade path. With the way things are done right now, users can turn off secure boot, re-run the update and it works. (Cough https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1929471) 2. Other than during development, it's unlikely that users will be turning on/off secure boot in the middle of a firmware update. To me this seems like a bullet point in a wiki page on how to test new shim releases properly with fwupd is what's needed. For GRUB support, please open https://github.com/fwupd/fwupd/discussions for discussing the merits and risks of it. ** Changed in: fwupd (Ubuntu) Status: New => Opinion -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1931213 Title: fwupd installs without shim if secure boot is disabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1931213/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
