see last commit ( this is a revert … )
https://git.savannah.gnu.org/cgit/grub.git/log/
Me too, I think jumping into the conclusion, rather hastily without any further steps in troubleshooting, that fwupd has been the culprit of the issue experienced by OP is not so overwhelmingly convincing.
I don’t have extensive experience of fwupd like yourself. However on some occasion in the past I used it to update the firmware for the motherboard of a supported system. It was a smooth experience and no issues to report.
As for many other things, this could very well be one of those “YMMV” cases.
It’s a pity we cannot dig into this issue to come to a more clear understanding of it.
For the sake of Science!
2 Likes
On a lot of distros it’s default now cause it’s stable and you can access snapshots from the Grub menu rather you’re using Timeshift or Snapper.
This is what i was going to do but it’s more time consuming for me than just reinstalling. I know 100% that it was the fwupd because once you mentioned it i remember i had tried it and there weren’t any updates. Then later when i had pacman updates and new kernel and reboot is when it showed.
1 Like
I’m sorry, but that just doesn’t make any sense to me. 
In all my years of using fwupd, I’ve never seen a BIOS or UEFI update contingent upon or as a result of a kernel update. I’m more than happy for someone to correct me with concrete documentation, but I’ve never experienced that or even read about it.
Here’s the other thing. Both BIOS or UEFI boot prior to passing things off and your kernel taking over, making fwupd even less of a suspect. BIOS and/or UEFI are on a completely separate chip as well. Logically, it just isn’t making sense to me and now we’ll never know.
1 Like
You can tell that twice! 
1 Like
I made that statement partly in jest. However, btrfs is employed by systems such as SUSE (primarily for enterprise use) and enthusiast distros like Garuda. In the case of enterprise use, btrfs makes some sense where it will be running 24/7 with uptimes measured in months. Enterprise use also presumes professional system admins who know how to properly deploy and maintain btrfs. For enthusiasts it makes sense since those users should be expected to troubleshoot problems and get familiar with the nuts and bolts of the filesystem.
In the case of general users, I see btrfs as unnecessary and more of a detriment in that it requires more maintenance (running balances and defrags somewhat regularly in order to keep the filesystem optimized). General users using btrfs need to get acquainted with the details of deploying and maintaining the filesystem. That responsibility is not needed when using something like ext4. I see far too many people running to forums to help fix problems with btrfs filesystems. Btrfs appears more susceptible to damage beyond repair from power interruptions and forced reboots. I regularly see complaints from people who lose their btrfs filesystem due to external catastrophes and/or misapplied installations and lack of understanding of required maintenance. I don’t see many complaints from ext4 users for these same reasons.
Btrfs appears to be a decent fit for professional applications where seasoned and knowledgeable system admins deploy and maintain the system. Generally, ZFS is a much better choice for all situations where the features of a COW filesystem are demanded. Btrfs is pushed over ZFS because of licensing reasons, and btrfs is a subpar alternative to ZFS in almost all regards.
3 Likes
Well said. 
Hmmm, I wonder if this has more to do with your problem than fwupd?
The timing was wrong. Grub had not updated when ricklinux experienced his problem.
1 Like
Good to know.
Still doesn’t make sense. I use systemd-boot so it’s been awhile for me.
There are so many “unknown unknowns” in this case so we cannot possibly find the smoking gun 
2 Likes
You and I are not going to agree.
Just a thought for you Grub users here. There was an update to mkinitcpio recently which would have left a pacnew file. Have you checked recently with Meld/Pacdiff via the Welcome app? I say this because there is a thread in the Arch forums about this and apparently it caused issues with Grub.
https://bbs.archlinux.org/viewtopic.php?id=293430
It may be worth a read. I cannot be of any more help as I use systemd/dracut instead.
3 Likes
As do all the righteous 
2 Likes
Funny, I made at least 10 different points and you disagree with all of them? OK. 
All i can say is fwupd was the only smoking gun that i had used prior to this issue happening. I’ve used btrfs and grub for a long time with no issues like this. This also happened to @tlmiller76 and if he hadn’t mentioned it I wouldn’t have even remembered using it. Although it would be nice to know exactly what it did the /boot/efi files I don’t have any need to save anything so reinstalling it in under 4 minutes is just a simple task. This is my test machine anyway so i beat it up every day.
1 Like
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.