Fwupd fails for 'install on reboot', possible EFI error

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.

You forgot to post the exact error you got.

As far as I’m aware there isn’t one, that’s why I said it fails ‘silently’ in the first paragraph. If ‘fwupd’ should log such failures somewhere, please tell me where and I’ll try to get the info and add it to the thread.

I’ve just had a system update notification which includes ‘fwupd’, so I’ll install that and see if anything changes…

Use fwupdmgr from the terminal.
Start with fwupdmgr -h
fwupdmgr get-devices
fwupdmgr get-updates
fwupdmgr install

Hy, Dell user here. What I usually do is:

  • Download BIOS update .exe from here

https://www.dell.com/support/product-details/sv-se/product/vostro-15-3520-laptop/drivers

  • Put it on my DOS-USB-stick

  • Set BIOS to allow (legacy) boot from USB-stick

  • Run the .exe from command prompt in booted DOS from USB-stick

Works for me 100% yet, however, I’m not on the latest Dell hardware, as restrictions for legacy become more and more strict in Dell BIOS. Time to look for a new hardware vendor anyway… :wink:

The Dell Vostro download site has instructions for BIOS update without any OS at the bottom:

Updating the BIOS from BIOS Boot Menu (independent of operating system)
Note 1: Before updating the BIOS, ensure that you suspend BitLocker encryption on a BitLocker-enabled system. If BitLocker is not enabled on your system, you can ignore this step. For information about how to disable BitLocker, see How to Enable or Disable BitLocker with TPM in Windows at support.dell.com.
Note 2: Do not turn off the power or interrupt the BIOS update process during the update.
Note 3: Your system requires a restart after installing the BIOS. The restart can be deferred but must be completed to ensure that the update is installed.
Installation

  1. Copy the downloaded file to a USB drive. The USB drive does not need to be bootable device.
  2. Insert the USB drive into any USB port.
  3. Power on the system.
  4. At the DELL logo screen, press F12 to access the one-time boot menu.
  5. Select BIOS Flash Update in the Other Options section.
  6. Click the … button to browse the USB drive to locate the downloaded file.
  7. Select the file and click Ok.
  8. Verify the existing system BIOS information and the BIOS update information.
  9. Click Begin Flash Update.
  10. Review the Warning message and click Yes to proceed with the update.
    The system restarts and displays a progress bar at the Dell logo screen. The system restarts again when the update is complete.

Yeah, just consequent, as the BIOS is the native OS and any other “OS” you install is running on the next abstraction layer as a virtual machine on this OS. :smiley:

So why not including a native DOS boot option into the BIOS.

This is wrong. The BIOS (Basic Input/Output System) is not an OS (Operating System). There is extensive documentation available about the differences.

There is no need to use an (outdated) DOS (disk operating system) to update (UEFI)BIOS nowadays when the manufacturer provides update possibilities from within (UEFI)BIOS itself. UEFI updates can be done from within UEFI itself when it is correctly implemented by the hardware manufacturer.

And in the case from the mentioned Dell Vostro, it is possible to update the UEFI bios without any outdated (DOS) or actual (Windows, Linux) OS.

On my Intel Motherboards it’s even easier, pop the bin file on a vfat USB, plug in boot, hold a Fn key and done… or move the BIOS jumper, plug it in and it recovers the BIOS to the version on the USB device, if it accidentally gets bricked (which has happened)… For my HP Z Workstations a BIOS update rpm (and the src rpm) is provided, so can just update from Tumbleweed :wink:

It appears my problem wasn’t unique. The bug-report has resulted in an update to fwupd version 2.0.8 as of 2 days ago, so hopefully it’ll hit my system in the next few days - I’ll let any concerned parties know.

I’ve chosen not to launch a BIOS update from within the EFI menu itself at least partly because the ‘exe’ file from Dell is 127Mb while the capsule files from LVFS (provided by Dell) that ‘fwupd’ uses are 45Mb, and not knowing what causes the discrepancy means I don’t trust myself to go ahead with one over the other. I do recall that previous successful updates from Linux were noticeably quicker than ones from Windows, back in the day…

The update to fwupd-2.0.8 has solved my issue. ‘fwupdtool efiboot-info’ now correctly shows a ‘firmware update’ entry in the EFI boot-menu which points to ‘\EFI\opensuse\fwupdx64.efi’ whereas it previously pointed to the same ‘shim.efi’ as the default ‘openSUSE Linux’ entry. This in conjunction with a ‘bootnext’ instruction pointing to the required menu-item invokes the desired BIOS flash upon reboot.

Thanks for all the suggestions along the way - marking as ‘Solved’.