Does anybody know precisely how ‘fwupd’ works, because I have an update failing to install on reboot, and it appears to me that the EFI boot menu entry for ‘Firmware Updates’ is IDENTICAL to the default ‘openSUSE Linux’ entry, so any firmware update I try just silently boots straight back to Linux without flashing the UEFI BIOS as desired.
If I run ‘efibootmgr’ without arguments, I see that both menu entries point to \EFI\opensuse\shim.efi, which I understand is a necessary file for SecureBoot systems, whereas I thought the Firmware option ought to point to the ‘fwupdx64.efi’ file in the same directory as the ‘shim’ one.
I’m fairly certain I’ve done at least one successful update in the past from ‘Discover’, since my Windows support expired and I stopped booting into it for updates, but this most recent one has been tried a couple of times without success.
The hardware is a Dell Vostro 3520, the BIOS update that’s failing is up to 1.30 from 1.29.
Is the EFI option correct, and the ‘shim.efi’ is supposed to redirect the process to the right place depending on additional arguments it receives from fwupd, or should the entry point to the other efi-file cited earlier? Who created the menu entry in the first place, and why would it’s behavior have changed, as those entries don’t appear to be editable?
There’s a fwupd config-option called ‘EnableGrubChainLoad’ that is described as forcing the use of ‘fwupdx64.efi’ instead of NVRAM or Capsule-On-Disk, but with something as potentially catastrophic a BIOS flash, I’d prefer not to make guesses.
I’ve scoured the web as best as I can and am still unsure how best to proceed. Most of the info I’ve found is related to ‘Arch’, which I believe disables SecureBoot as standard so as not to need authenticated access via the ‘shim.efi’ solution, but I may be doing them a disservice in saying that.
Apologies for the ramble. If I’ve omitted anything important, please feel free to ask.