Latest grub bricked my system (grub_is_shim_lock_enabled not found)

Hello, in the last update this morning i updated to kernel 6.4.1-zen2-1-zen and updated grub from core/grub 2:2.06.r566.g857af0e17-1 -> 2:2.06.r591.g6425c12cd-1.

After the grub-install ... and grub-mkconfig -o /boot/grub/grub.cfg i reboot and could not boot in any of the grub menu items.

the error message, when i select a kernel to boot, would be:

loading snapshot: date @snapshots/snapshot
loading kernel: vmlinuz-linux-zen ...
error: symbol `grub_is_shim_lock_enabled` not found
loading microcode & initramfs: amd-ucode.img initramfs-linux-zen.img ...
press any key to continue

i had to boot from live ISO, mount my previous system, arch-chroot into it, downgrade grub and remake grub with grub-install ... and grub-mkconfig -o /boot/grub/grub.cfg.

i also tried remaking grub before downgrading, no change.

no kernel would work, no snapshot would work tried every menu item.
i don’t have secure boot enabled, had no problem prior to the grub update ( proven by the fact that downgrading only grub works perfect ) and could not find any documentation on this specific error

on endeavourOS, btrfs filesystem
partition EFI
partition BTRFS

if you have any idea on why this may have happened i’m very happy to hear it because now i’m scared to update grub.

I had this happening to me as well.

Normally after an update to the package grub, I do:

grub-install --no-nvram


grub-mkconfig -o /boot/grub/grub.cfg

But today after reboot, I had the same issue as yours.

I tried then again with:

sudo grub-install --efi-directory=/boot/efi

and this resolved the issue for me. Looks like, this time, the EFI entry needs a renewal.

I thought it was an issue on my end.

If other users are also hit by this, perhaps an “announcement” should be made on the forum.

correction: --efi >> --efi-directory.
Thanks to @gipo355 for bringing it to my attention.


thanks! will save this when i next update grub to try if it’s not fixed by then

1 Like

to be sure, do you mean this?
man --efi-directory=DIR use DIR as the EFI System Partition root.

Right. I see that there was a “typo” in my previous post.

My ESP (EFI System Partition) is mounted at /boot/efi, thus --efi-directory=/boot/efi.

I am not sure though if that was relevant in this case. I think omitting --no-nvram was what solved the issue. I have no way of verifying this now.

not sure, i used the command grub-install ... with no --no-nvram

although i’ll be honest i’m not sure what the 3 dots mean, but i follow the tutorials.
is it 2 folders up?
so from home its /home/userFolder? user folder … home … /?

That is quite unfortunate that the message from pacman is not more explicit.

Instead of … it should say Run grub-install with appropriate arguments/options or some such.

Had the same issue this morning, I had to chroot and manually downgrade GRUB. For the time being I put the grub package in the PackageIgnore list inside pacman.conf, but I’ll try to reinstall it specifying the /boot/efi path. I’m glad it was not an error on my part at least.

EDIT: weird I didn’t see any mention of this problem on Arch reddit.


yeah same, i have informant and checked arch news and endeavour announcements too + reddit

I updated grub(2:2.06.r591.g6425c12cd-1), rebooted my system and was just able to boot as normal.

yeah so somehow running grub-install ... from ~ works because it installs from / (path traversing?) and the default args are used in endeavourOS

lol good to know

did you run grub-install and mk-config?

Do you have secure boot enabled?

What’s up with the grub development? Half of the time there is an update I have to check the forums if it’s safe to update.

You don’t have to run grub-install every time grub is updated, that is normally only used to install grub to your disk during the installation of the system. I did grub grub-mkconfig to see if I generated a new grub config if my system would be still working and it was still working when I ran that after a reboot. However that isn’t normally needed either because the kernel files that get updated get the same name as the files for the previous kernel so you no grub config update is needed. The only time that is needed if you install another kernel such as the linux-lts kernel, after which you run grub-mkconfig to update your Grub config in so that it shows up in your Grub menu.

this is the pacman output


I hadn’t notice it, I reinstalled the grub package again and got the same output.

:: To use the new features provided in this GRUB update, it is recommended
   to install it to the MBR or UEFI. Due to potential configuration
   incompatibilities, it is advised to run both, installation and generation
   of configuration:
     $ grub-install ...
     $ grub-mkconfig -o /boot/grub/grub.cfg

I find that quite odd because because unless a change is make the the grub configuration running “grub-mkconfig” shouldn’t be needed because grub-mkconfig generates the configuration for the grub-menu.

I did a bit digging and I found out why I thought that was the case. I have been away form Arch-based distributions for a while and it seems like since the Grub bug that happened 9 months ago both Arch and EndeavourOS now recommend running those when updating Grub.

The last time I ran Arch which was about 2-3 years ago that wasn’t the case, so the advice has changed. Seems like I learned something new today :slight_smile: Thanks!

Let me just try it and see what happens.

1 Like

I ran both of those.

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=endeavouros
grub-mkconfig -o /boot/grub/grub.cfg

My efi binary was also just updated.

[root@lilith endeavouros]# ls -l /boot/efi/EFI/endeavouros/grubx64.efi 
-rwxr-xr-x 1 root root 360448  5 jul 12:26 /boot/efi/EFI/endeavouros/grubx64.efi

Then I rebooted and I was still able to boot like normal, didn’t get any Grub errors or other errors when booting.

ok so you didn’t use the simple grub-install which has default flags as we did when we got the problem but provided the flag --efi-directory= like @pebcak suggested earlier which could fix it

No, because Seeing “$ grub-install …” in the pacman output made me think that you have the fill out the rest yourself and it being Arch I decided I would look it up in the Archwiki how you are supposed to run grub-install for en uefi system again just to be sure.

You are right.

Perhaps even better grub-install --no-nvram which should normally work.
There is no need to write into NVRAM each time the grub package is updated.

don’t update the boot-device'/Boot*’ NVRAM variables. This option is only available on EFI and IEEE1275 targets.

1 Like