Latest grub bricked my system (grub_is_shim_lock_enabled not found)

General system Newbie
121

Yeah, if they are different, that would be useful to know :slight_smile:

122

Well i didn’t have any trouble as the grub package came in an update. I was still confused running the grub update command because i tried grub-install first and that didn’t work. I even tried it with sudo. Then i decided to use sudo grub-install /dev/sdax which worked on all 4 systems. Some have SSD and others are m.2 drives. On a couple laptops i thought it had added other stuff but got that sorted out as i had installed other distros before and the entries were still there in UEFI.

What’s confusing about the grub-install is using the id and or path such as in the wiki.

sudo grub-install --target=x86_64-efi --efi-directory=esp --bootloader-id=GRUB

When they do this --efi-directory=*esp* in the wiki I’m never sure what they are referring to. They do this a lot assuming the user knows what they mean when they don’t. Such as using italics which is almost impossible to note the difference.

I just installed using sudo grub-install /dev/sdax and there were no issues. It has the endeavouros folder in /boot/efi/EFI/endeavouros

123

It should be something like:

--efi-directory=/boot/efi
124

But would it work if you used /boot/efi/EFI because the actual grubx64.efi file is in /boot/efi/EFI/endeavouros

Or does it actually create or know those other folders?

125

No, the /EFI part gets appended automatically, so in this case it would actually try to put it into /boot/efi/EFI/EFI/GRUB or something like that. I’m guessing, I could be wrong, didn’t check any of that :slight_smile:

126

That’s what i thought! Where does the endeavouros folder come from? Or would it not be there other than the fact that the eos installer calamares creates it on the install?

127

I haven’t the foggiest idea, sorry.

128

I think that’s where it comes from.

Edit: It’s good to know you can check what grub version is actually installed. Not just the package but the actual grub installation.

1 Like
129

This value becomes a folder.
As FAT32, names are case-insensitive.

1 Like
130

Yes i understand that would happen if used. I was only thinking in terms when using grub-install and i give it the target which is the efi partition sudo grub-install /dev/sda1

I’m not doing it the way it explains in the Arch wiki. When we had the first grub fiasco and they came up with the grub-install i thought that nothing else was needed but that’s not always the case. It doesn’t always work with just that. At least not for me. :wink:

131

It’s right at the top of the page:

Note: In the entire article esp denotes the mountpoint of the EFI system partition aka ESP.

132

The documentation about grub is vague and manual pages outdated.

AFAIK, grub-install on MBR systems need the partition parameter, like /dev/sdaX.

On UEFI system the partition parameter is not needed. Instead you need to use options like --bootloader-id and --efi-directory unless your system is using the defaults for those options.

On EndeavourOS (UEFI) installs Calamares sets endeavouros as the bootloader-id.

133

What documentation?
Archwiki article ?
Grub manual?

134

Archwiki seems the best of them. The man and info pages are severely outdated. Grub manual is also somewhat outdated, but fortunately has quite much relevant info, but unfortunately not all which I think should be there.

But take this just my personal opinion.

Generally many devs say the source code is the best documentation, but I don’t think it as a documentation at all, but just the implementation of a design (document if such exists).

1 Like
135

I may misunderstand this word.
Is it possible that a man page, package provided, could be outdated ? Post some content that is incorrect and might confuse users. We have to report upstream.

Grub Archwiki article is the best on the web.
Grub manual is continuesly updated, with the latest version/commit.

IMHO, saying that documentation is at a failed state, is an insult to the devs. I wouldn’t dare.

1 Like
136

Fortunately none of us did so. :wink:

And I know from experience that creating and maintaining documentation about software is not easy at all, and humbly admit I also should do a better job.

But I think this is a bit off-topic in this thread and would require another thread if we want to continue.

137

Having just last night tried to chase down some details of the mdraid1x grub module for an edge case, I agree that some design/overview would be good. Looking at the code seemed like it supported all mdraid 1.x devices, but I still don’t understand how having the grub root device == /boot file system would work if the md raid device wasn’t raid1. Possibly part of the embedded grub core has that smarts in it, but I failed chasing it thru the code.

And there is a huge different in utility of documentation for a familar dev, who just needs memory refreshed a bit, vs someone starting cold, and doesn’t really want to have to understand the whole thing, just need to have an understanding of how the parts fit together and find some of the fine detail that pertains to the issue at hand.

The question I was trying to answer was can the grub boot device be a raid0 stripe. Often it is raid1 mirror, so reading from one side is perfectly fine, but a stripe would require actually following the stripe. It seems like raid0 should work looking at the code, as it doesn’t reject 0/4/5/6 etc. But seeing grub rescue appear and requires manual intervention. Or it could just be a configuration error. So some overview addressing the supported md raid devices, and any constraints, would have been good, rather than this is the mdraid1x module.

138

Here’s an answer from the grub-devel mailing list:

This and [1] suggest problems with updating the GRUB modules.
The grub_is_shim_lock_enabled symbol is provided by the GRUB kernel.
If for some reason the GRUB kernel is downgraded but modules are not
then newer version of the linux.mod tries to call the function which
does not exist. Please double check Arch linux properly updates the GRUB
including the modules. In this case especially downgrades are prone to
errors.

Daniel

[1]
https://www.reddit.com/r/archlinux/comments/14rlz7x/comment/jqtoio9/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Full thread can be accessed here and more infos can be found at this reddit post. The problem is that I’m too dumb to understand what they’re saying :frowning:

1 Like
139

Not having read the link, however …

[deleted, inaccuracies, I didn’t really want to enumerate the entire PC boot process, and grubx64.efi build/install was more complex than I initially thought]

140

Thanks for the very detailed explanation, so if I understood that correctly, this shim_lock error should trigger because GRUB finds a mismatch between the kernel and it’s modules, but both should be recreated by running grub-install, so the error doesn’t make too much sense, at least to me.

I tried recreating both with the following

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=endeavouros

But got greeted by the same error about shim_lock.
I guess I could try adding --disable-shim-lock and see if it helps, but to me it sounds like either a packaging error or an issue with GRUB itself.

1 Like