Wait for fwupd update:
2 Likes
Okay, thanks a lot.
I think you have to manually run the fwupdmgr command
sudo fwupdmgr refresh && sudo fwupdmgr get-updates will tell you what updates are available.
sudo fwupdmgr update will actually perform the update.
fwupdmgr --help will give all the commands and options available.
3 Likes
I can also do that. As far as I can understand there was a bug in the fwupdmgr and now it’s fixed ?
I’ve answered to fast before. This update is normal, but it comes from LVFS (https://fwupd.org/) through fwupdmgr (not dnf). You can install it.
If you can’t apply this update in Gnome Software, try like @computersavvy (or I in linked post) wrote, it’ll either work or throw some error. If this error is similar to the one in linked post, read that: https://github.com/fwupd/fwupd/issues/5035#issuecomment-1250094031
If you get different error, post it here.
1 Like
It’s better to use semi-colon between those commands, because second one won’t get executed if fwupdmgr was updated in last two hours. Also there should be no hyphens before refresh.
sudo fwupdmgr refresh ; sudo fwupdmgr get-updates
1 Like
Hmm. I have first did,
sudo fwupdmgr refresh ; sudo fwupdmgr get-updates and later on sudo fwupdmgr update. but I guess I broke something in my system because now I cannot access any of the Fedora kernels, and it gives this error.
From my research it says disabling secure boots might work. Is that really the case ? Should I redo the steps with that option ?
This post says I should try rmmod tpm in GRUB menu. Any ideas ?
Was there anything beside UEFI dbx updated?
On some laptop that update changed default boot entry to some old leftover. Open boot menu and make sure you’re booting the correct entry.
If that doesn’t help, you can try steps described on that reddit and disable TPM, at least to start up the system.
No there wasn’t anything else.
I was using Windows before and I deleted it completely but some parts of might be left at the EFI. Because in the GRUB menu I was seeing Windows Boot Manager even tho I completely deleted it.
The boot order seems correct. I had a bootable USB so I will fresh-install. Luckily I can access to UEFI firmware settings and can change the boot order to access the USB.
This time I’ll try to do it over gnome software…or maybe I should just ignore the update but it’s kind of annoying in that case.
And interestingly, even I delete the Boot option from the UEFI FMW settings it still appears in there after I re-open it. But it does not show up on the GRUB menu. I believe there’s some windows code left in the EFI that is messing my system.
Fresh install did not work. I am still getting the same error.
That shouldn’t be necessary.
Gnome Software won’t do it any better, it uses fwupdmgr. If update succeeded, it won’t be bugging you until new dbx is released.
dbxtool -l will list content of your UEFI dbx, version 217 has 268 entries, so you’ll know whether it’s updated.
Formatting/recreating EFI partition and reinstalling Fedora should have cleaned that up (so would removing windows files and regenerating grub config). After that, removing windows entry in UEFI setting should work.
Have you tried that in grub console?
What TPM settings do you have in BIOS?
1 Like
Sadly. I already did…I thought maybe it would change the EFI file system and the problem will be solved.
It was gone but now it has re-appeared. I don’t know what’s wrong…
No, I have not. Instead, I disabled the SB. And it worked…Now I can boot without an error.
Also dbxtool -l shows 268 lines. So it’s seems upgrade was successful, however I cannot use SB so I don’t know what was the point of this update…
The point of dbx is to block you from using an old shim and/or grub2 version which could contain the “boot-hole” bug.
After searching the error online, I find this post from a couple of months ago.
https://discussion.fedoraproject.org/t/grub-core-error-you-need-to-load-the-kernel-first/73536
Which is the same error as I have seen (see post 7/8)
In this page
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1848892
It says
Some specific systems (listed in upstream thread at https://lists.gnu.org/archive/html/grub-devel/2019-10/msg00104.html).
Mostly ASUS systems, but also reported on some Dell systems.
The affected systems are used to boot in UEFI mode and will fail to write measurements to the possible onboard TPM, causing failure to boot.
And my computer is ASUS…
From the comments, it seems that most people solved the problem by disabling either TPM or Secure Boot. Maybe disabling TPM is better than disabling SB? Should I try to disable TPM instead of SB?
Also, this bug report is from Ubuntu. Can it be solved in Fedora as well, so that someone does not need to disable one of them…
So it has not much to do with the SB ?
Disabling TPM or SecureBoot is definitely a workaround.
Why that happened after dbx update? 
New entries filled some memory?
Something got blocked? You could compare hashes from dbxtool -l with find /boot/ -type f -exec sha256sum {} \; (for example using conditional formatting of duplicates in LibreOffice Calc).
If you don’t have your data on disk and in TPM, you could try restoring BIOS to defaults, purging TPM memory and formatting disk, to get rid of old windows leftovers.
Do you have any BIOS updates available?
I guess disabling TPM is better than disabling SB…? How can I perform those steps ? I really want to get rid of the old windows leftovers. How can I check my BIOS updates ?
I’ ll try that.
In BIOS, if manufacturer facilitates such settings.
On your manufacturer drivers’ page for your laptop model (unfortunately ASUS doesn’t provide BIOS updates through fwupd yet).
1 Like
I see…I guess I ll leave it like this for now…but thanks for the help.