Latest grub bricked my system (grub_is_shim_lock_enabled not found)

General system Newbie
141

This is only for compile time, for packagers.

It is both.
Neither grub, nor Arch packaging should let systems unbootable, because of one new variable introduction. Ask bashrc xinitrc devs how they do it.

When a commit breaks backward compatibility, a new major version is required.

WTF? Someone has to accept responsibility for this mess.

Is grub development falling apart because a random dev can publish commits without parenting?

Is Archlinux falling apart because there is no time to block an upstream bug, that will break several systems? Itā€™s not about a WM, or a DE, that we can live without, or with alternatives.

142

[deleted, inaccurate]

143

I appreciate the excitement and fruitful explanations with knowledge.
Nevertheless, grub is very well known actor. Iā€™d suggest a little walking before running :joy: . Archwiki for grub explains everything.

OTOH, the current issue is known. The problem is that Grub and Arch act like Gnome.

Itā€™s not a bug. Itā€™s a feature.

144

Having read a lot of archwiki entries over the years, it is often a useful tool. Sometimes it is very dated too.

145

Is this an excuse for not reading?
I donā€™t need a flame war here ubu<>arch and such. Ubuntu is not Arch, and vise versa.
If you respect communication, our common language is Archwiki, no random web blogs.

146

Iā€™m not after a flame war either. Iā€™m here looking around EOS because it was time to look away from ubuntu, no trying to say that is the one true way, far from it, just what I had with grub installed to test against. I just did the grub install on my EOS, and will be updating my posts with what EOS does.

This is the cut down grub-install -v from an EOS grub install.
grub-install effectively compiles a specific grubx64.efi for the current boot environment, the grub-install logs looks a lot like the old link loaders combining object files into an executable. This also means that the core.efi from /usr/lib/grub is only the source, not the final product that gets installed into /boot/efi.

You can see normal.mod, as a sample grub module, and grub-mkimage building the efi to be installed in /boot/efi, and leaving a copy in /boot/grub, so this should be compared to what is on /boot/efi I guess.

Note that I am using /efi, not /boot/efi, so different, and that Iā€™m using a ZFS root which isnā€™t a viable grub /boot directory, I would have to use a reparition to a separate /boot partition, which is one reason Iā€™m using systemd boot at the moment.

I hope this gives @chromiell a better idea of where to check the files to compare against. This is a vastly cut down log of the grub-install -v process. But note the references to shim_lock_verifier etc.

