Yup. Not gonna lie, I didn’t even know the grub-install command was a thing before the grub issue. I knew what grub does, but I didn’t think it required any “manual maintenance”.
While I wasn’t affected by the issue, since I saw the post before updating, I was still able to learn something.
The reason to update grub cfg has not vanished, so if the hook is removed, the user should do it manually.
I guess you mean “the Install Grub to ESP” procedure, not the “re-generate grub.cfg”.
In any case, there is no magical solution to avoid all possible future bugs, thus the user should normally do everything manually.
All distributions try to lessen the difficulty of maintaining/administrating their OS, but every automatic solution may become obsolete with future package upgrades at any time.
This way, packaging becomes an art, if (any) upstream devs want to avoid backwards compatibility problems.
Arch is not for ease-of-mind local admins, even if many derivatives try to accomplish that (and even worse, advertise as such). 
The tools that might help you do that exist, if you are using grub.
ls -1 /bin | grep "^grub-"
info grub
Nevertheless, for UEFI installations (maybe also for BIOS), switching to a standalone grub, instead of standard install, might be a solution.
grub-mkstandalone <==> grub-installLets just stick with grub and carry on. Otherwise might as well switch to something else. I think this is so overblown. 
Those would pretty much be the only two options. 
So I run grub-install and then grub-mkconfig -o /boot/grub/grub.cfg right @dalto?
You need to run an appropriate grub-install command for your system. Are you using BIOS or UEFI?
An appropriate
grub-installcommand
Could you be a bit more specific?
Are you using BIOS or UEFI?
UEFI
It is specific to your actual system.
If you have a fairly standard UEFI install it is likely that sudo grub-install --no-nvram will work.
And what’s likely to work on a BIOS system?
sudo grub-install
Have you seen anything weird about my partition scheme @dalto ?
And why it wouldn’t work?
You appear to have a standard UEFI partition scheme but you have no access to UEFI variables which means you are booted in BIOS mode. I don’t understand how that is possible to be honest.
I just want to confirm one more time.
When you ran the command sudo efibootmgr, you were booted into your install as normal, not booted off a live ISO or something else.
Yes, I’m running my install from my ssd and booting in eufi mode, as always.
Can you run the command again. sudo efibootmgr. Also, ls /sys/firmware/efi
I just dived into the bios and the boot method is set to uefi+legacy…
Would it be that I’m booting in bios mode?
Now I’m not certain any more.
$ ls /sys/firmware/efi
ls: cannot access '/sys/firmware/efi': No such file or directory
It seems that you are booting in BIOS mode. But your install is definitely not setup for that. You disk is GPT, you have an ESP and your ESP is the partition that is set to be bootable.
My best guess would be that you did a UEFI install originally and then at some point(maybe during the grub debacle?), reinstalled grub in BIOS mode.
What you probably should do is boot the live ISO in UEFI mode and reinstall grub in UEFI mode.
I was very certain that it would be an uefi install, I always do that since a couple of years.
But I am booting in bios mode and I can’t for the love of god remember what I did so that this machine boots in bios mode.
Changing the modus in the bios from uefi+legacy to uefi boots to grub rescue, so I’ll probably reinstall grub with a live iso.
All done and we’re up and running, thank you for your help @dalto .
$ ls /sys/firmware/efi
config_table efivars esrt fw_platform_size fw_vendor runtime runtime-map systab
Wouldn’t grub-install, in this case, complain about embedding not being possible on a GPT disk which is lacking a bios_grub partition and fail consequently?