Like others, I could not get r591 to work at all on my laptop, even after chroot from live and sudo grub-install --efi-directory=/boot/efi.
In the end I downgraded to r566 from chroot.
I’m thankful that, having seen grub in the upgrade list, I had the presence of mind to test on my (expendable) laptop rather than my main desktop system.
Grub r566 is going to the IgnorePkg corner indefinitely on all systems. [edit2: not a good idea long term, see long discussion below]
Next install will stick with systemd-boot. Some moderate amount of breakage is expected and tolerable when upgrading, yes. Casually bricking the system (unless you have a liveUSB on hand, and until you have the time to perform a chroot or several) does not qualify as moderate in my book. Twice in 6 months is way too much for something that critical.
I assume he, like me, is trying to get on with his life and not to have to worry about grub randomly breaking on update anymore.
Not really, unless you need something specific in the new versions. Nothing depends on the grub package. [edit: not a good idea long term, see below]
The update does not touch your /boot/efi directory, so GRUB cannot randomly break on update. It can break if you regenerate the config file with the wrong version of GRUB.
Consider, what happens when you update, for example, glibc, but you ignore an update to grub package? What would happen if you tried to install a new kernel?
You’re only making it more difficult for yourself down the line.
Personally, I upgraded as usual, did not run grub-install or -mkconfig, (I never did) and… brick. Fortunately on my disposable laptop, again. And another time in a VM.
Right. If glibc updates I expect it’ll break then. Fantastic.
I think you did, you just don’t know it. You probably have an automated hook set up to run grub-mkconfig as default on some earlier ISOs of EndeavourOS. That was a mistake on the part of EndeavourOS, not GRUB’s fault. This lesson was learnt last August.
No, it won’t break, it will be much worse than that. It will work fine. Then, one day, you will run grub-mkconfig and it may break, but if you run grub-install to fix it, that won’t work, because you’ll have a wrong version of glibc. That’s why partial updates are not supported on Arch.
I have now, (or had until 10 minutes ago ) because I set it up after r322. And I have the git logs to prove it.
And since then I read the output of the hooks carefully on each update; there was only one instance on that output, each time. If there had been a preexisting hook I’d have seen it run twice, each time.
And the systems I updated without running them were bricked until I did run the commands explicitly in chroot. If the problem was that they were run automatically, then running them again would not have fixed the bricked systems…
If you read the previous thread, you will see adding a hook mentioned as solution for future instances of the problem; there were other threads and posts to that effect on the boards at that time.
I would really like for you to be right, for grub updates to be safe by default. But I don’t see any way that can be the case here.
Not update grub package. A bad idea in the long run.
Don’t run grub-mkconfig and grub-install when you don’t need to.
Run grub-mkconfig and grub-install every time the grub package updates, but be careful to do it correctly and manually (do not try to use hooks to automate stuff that shouldn’t be automated). If you mess up, you’ll have to chroot, so be ready for it, keep an USB on hand and do it only when you have 5 or so minutes to spare.
Or use systemd-boot. Of course, there is no guarantee that that won’t ever break.
Personally, I find GRUB to be very reliable.
I only got screwed once, and that was not GRUB’s fault, but because of the EndeavourOS hook. It took only 5 minutes to fix it.
Unfortunately, this was on my mum’s computer. I updated it when I visited her earlier that day, shut it down, and went home, and then later that night realised that her GRUB is borked. I was travelling next day to Norway, and I would be gone for two weeks, my mum unable to use her computer. So, I had to go back to her flat to fix it, and it was already 11 in the evening, and I had to catch the plane at 7 o’clock next morning. When I got back home, it was already very late, close to 2 I think, and I didn’t even begin to pack. But that’s just bad luck.
On my vanilla Arch machine, I’ve never had any issues with GRUB.
Not update grub package. A bad idea in the long run.
The problem is that I’d love to upgrade to r591, but everything I’ve tried so far hasn’t worked, while r566 works flawlessly. I probably can refrain from running grub-install and end up with a working system for the time being, but the same logic applies, the first time I need to run it to fix some issue with grub-mkconfig will brick the system.
It seems like a bug to me on GRUB side, there’s too many reports from people to be a config problem on our end, even this thread on Arch Forum. I personally think that I’ll skip a couple revisions and will try to update GRUB in a couple of months to see if anything changed, but it looks more and more like a bug in r591. I’ll keep looking into it, but GRUB error messages are about as useful as an ashtray on a motorbike.
It was a hook that ran grub-mkconfig every time a kernel was updated. I’ve deleted it since from all the computers I look after. It’s no longer part of the EndeavourOS install, but if you’re on an older install you might still have it. This was the hook that caused the legendary Grubbening of August 2022.
That was the one I was referring to; I linked the wrong stuff previously, I wanted the original breakage thread for r322 in august 2022:
I think I finally understood something:
1° you’re talking about a hook that runs only mkconfig, while my own ran both grub-install and mkconfig.
2° The existence and role of that hook in the Great Grubbening of 22 was not mentioned as a cause of the problem in the thread, and so I developed a warped understanding of how grub works: I thought part of the grub package files passively played a role in the later phase of the boot, somehow:
So what was implied was “When you call grub-mkconfig, whether manually or because the hook we set up on kernel update does that for you, that updates only the userspace components.”
Pinging @dalto for sanity check.
One last thing I want to check: are we agreed that there is no reason to run grub-mkconfig on kernel updates, only on install/removal of entirely new kernels (eg zen or something like that)? (Or of course upon modification of /etc/default/grub, or after a grub-install)
If that is the case, since I’ve all the kernels I need (vanilla, lts, zen) already, and I’m happy with my grub config and unlikely to tinker with it anymore, now that I’ve removed my -install + -mkconfig hook, I can basically ignore updates to the grub package entirely (until I want to tinker again, of course).
Well, you shouldn’t ignore updating the grub package, as in keeping it on your IgnorePkg list. Just update it normally.
That’s pretty much how I do it, I almost always forget to run grub-mkconfig and grub-install when the grub package is updated. I mostly worry about that when I change my config or install or remove a kernel.
The only downside is that you’re not getting any security updates or bug fixes to GRUB.
Thank you for this lengthy exchange, it did serve to clear up a major misconception I had about how grub works — this will considerably reduce my stress levels when dealing with it henceforth.
Thank you for this post. I consider myself a n00b what comes to Arch. I was on impression that I have to run grub-mkconfig and grub-install after every new grub install. Now I updated to new grub, rebooted and everything works fine.
It’s a bit confusing. Updating the grub package does not update your installed bootloader on the EFI partition, it just updates the package. To actually install the new version of GRUB (to your EFI partition), you run grub-install after updating the package. If you do not run the install command, you will continue to use the version of GRUB you have installed in your EFI partition, regardless of the version of the package grub you have installed.
If you have snapshots, you need mkconfig to update the snapshots in the menu.
Grub-btrfs has a hook to update grub on every snapshot taken.
This post was written after I updated grub and turned off my PC without installing and mkconfigging it and realized the above so that when I next turn it on, I will have to downgrade again. Sad
The first one, if I’m not mistaken, gives you the installed version, the second one gives you the package version. I could be wrong, because right now on my computer, both give the same number. But I did run grub-install yesterday, to see whether it would boot, so it would make sense they are the same.
) because I set it up after r322. And I have the git logs to prove it.