# grub-install -v --bootloader-id=grub --efi-directory=/efi /dev/sda > /tmp/grub.log 2>&1
Installing for x86_64-efi platform.
...
grub-install: info: copying `/usr/lib/grub/x86_64-efi/normal.mod' -> `/boot/grub/x86_64-efi/normal.mod'.
...
grub-install: info: grub-mkimage --directory '/usr/lib/grub/x86_64-efi' --prefix '(,gpt2)/ROOT/eos@/boot/grub' --output '/boot/grub/x86_64-efi/core.efi'  --dtb '' --sbat '' --format 'x86_64-efi' --compression 'auto'   'zfs' 'p
art_gpt' 
.
grub-install: info: the total module size is 0x16118.
...
grub-install: info: locating shim_lock_verifier at 0xf880 (0xf7c0).
grub-install: info: locating grub_shim_lock_verifier_setup at 0x6c30 (0x1000).
...
grub-install: info: locating grub_is_shim_lock_enabled at 0x6d08 (0x1000).
...
grub-install: info: reading /usr/lib/grub/x86_64-efi/kernel.img.
grub-install: info: reading /usr/lib/grub/x86_64-efi/gzio.mod.
grub-install: info: reading /usr/lib/grub/x86_64-efi/zfs.mod.
grub-install: info: reading /usr/lib/grub/x86_64-efi/part_gpt.mod.
grub-install: info: kernel_img=0x560c71614760, kernel_size=0x1c000.
grub-install: info: the core size is 0x32118.
grub-install: info: writing 0x35000 bytes.
...
grub-install: info: grub-mkimage --directory '/usr/lib/grub/x86_64-efi' --prefix '' --output '/boot/grub/x86_64-efi/grub.efi'  --dtb '' --sbat '' --format 'x86_64-efi' --compression 'auto'   'zfs' 'part_gpt' 
.
grub-install: info: the total module size is 0x16100.
...
grub-install: info: locating shim_lock_verifier at 0xf880 (0xf7c0).
grub-install: info: locating grub_shim_lock_verifier_setup at 0x6c30 (0x1000).
...
grub-install: info: locating grub_is_shim_lock_enabled at 0x6d08 (0x1000).
...
grub-install: info: reading /usr/lib/grub/x86_64-efi/kernel.img.
grub-install: info: reading /usr/lib/grub/x86_64-efi/gzio.mod.
grub-install: info: reading /usr/lib/grub/x86_64-efi/zfs.mod.
grub-install: info: reading /usr/lib/grub/x86_64-efi/part_gpt.mod.
grub-install: info: kernel_img=0x560c71614760, kernel_size=0x1c000.
grub-install: info: the core size is 0x32100.
grub-install: info: writing 0x35000 bytes.
grub-install: info: copying `/boot/grub/x86_64-efi/core.efi' -> `/efi/EFI/grub/grubx64.efi'.
...
grub-install: info: executing efibootmgr -b 0005 -B.
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,0004,0001,0003,0000
Boot0002* UEFI QEMU QEMU HARDDISK       PciRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/SCSI(1,0){auto_created_boot_option}
Boot0003* EFI Internal Shell    FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0004* Linux Boot Manager    HD(1,GPT,a9bcd511-8248-446a-ac6b-fdeb762bf4e8,0x800,0x200000)/File(\EFI\systemd\systemd-bootx64.efi)
...
grub-install: info: executing efibootmgr -c -d /dev/sda -p 1 -w -L grub -l \EFI\grub\grubx64.efi.
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0005,0002,0004,0001,0003,0000
Boot0002* UEFI QEMU QEMU HARDDISK       PciRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/SCSI(1,0){auto_created_boot_option}
Boot0003* EFI Internal Shell    FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0004* Linux Boot Manager    HD(1,GPT,a9bcd511-8248-446a-ac6b-fdeb762bf4e8,0x800,0x200000)/File(\EFI\systemd\systemd-bootx64.efi)
Boot0005* grub  HD(1,GPT,a9bcd511-8248-446a-ac6b-fdeb762bf4e8,0x800,0x200000)/File(\EFI\grub\grubx64.efi)
Installation finished. No error reported.

Looking the above, the symbol grub_is_shim_lock_enabled seems to be located.

$ cd /usr/lib/grub/x86_64-efi
$ for i in *mod kernel.img; do nm $i | sed 's/^/'$i'/'; done | grep shim
nm: all_video.mod: no symbols
linux.mod                 U grub_is_shim_lock_enabled
kernel.img0000000000005d08 T grub_is_shim_lock_enabled
kernel.img0000000000005c30 T grub_shim_lock_verifier_setup
kernel.img00000000000000c0 D shim_lock_verifier
$

So it seems linux.mod want grub_is_shim_lock_enabled, and kernel.img will provide grub_is_shim_lock_enabled. I tried to check /boot/grub/x86_64-efi, however the symbols are stripped so nm doesnā€™t help.

147

Usually when it reports this you need to select the proper boot drive from bios settings.

148 
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.

When you say you go the same error, so you mean the you got the error when you tried to do grub-install, or when you tried to boot? grub-install is probably much easier to track down.

I just did the grub install and I have the below, and grub-install completes OK for me.

# pacman -Q grub
grub 2:2.06.r591.g6425c12cd-1
# md5sum /usr/lib/grub/x86_64-efi/{linux.mod,kernel.img}
13385f16693144e83d8ea88bc968dc4a  /usr/lib/grub/x86_64-efi/linux.mod
b29fad5a219db3d769f04c38faa398ae  /usr/lib/grub/x86_64-efi/kernel.img
#
149

