Written by Dalto
Full transparency on the GRUB issue
Since the recent grub issue has impacted a lot of people, we wanted to provide full transparency based on the information we have so far. The situation with this package is still evolving and we will update this post with more information as it becomes available.
The issue
After updating to grub 2.06.r322 many users reported that their machines could fail to boot or booted directly into the BIOS or another OS.
What caused the issue?
Starting with this commit, grub introduced a call to fwsetup --is-supported in /etc/grub.d/30_uefi-firmware. If the version of grub you have installed via the grub-install command didn’t support that command, it caused grub to fail.
How come not everyone was impacted?
Prior to the most recent version, grub only registered the fwsetup if detected support. If your machine detected support, you would have had the fwsetup command registered and the failure wouldn’t occur.
I have already updated and my machine is broken, what should I do?
Follow the instructions in this post 1 to chroot into your system and run grub-install to install the latest version.
I haven’t updated yet, is there anything I should do?
Follow the instructions in this post 1 that relate to that scenario. Basically, run grub-install after upgrading but before rebooting.
What happens next with the grub package?
According to the bug report 1, Arch will produce a version of the package without that commit while working with grub upstream to determine next steps
Why wasn’t this caught in testing?
We can’t answer this question absolutely but there are at least two factors to consider:
- Not all grub users were impacted by this issue
- Many Arch users don’t run grub
What should we do differently in the future to avoid this type of problem with grub?
We are exploring all options here but the reality is that this has never happened before. Blindly running grub-install everytime would be knee-jerk reaction and probably create more problems than it would solve.
We were already considering moving away from grub by default and that may happen at some point in the future.
First we will wait to see what Arch decides to do moving forward and then we will make a long-term decision.
UPDATE 29 August 2022: An updated Artemis Neo 22_8 is released to address the Grub issue for the offline installation. When performing the online installation, the latest packages are already fetched, therefore it never caused the Grub issue in the first place.
For updates on this topic follow https://forum.endeavouros.com/t/full-transparency-on-the-grub-issue/30784
I got bitten by this bug, since yesterday I can no longer boot to EOS in my dual boot nuc machine. I’ll try the solutions outlined above hopefully it gets resolved. Otherwise I’ll try another OS again.
I guess this not an Endeavouros issue rather a general Arch Linux one. I see no need to move to an other Arch Linux distro, espesially because they plan to move from grub for the long therm.
I gut stuck in the same issue and actually I also can’t boot my Endeavouros machine, single OS boot.
I’m now also waiting for a solution, fortunately most of my works can be done on other machines with Windows or MacOS.
Use timeshift on any distro, then you will roleback with ease and install the grub patch.
It is good to have installed two different distros each with timeshift, then you can boot and rollback the other distro or make the rollback from a usb-iso-distro with installing timeshift and start the rollback from there. 😉
Perhaps an ignorant question here, but I just did an update tonight (8/28 Pacific Coast) and was hit with this. Is this package still out there in the wild causing issues for others, or is/has it been removed?
The instructions are there to let you install the right Grub version with the ‘fwsetup –is-supported’ in it enabled. It depends on when you installed the system and if this feature was shipped or not. Grub, not Arch or us, decided to let the recent package update only work for Grub installs with that feature enabled inside.
To be able to run Grub again, you have to go through these steps for this time, unless Grub decides to make another change like this, you should be fine for a long period of time.
Still there
. Screwed my laptop 2hrs back. India
thank you for your quick solution and help. i was really stressed seeing my system not booting today ..
I just got this issue, and I greatly appreciate the fact that you put it front and center on your site. I understand mistakes happen, and I’m glad you admit to them and explain the workaround. Keep up the great work!
Thank you so much for posting this. I ran into this issue and decided to search the web “endeavouros grub” hoping I’d come across a recent forum post somewhere with somebody talking about this problem. Having an explanation and a link to instructions on your site gave certainty and made recovery easy.
If I run `sudo grub-install` after upgrading packages (I checked everytime and my ESP was usually mounted at /boot/efi) grub-install doesn’t report any errors, however, I keep getting stuck in grub rescue mode if I then reboot:
“error: symbol `grub_debug_malloc`not found.
Entering rescue mode…
grub rescue> _”
Does anybody know what I’m doing wrong?
I had the same issue and I fixed it by rearranging the boot option in my bios.
I had a UEFI something and endeavor os and I switched to boot from the endeavor os partition.
Thank you for the detailed fix and posting the link directly on the front page. Easy to find and to follow!
Well… This was one way to learn how to chroot…
Guys, we’re all Linux users, don’t let issues like this to bring yiu down, just read news BEFORE actually upgrading your OS!