Edit: Not what i thought because i was thinking it was all pacman related.
Edit2: I think a lot of people are probably as confused about this as i am. All along i was thinking this was a shortened command to re-install grub and then running the update grub command would create the proper entries.
That’s a normal thing to think at first, because of the name grub-install – since it is pacman that does all the installing on Arch. But no, it’s a utility provided to us by GRUB that… deploys… it.
So with GRUB, there are three steps:
Installing (or updating) that package grub with pacman.
Actually installing (or deploying) GRUB to MBR or UEFI and nvram with grub-install utility.
Generating config file /boot/grub/grub.cfg with the grub-mkconfig utility.
We never did step 2 before this issue…
I find it very confusing myself, even though I think I got it.
Yes, I don’t think a proper explanation of this grub fiasco got in my head. I understood parts of it but it’s gotten more confusing since then. Now i understand the other 90%
Edit: Partly this is because i never saw the grub-install command before or used it until this grub issue came along.
Apparently we should have been doing it all along, but we just never did.
In the past, the only time I ever saw this command was when I was installing Arch the Arch WayTM. The thought that I was supposed to run it on every GRUB update wouldn’t have occurred to me in a million years.
And that is the reason Arch was so bold on calling an installation “Arch”, only when it was installed the ArchWay.
For the discussion, I can only say it is very sad to see so much panic.
Everyone has an opinion, so do I
Work as usual! Do not install grub (to EFI or MBR) after grub package updates.
Short justification: Because this was a bug, and the solution was to re-install grub. Nobody knows which will be the solution to the next bug (which will break some systems). Imagine if the solution to the next bug will be to not install grub, because it would break the system!..
If you insist, I can write a small essay with more details.
Was it a bug, though? I don’t think it was. It was just a new feature, an option that the new version of grub-mkconfig added to grub.cfg, which wasn’t recognised by the old version of GRUB that was previously deployed with grub-install.
There is no panic here. Just trying to understand what is what and why? Because i believe that it’s not necessary to over complicate this. But the fact remains it’s not well understood by many.
One more thing to note is that arch uses commits from grub upstream instead of releases so that they package the latest security patches to grub and ship to arch users. But we won’t get the advantages of the security patches if we don’t run grub-install.
So, if we are not running grub-install there is no need to update grub at all.
That is hotly debated. Several people are claiming it is bug, but the grub team hasn’t changed it yet so it isn’t clear if they consider it a bug or not.
When I write software (though I don’t write bootloaders), and I decide to change the format of some config file (for some reason, like an added feature), I make sure that the new version of the program can still read the config file from the old version of the program, i.e. it doesn’t crash when it doesn’t get a config file it expects. That is how it is most often done.
However, doing it in reverse, ensuring that the old version of the program works with the config file intended for the new version, is really difficult, if not impossible. Failing to do so is something I’d consider normal, definitely not a bug. That is why downgrading software can often cause the current config files to become useless.
It was a bug, but not a grub bug. It was an administration bug, actually, a packaging bug.
The introduction of a package version that would, in specific circumstances/system configuration, would break a few or more systems (but not all), is a bug.
Have grub devs caused the bug? No. They had not released that version. It was a git package.
Who introduced git instead of version packages? Arch.
Are bugs (any bugs) a sin? No! Every complicated program has potentially bugs, not yet found, or introduced after a code modification.
When a program modification breaks compatibility (in some way) with systems running an older version, this has to be dealt with before the new version lands. That’s why testing is a part of tech/coding.
How long, or how strongly should packagers/distributions test new package versions? As strong/long their identity suggests. That’s why we have so-called Stable Distros and Arch Stable Rolling has a Testing branch.
Should we blame Arch for a packaging bug? Of course NO!!! $hit happens…
What should users do from now on? If they got shocked, they should take it as a lesson and learn from it. Stop ignoring Wiki RTFM. Overcome terminal-phobia. Don’t administer your system with copy/paste dat command, and focus more on understanding. And if the previous are not acceptable, choose another base distro, that can afford more testing.
Surely, that depends on the specific circumstances/system configuration? To give an absurd example, literally every software update will break the system if the update is done when the laptop is submerged under water.
So if it depends on the circumstances, we should take into account that Arch does not come with Pacman hooks that run grub-mkconfig on every kernel update. So how could it be a bug with Arch? And how could they have caught it in testing, when they don’t have these hooks? In fact, they warn you against automating any part of the update.
This is why, btw, Arch devs do not consider it a bug. If anything, it’s a “bug” on distros like EndeavourOS, Manjaro, and Garuda, which have such a hook. But if it is a bug, it’s a bug in what package? grub? No, GRUB works as intended. Package that adds the hooks? Well, those hooks have nothing to do with update to grub, and they worked as intended… So I don’t think it is a bug at all, just a very unlucky set of coincidences.
No and Yes.
Arch is not only the packages. It’s the wiki as well, an inseparable part of the distribution. Wiki explains when and why such a hook would be a nice administrative (helper) technique. If you do as suggested, then you run into the breakege.
What Arch does, and is very clear about it, is that breakage may happen at any time. Be prepared!. So, that’s what’s needed. Users (local system admins) should, at the least, know how to chroot and fix broken installations.
Not by word, but for an Arch user, when pacman hooks exist, as a mechanism, to accomplish essential administrative tasks, and wiki insisting the reminders to “remember to re-generate configuration after this”, it is assumed as a normal way of doing it. Nevertheless, I would swear it was written by word, but since the wiki, luckily, is a dynamic book of current knowledge, it may have been removed. I have been supporting/troubleshooting grub issues, since 2016, learned by the best (@gohlip at MJ forum)
BTW, as I was looking for this hooks word, the only mention was for the need to ensure /boot is mounted, when you have it on separate partition, and you act on /boot. Maybe it could be the next bug