Set the boot drive to the one that sayā€™s endeavouros.

Edit: It changes the entry in nvram and isnā€™t booting from the proper path.

150

Sorry my bad, I didnā€™t specify. Grub-install logs that it finished successfully and that there were no errors to report, I meant the same:

error: symbol `grub_is_shim_lock_enabled` not found

while trying to boot into a kernel or a btrfs snapshot.

151

Thanks, but I have multiple installs running on that disk, and I just want a separate bootloader-id for the grub efi boot entry, while not breaking the endeavouros systemd boot setup.

Iā€™m just trying to see if the current grub will work as a boot loader, but my current installs are all ZFS root, and the ZFS pools have features the preclude grub boot.

1 Like
152

Well i donā€™t know much about zfs pools. :man_shrugging:

Edit: But this is what i meant. It changes the entry. Before it was listed as the UEFIOS and drive name.

MSI_SnapShot
MSI_SnapShot1024Ɨ768 135 KB

153

Does the btrfs snapshot have /boot on it? Because if that is inconsistent with the grubx64.efi that would explain it to some degree.

If you have the btrfs snapshot with /boot in it, then it should have /boot/grub/x84_64-efi/grubx64.efi in it, and that could probably used to create a new boot entry in /boot/efi/test, and then use efibootmgr to create the efi menu entry to boot it, if you want to go down that path.

I donā€™t know why your new version of grub isnā€™t working, I have to do some setup work on my disk before I can try that.

154

Thanks, I know enough, I just have to bludgeon it enough to make it work. Possibly rsync the root image to an ext4 parittion, then grub-mkconfig might work.

Changing the name should not matter, it is what the name refernences that matters, ie:

# efibootmgr |grep GPT
Boot0004* Linux Boot Manager	HD(1,GPT,a9bcd511-8248-446a-ac6b-fdeb762bf4e8,0x800,0x200000)/File(\EFI\systemd\systemd-bootx64.efi)
Boot0005* grub	HD(1,GPT,a9bcd511-8248-446a-ac6b-fdeb762bf4e8,0x800,0x200000)/File(\EFI\grub\grubx64.efi)

Both reference the same EFI boot partition, the enseavouros is a systemdboot setup, and the grub is the one I created for testing. I also have base device references like you too.

155

I only use grub and Iā€™m only pointing out the fact that this command is going to give you what i showed with the image. So it has to boot from that.

Edit: At least thatā€™s how it works on my board. :wink:

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

Yes, but that not the configuration I want. I just want test the current grub, and I want it to use grub as the bootloader-id. My problem at the momemt is grub-mkconfig and it not liking ZFS root, and not generating a boot entry for it, thus I was thinking of quickly rsyncing my zfs root to a temporary ext4 partition which grub-mkconfig should be happy about, rather than manually build a grub menu entry which would be more error prone for me.

Iā€™m just trying to understand the issue @chromiell is having.

1 Like
157

Iā€™ll have to check, but I donā€™t think that snapshots could cause these issues, at most theyā€™d be borked, but mainline and LTS kernels should still boot without errors. Iā€™ll probably get back to this tonight or tomorrow, I had to restore the system 8 times via chroot just in the last couple days. Every day I keep getting closer to saying ā€œfuck itā€ and switching to SystemD-boot tbh.

158

systemd boot is booting fine for me, but I want to get grub working anyway as that way I have better snapshot control for ZFS booting.

It is getting late here too, and I am going to give up for the night, and attack it in the morning.

Nothing says you have to only have systemd boot or only grub boot, they can co-exist, each with a separate folder in /boot/efi, you just have to arrange for the update hooks I guess, if it is non standard, or designate one of the your fallback setup and just update it occasionally.

159

i would not recommend to set a new ID in case the one used is different it will add a new entry.. if you do not use this option it will take name from /etc/default/grub

160

GRUB

in testing repo

grub 2:2.06.r591.g6425c12cd-1 ā†’ 2:2.12rc1-1

:ghost: