The problem isn’t the one issue, it is the future outlook.
Since it now seems that running grub-install is required when updating grub, that creates a situation where distro provided automation is much more challenging.
None of that is the fault of the Arch team, but it is a problem depending on how you use grub and what your expectations are.
I don’t think so, after the dust is gone, IMHO.
As I have followed the issue, a different handling from upstream would have prevented the panic.
I hope those who have missed this (potential danger) before it happens, have taken the lesson, even without admitting their part in it.
If there would be a new case that grub needs re-installation, there should be either a proper package script to handle it properly to avoid system breakages (even for those few), or a suitable announcement at least, before it lands in normal repos.
But this is the problem. In it’s current state, it isn’t easily automatable as far as I can tell. The grub-install command you need varies by installation and there is currently no config that manages that. A plain grub-install will handle 90% of the situations but it won’t work for everyone.
Even with a suitable announcement, there will still be major issues. It isn’t like something that breaks the update process. The update is successful and your system is broken. I am fairly certain that the majority of EndeavourOS users don’t check the website/forum before each routine update. Also, they shouldn’t have to.
One would hope…
I/we know that. I didn’t mean to automate/hook a grub-install. The specific/current issue could have been prevented with a proper modification in grub.d/file code (with a patch?). There is some poor logic in how the uefi-check command was entered. The new command (unknown to previous grub version, when installed) could have been avoided and just using the old one, or no check at all. It is better to have a failed grub.cfg generation, and wonder what happened, leading to investigation, than a bad grub.cfg, that will break a system from booting that badly (need to chroot to fix it), for no apparent reason (IMHO).
I take Arch announcements like a crash landing warning:
Place your ID cards in your mouth and take emergency position until someone
wakes you upcollects your pieces
It helps to get it seriously enough, no matter if it finally affects you or not.
I regret to hear this. My suggestion, if I may, would be to clearly suggest EnOS users to always check Arch announcements, before any update, even if they won’t do it. I really don’t follow this statement 
. We are not in Fantasy Island, where everything is perfect… 
The problem isn’t only this specific issue, it is that the grub devs have stated that they expect grub-install to run whenever grub is updated. This means that future changes could also introduce breaking changes.
I didn’t know that. Sorry. Then we are in trouble 
Meanwhile in grub HQ:
An interesting read over on the Arch reddit, they explain the issue through code a bit and then offer some other possible solutions which the Arch devs don’t seem to keen on. I’m not sure on their solution, but the overall thread is very positive and a good explanation of the grub situation :
On a second thought, I doubt they said this literally, in full meaning, but to avoid the unjust blaming. It wasn’t their fault after all, and I might have answered the same, if I was being blamed for no reason.
Going by full transparency, the swift change from versions to master was the real source of the trouble, IMHO.
Nevertheless, my proposal for a workaround, until something better arrives, would be
Edited:
to design/add an EFISTUB entry with efibootbgr to installations, as a backup/emergency rescue. Modifying the installer, (or using Welcome) for new installations. Creating a tutorial and an announcement for existing systems.
I’ll refrain from specific comments and just say that this didn’t reflect well on the Arch devs. And frankly we still need Arch as a base for EOS so i don’t want to see anything bad happen to the Arch distro.
I thought about that myself but it’s not compatible with the current default partition scheme. For that to work the EFI partition needs to be mounted to /boot, but for BTRFS snapshots to work, the kernel really needs to be on the root partition, and so they get installed on /boot but the EFI partition is mounted to /boot/efi (so the kernels get caught in the snapshot preventing a mismatch)
Of course just because i know what the problem is doesn’t mean i know how to solve it 
This is what i was thinking.
Somewhere there was the question before, but tldr :
In the future, must grub-install be run after each update of Grub to prevent the computer from hoofing it?
To my understanding no, unless they pull the same thing they just did, again…
Edit: sorry misread, thought about each arch update not grub.
That’s how we interpret the messaging from Arch devs as.
Yes. That is my understanding.
@dalto nails it on the future outlook.
Grub 2.06 is the current release from upstream and was released June 2021. No updates since; that’s old stable code if they haven’t had any security issues or regressions that blocked others. Or project mis-management, but that’s another story.
After Arch took that release, there have been 10 Grub 2.06 releases, including the 4 last 2 weeks. I know Arch maintainers don’t typically do a lot of patching on the Arch packages. However, this appears to be a lot of patching.
I don’t think other distros (this needs proof though, especially other rolling distros) are that aggressive in patching grub like Arch does.
That’s the other problem here, that the Arch announcement took 5 calendar days to appear. A lot of -Syu’s happened in between. EOS was on it with forum and web site announcements though - kudos! and the Arch bug filed day 2 of that 5 day.