Can I trust "fwupdmgr"? I wish to have latest UEFI Firmware

Hi

Is there really no more recent Firmware update? I installed the 23.09.2024 build.

Can I trust “fwupdmgr”? I wish to have latest UEFI Firmware


# fwupdmgr refresh --force
Updating lvfs
Downloading…             [************************************** ]
Successfully downloaded new metadata: Updates have been published for 3 of 15 local devices
Successfully uploaded report

# fwupdmgr get-updates
Devices with no available firmware updates: 
 • KEK CA
 • KEK CA
 • SBAT
 • System Firmware
 • ThinkPad Product CA
 • UEFI CA
 • UEFI Device Firmware
 • UEFI Device Firmware
 • UEFI Device Firmware
 • UEFI Device Firmware
 • UEFI Device Firmware
 • Windows UEFI CA
Devices with the latest available firmware version:
 • KBG6AZNT512G LA KIOXIA
 • UEFI CA
 • UEFI dbx
No updates available

Thank you

Check the Lenovo support page for your device and see if it has newer firmware. But I doubt there is if it’s not in the LVFS. Lenovo are pretty good with firmware support in the LVFS (I’m also on a Thinkpad).

2 Likes

I think it is the vendor who decides what updates appear in the Linux Vendor Firmware Service. There may be updates that target issues with Windows so are not a priority for linux, or that require newer kernel.

1 Like

There is more recent firmware, even “critical”:

https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-edge-laptops/thinkpad-e14-gen-6-type-21m3-21m4/21m3/21m30031mz/pf5fccw4/downloads/driver-list/component?name=BIOS%2FUEFI&id=5AC6A815-321D-440E-8833-B07A93E0428C

For a critical update (and nothing in the LVFS), I would do a manual install of the BIOS myself. I previously used this method on my older Thinkpads. But it’s been a while since I’ve used it due to the LVFS keeping up-to-date with my T series quite well. Checking that manual method, the only bump is the lack of geteltorito in the Fedora repos. And the links on the article don’t work. But I did download the raw file from it’s new home at Github and successfully converted the *.iso to *.img.

The steps I followed…

sudo dnf install genisoimage, download the geteltorito script from here and save it as or move it to geteltorito. Copy it to /usr/local/bin with sudo cp -v geteltorito /usr/local/bin/ and then adjust the permissions on it with sudo chmod +x -v /usr/local/bin/geteltorito and once that is done convert the update *.iso to *.img for burning to USB with geteltorito -o [image_name].img [update_name].iso.

Replace [image_name] with whatever you want to call the image file. The [update_name] will be r2kur34w.iso if you’ve downloaded the latest BIOS Update (bootable CD).

Then you reboot, boot from USB and follow the instructions.

I just checked my own Thinkpad and see they have issued a BIOS update for my own machine last month (though it’s only recommended, not critical) so I’ll be doing my own update with the above process. You can wait until I’ve done it and I’ll post back here. If nothing has exploded it shouldn’t take long.

Edit: Success. The old method still works. One word of warning. Follow the instructions to the letter and don’t rush it. It might appear at times that something has frozen or stuck. It hasn’t.

2 Likes

Thanks. I use Fedora Silverblue.

find .
.
./System Volume Information
./System Volume Information/WPSettings.dat
./System Volume Information/IndexerVolumeGuid
./FLASH
./FLASH/ShellFlash.efi
./FLASH/R2KET34W
./FLASH/R2KET34W/$0AR2K00.FL1
./EFI
./EFI/Boot
./EFI/Boot/Bootx64.efi

I wrote the *.img to stick, but can’t boot from it :frowning:

What you’re running shouldn’t matter, aside from installing the likes of genisoimage which you’ll layer with rpm-ostree specific commands, rather than dnf install commands on a regular Fedora system.

The following is what I did…

In the terminal, change to the ~/Downloads directory because this is where I’m doing everything.
cd ~/Downloads

After downloading the geteltorio script to ~/Downloads I renamed it by using mv. You can also do it in the GUI by right clicking and renaming. But since I’m already in a terminal…
mv geteltorito.pl geteltorito

I then moved geteltorito to the appropriate folder with…
sudo cp -v geteltorito /usr/local/bin/

Then I set permissions on geteltorito with…
sudo chmod +x -v /usr/local/bin/geteltorito

Then I used geteltorito to convert the *.iso to *.img (note the *.iso file is the one you should have for your own system downloaded from here. That’s the direct link from the support page you linked to).
geteltorito -o update.img r2kur34w.iso

Then I burnt the image to USB with the following…
sudo dd if=update.img of=/dev/sda bs=4M status=progress ; sync ;

Then I rebooted and pressed F12 during the boot process. When presented with the boot menu, I selected the USB stick rather than the nvme drive. If there is something blocking you from booting the USB stick, that’s a setting in your BIOS you need to change. It’s possible that secure boot is preventing that on your system, however I have secure boot running and had no issue booting from the USB.

The only thing I could see preventing that would be Prevent BIOS Rollback which as it’s name suggests, prevents the BIOS being rolled back. But since you’re not rolling back and you’re in fact quite a few BIOS behind, it shouldn’t be an issue.

1 Like

Or you could probably install it in a toolbx on Silverblue.

2 Likes

Thank you very much.
I had to “disable SecureBoot” and re-enable it after flashing.


1 Like

Thanks, that is what I did

1 Like

Interesting.

Did you run the entire process in a toolbox? I just wonder if all of it or part of it was done from / used components in a toolbox, is that the reason it couldn’t boot with secure boot while I could. Or maybe it’s just a difference in BIOS settings between E series and T series… ¯\_(ツ)_/¯ who knows.

1 Like

Yes. Expect sudo dd if=update.img of=/dev/sda bs=4M status=progress ; sync ; because I was missing rights in toolbx.

Have a look on the video, what the reason could be, that on some computers it works and on some not: https://youtu.be/5T1Frk70LTQ?t=83

The video is wrong about the expire date of the Microsoft certificates. They expire June 2026. Besides, the expire date is not enforced as can be seen when the Fedora certificate was expired a couple of years before the updated certificate was made available.

To check your certificates, run

mokutil --list-enrolled --db |grep Microsoft
mokutil --list-enrolled --kek |grep Microsoft
2 Likes
$ mokutil --list-enrolled --db |grep Microsoft
580a6f4cc4 Microsoft Windows Production PCA 2011
46def63b5c Microsoft Corporation UEFI CA 2011
b5eeb4a670 Microsoft UEFI CA 2023

$ mokutil --list-enrolled --kek |grep Microsoft
31590bfd89 Microsoft Corporation KEK CA 2011
459ab6fb5e Microsoft Corporation KEK 2K CA 2023

and

$ mokutil --list-enrolled --kek 
a2cc64c8e1 Lenovo Ltd. KEK CA 2012
31590bfd89 Microsoft Corporation KEK CA 2011
459ab6fb5e Microsoft Corporation KEK 2K CA 2023

$ mokutil --list-enrolled --db 
7b9e6cc3c2 ThinkPad Product CA 2012
cb02597148 Lenovo UEFI CA 2014
580a6f4cc4 Microsoft Windows Production PCA 2011
45a0fa3260 Windows UEFI CA 2023
46def63b5c Microsoft Corporation UEFI CA 2011
b5eeb4a670 Microsoft UEFI CA 2023

Those certs are expired?

The “2023” in the descriptions is the year the certificate was created. For full listing including expire dates, add --verbose-listing to the mokutil command.

1 Like