Just would like to express appreciation for the “Full transparency on the GRUB issue” topic.
(this topic was the best I found in the forum regarding this grub package problem)
“Grub 2:2.06.r322.gd9b4638c5-1 won’t boot and goes straight to the BIOS” has grown into a deep well of posts – over 780 posts at time of this writing.
Hoping to see some clarification as to what in grub or grub.d set this storm in motion, as well as notification once a safe, grub-package-update is issued.
It is explained in the post you referenced but at a high level, the new version of grub required a call to grub-install which no grub update had ever needed before and there was no warning of this change.
Right now we are trying to find if this will be changed in a future release or not. It will be up to the grub devs to decide if they see this as a bug or not. If they don’t it is possible it will require manual intervention to resolve.
I thought all the jumping to rEFInd or systemd boot right off the bat was a bit on the knee jerk side (but I’m not at all dogging those who did). BUT - if the Grub devs don’t see this as a major flippin disaster that absolutely needs to be fixed and do all that is reasonable to prevent such an occurrence again, than jumping is more than a good idea.
It all depends on the individual user. I’ve never had grub break like this on me before. I’ve also never really given it much thought of what bootloader to use with my system either. I’ve always went with the defaults. But after this “setback” I did some research of the various bootloaders out there, as well as brushed up on grub, and I determined that for my own system I didn’t need all the features grub was offering.
I just wanted something simple, modern, and ideally just works. So I landed on systemd-boot which is what some users who’s opinions I value very highly here use as well. ‘systemd-boot’ does not fix everyone’s use case, but for me it’s just what I needed. I didn’t make the switch the minute the grub issue happened, but I’ll admit it did become a priority that I looked into for myself and determined I was far better off leaving grub. We all use our system in different ways, I just try to automate mine as much as possible while keeping the risks as minimal as I can.
With that said, if it wasn’t for this amazingly helpful community, I’d still have a borked setup, I’d still be on grub, and I’d probably be attempting to reinstall for the third time on my own. Thankfully I don’t have to do any of that! Instead I have a simpler setup, everything is working as intended, and I’ve got all the users here to thank for that. 
Not all of us are jumping. Some of us already use rEFInd but it also boots from grub.
Edit: I decided to go back to grub only for now.
@Scotty_Trees
I might use systemd-boot but i don’t know if you can multiboot with it?
If you’re already using rEFInd and if it already works perfectly fine for you, I would just stick with that. I choose systemd-boot because it’s simple and less likely for things to go wrong. Can it multiboot? 100% it can. But I don’t use that feature, so I can’t offer you my experience with it.
I’m also not jumping (I don’t have choice). It seems that syslinux doesn’t support btrfs fs with compression.
I don’t have enough experience with systemd boot but maybe some day. Not sure how it works for multiboot? For now I’ll stick with grub and rEFInd too since it’s the most familiar. There are lots of things I still don’t understand about them also yet!
I believe you need to go into the uefi boot menu each time you want to change, which was one aspect that dissuaded me from using an independent distro for my desktop.
That isn’t the case. My laptop multi-boots many distros with systemd-boot.
Somewhere around here there is a whole post on the project.
As far as I can tell, this is affecting Arch because Arch decides to backport newer patches into grub before the grub devs actually release a new version. The pkgbuild file for grub in Arch contains numerous patches backported from the git branch of grub. If Arch stuck to the stable releases of grub, this would not have happened. I don’t see this as a grub developer problem. Furthermore, since Arch seems to be affected because of their preference for inclusion of newer patches, this is really an Arch problem to solve.
Then again, even if Arch stuck to the stable releases of grub, this problem might just have been delayed until grub 2.08 is released. I don’t know.
I think it should be possible to use a pacman hook to run grub-install after grub is updated. That might help? I have not tested it, but it makes sense to me. Never mind, running grub-install would require the exact options used during the initial install. Sorry. 
I was using systemd-boot on my main PC. I was really happy that it was not affected. The other PCs and my laptop where affected by the grub issue. I took the opportunity to migrate all of them to systemd-boot. bye bye grub.
There is a good tutorial from @dalto how to migrate to systemd-boot:
I think this is going to be a pattern followed by many users in the following weeks. Grub sucks, but not compared to the alternative… 
The grub issue was the first real issue I had with EOS in more than 8 month of usage. And in my humble opinion, the developers and community have been highly professional with troubleshooting.
Thanks to all people involved.
In my 9 months of using 
, there was only one bad update which lead to me having to use tty to downgrade mesa. That’s it.
Two other times I needed any intervention was when I didn’t perform updates properly or stopped them somehow in between causing to bad/corrupted initramfs. But that’s PEBKAC
I have btrfs snapshots set up but I never use them.
Only time I needed it is when I accidentally rm -rf my home directory. 
Ahhh nice, read the mail, really fast. 
You gave me a bit of self confidence! I thought my mental capabilities are gone!
I did exactly the same! I just skipped cd to the folder I want to rm.
For what it’s worth I have been using GRUB since the first “Legacy” version (for those who remember, the one that was stuck at Version 0.97 for a long time before finally being rewritten and replaced by GRUB 2.
Both versions have always been solid, as are the vast majority of boot loader and boot manager programs.
To me this is a clear error on the upstream packaging team, but it’s the first time I’ve seen this so even the best of us occasionally make mistakes. I don’t anticipate repeating instances of this, based on the past 20 years of solid history.
I have them as well but since I couldn’t boot at all, the snapshots didn’t help much