(SOLVED) error: symbol `grub_is_shim_lock_enabled` not found

[osugi_sakae]

This started happening at boot after the recent grub and installkernel updates.

I did at first have the issue some have had because we forgot to rerun grub-install. I used the live disc to chroot and fix that.

But then the shim lock error appeared. Grub comes up correctly, and I choose the 6.6.21 kernel. It starts to load, gives the "error: symbol `grub_is_shim_lock_enabled` not found" message, then loads the initial ramdisk, gives the same error again, and fails with "press any key to continue". Still seems to be in the small grub 2.12 window in the middle of the screen (hasn't switched to using the entire screen yet).

I've spent hours in the live dvd checking grub, efi, the entire boot directory, etc. Even recompiled the kernel.

I tried rerunning either grub-install or (I forget which command) with --disable-shim-lock, as someone somewhere suggested.

Root partition is LUKS encrypted, but the system isn't making it that far into the boot process for that to be an issue.

/boot is a separate partition, formatted vfat. Everything seems good in /boot and /boot/EFI.

Any thoughts? This system has booted many kernels without problem through the last few years, so I don't think it is a hardware issue or a forgotten config command somewhere.

If it might be helpful: ASRock mobo, AMD cpu from two or three years ago. Boot and root are partitions on the same SSD.

EDIT: Solved!

Turns out the error had nothing to do with secure boot, despite the error message. The problem was mismatch of grub64.efi files in /boot. grub-install put new files in /boot/EFI/EFI/gentoo/ but when booting grub is looking at /boot/EFI/gentoo/. (No idea why that is, but not going to deal with it just now.)

There was a grub64.efi from like 2021 in that dir, so it did not match the rest of the files (from init disk or grub dir or ???). Copied the new one into /boot/EFI/gentoo/ and machine booted into the new 6.6.21 kernel just fine.
_________________
I am not a number, I am a free man.
---- The Prisoner

[majoron]

Same problem here. Similar setup.

I booted with a live USB, mounted / and /boot (my efi dir is /boot/EFI) and copied the newly created kernel from the wrong location to the right one:

[GDH-gentoo]

I don't know how you people ran grub-install, but it has always installed grubx64.efi in /boot/efi/EFI/gentoo by default unless invoked with an --efi-directory option. This isn't new behaviour.

The need of --efi-directory and the correct value depends on where the EFI System Partition is mounted for any given computer. If it is mounted at /boot, then the correct invocation is grub-install --efi-directory=/boot, and grubx64.efi will be installed in /boot/EFI/gentoo indeed (i. e. directory \EFI\gentoo of the FAT filesystem of the ESP).
_________________

[osugi_sakae]

Thanks for the info.

I think the question I have at this point is not so much how did grub64.efi get in /boot/efi/EFI/gentoo/, but why is grub not using that one and instead using the (very old, in my case) one in /boot/EFI/gentoo/?

Is there maybe a hierarchy of dirs that grub checks, and /boot/EFI/gentoo/ comes before /boot/EFI/EFI/gentoo/? The grub that is booting is the same one that installed the grub64.efi file, right? It seems like it should know where it put it.

Or am I misunderstanding something? I've not had to deal this much with boot stuff since the old days of LILO, so I'm not that familiar with all the modern intricacies.
_________________
I am not a number, I am a free man.
---- The Prisoner

[logrusx]

I don't think /boot/efi/EFI has ever been the default. It was rather /boot/EFI with the ESP mounted on /boot.

Best Regards,
Georgi

[Slow_cyclist]

I had the same problem. In my case the solution was slightly different; to remove the whole folder of efi-files, and then re-run grub-install. I also had some old files lying around from having run grub-install with the incorrect --efi-directory (years ago). I seems like the upgrade of grub to 2.12 removed the ability of grub to cope with their presence.

In fact, having studied the matter for the first time in a long while, I appear to have been running grub-install with the wrong --efi-directory for years - /boot/EFI/ rather than /boot/. Somehow it's worked until now. (Just using the correct path now didn't solve the problem, though. I had to delete the spurious files).

Keep in mind, I'm not doing any dual-booting, so there was risk of removing something crucial to that.