Get a black screen with “Error: grub_is_using_legacy_shim_lock_protocol not found"

Support System Updates
,
1

After upgrade I rebooted. Grub boot menu loads fine, but when I select Manjaro from the menu I get a black screen with “Error: grub_is_using_legacy_shim_lock_protocol not found".

I assume this is because of my recent enabling of secure boot (had to do it to play the new Battlefield lol, it’s been nothing but a headache).

I enabled secure boot by following this article on the Arch Wiki (Section 3.1.4 with sbutil).

Not really sure where to go from here. Do I just disable secure boot and restart the process of signing everything again?

1 Like
2

Seems there was a useful warning posted in the testing branch that should have been brought across to stable as well…

Continuing the discussion from [Testing Update] 2025-07-30 - QEmu, Firefox Beta, Tuxedo Drivers, Slimbook Service:

3 Likes
3

I think I’m really hooped now - I disabled secure boot, booted into my install usb. Mounted my system and efi partition. I ran manjaro-chroot /mnt and attempted to reinstall grub like so:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Manjaro --recheck --disable-shim-lock and grub-mkconfig -o /boot/grub/grub.cfg. Reboot and same thing: grub_is_using_legacy_shim_lock_protocol not found.

4

Try install-grub instead.

The shim lock problem is caused by the fact that /boot/efi/EFI/bootx64.efi and /boot/efi/EFI/manjaro/grubx64.efi are different from one another. install-grub is a script meant to synchronize the two files, so that they will be identical again. It comes with a pacman hook too, so that it automatically runs after an update.

2 Likes
5

Shoot. Probably should’ve waited for a response to my first message before messing around. “Grub is not properly installed, system may not be bootable or other bootloader is used”.

6

chrootinto your installed system, install install-grub (if you don’t have it already), and run the script. :point_down:

sudo -i
manjaro-chroot -a
pacman -S install-grub
install-grub
3 Likes
7

Thanks for your help with this.

manjaro-chroot -a doesn’t seem to work (No Linux partitions detected) but if I do mount -o subvol=@ /dev/nvme0n1p2 /mnt and mount /dev/nvme0n1p1 /mnt/boot/efi I can use manjaro-chroot /mnt. Unfortunately, installing and running install-grub gives me the same thing: WARNING: Grub is not properly installed, system may not be bootable or other bootloader is used.

Anything else I can try?

8

Well, I submitted a patch somewhere around the middle of June for getting manjaro-chroot to work with btrfs root filesystems, but I guess it hasn’t been merged yet, and unfortunately, there is only one person who can do that. :man_shrugging:

Well, one thing… From with the chroot environment, update grub as follows… :point_down:

grub-install --recheck --removable
update-grub

If that doesn’t work either, then I’m afraid I don’t know what other advice I could give you. The thing is that Secure Boot is not supported by Manjaro, even though there are documented ways — at the Arch Wiki — to enable support for it. :man_shrugging:

1 Like
9

Damn. The grub re-install doesn’t work. This secure boot ■■■■ has been nothing but a pain in the ass, It’s a real shame the games I want to play require it now. Oh well.

I’ve disabled secure boot completely, I’m trying to just get a workable system at this point but no dice. Next step is going nuclear and re-installing everything lol.

Seriously though, thanks for being so responsive. You rock.

1 Like
10

Well, only a week ago, a bunch of early teenage girls wanted me to put my autograph on their forearms — I’m not kidding! — but I would have felt better if I had been able to help you out. :face_with_diagonal_mouth:

2 Likes
11

Small update, got the install-grub package to run. Same thing sadly. Backed up my home folder and will now re-install. Thanks again for the help

1 Like
12

@average You may want to check this post: [Unstable Update] July 2025 - #31 by linux-aarhus

1 Like
13

Had the same issue today. All I had to do to fix it was boot into the live ISO, execute manjaro-chroot -a, install-grub and reboot.

6 Likes
14

This issue bit me last night after updating.
install-grub solved the shim warning and allowed booting as normal.

Since this post appeared when I looked for the solution I’ll add this for when I or any other luks user next needs it.
manjaro-chroot -a selects my non-luks install so manually running luksOpen is needed.

key point, remember to actually manually mount /boot as well or get the
“grub-install: error: /boot/EFI doesn’t look like an EFI partition” headache at 2am.

1 Like
15

… had at least provided system information others might have been more easily able to identify the file system used…

Please provide inxi output as described (below) - even if only from Manjaro Installer live environment’s terminal.

Regards.

System Information

Output of the inxi command with appropriate parameters will achieve this (naturally, formatted according to forum guidelines) and will generally be more useful for those wishing to help:

inxi --filter --verbosity=8

or the short form:

inxi -zv8
16

I had the same issue today. I’m using LUKS encryption, the following steps fixed it for me:

  1. Boot into Manjaro with USB stick (Live)
  2. Open my encrypted SSD system partition (in my case 2nd partition on drive): sudo cryptsetup luksOpen /dev/nvme0n1p2 root (you may have to set the keyboard to EN-US when typing the unlock password)
  3. Mount it: sudo mount /dev/mapper/root /mnt
  4. Create mount point for my boot/EFI partition: sudo mkdir -p /mnt/boot/efi
  5. Mount the boot partition (in my case 1st partition on drive): sudo mount /dev/nvme0n1p1 /mnt/boot/efi
  6. “Login” with manjaro-chroot: sudo manjaro-chroot /mnt
  7. Install grub: install grub (no sudo needed)
  8. Exit: exit
  9. Unmount everything: sudo umount -R /mnt
  10. Reboot
1 Like
17

… just some nitpicking - not at all meant as mean spirited objections:

If you select the correct language and keyboard layout when booting the ISO, that should not be an issue.
But it is worth keeping in mind when you have trouble opening the encrypted container with your password on a not matching keyboard layout.

Not necessary - that directory (/boot/efi) already exists in the file system root

That is also not necessary.
Just reboot after you have exited the chroot environment.

Cheers! :wave:

18

Had the same issue, was able to fix it with the following steps while booting from a live usb stick. Thanks everyone.
(I’m running btrfs & luks encryption)

# find the drive
sudo fdisk -l
#> ...
#> Device              Start        End    Sectors  Size Type
#> /dev/nvme0n1p1       4096     618495     614400  300M EFI System
#> /dev/nvme0n1p2     618496 7674682351 7674063856  3,6T Linux filesystem
#> /dev/nvme0n1p3 7674682352 7814037101  139354750 66,4G Linux filesystem
#> ...

# decrypt/open the /root partition (in my case that's the largest one. The other is swap)
sudo cryptsetup luksOpen /dev/nvme0n1p2 root

# mount the root partition in /mnt. The -o subvol=@ is necessary for btrfs
# for ext4 you would just use mount /dev/mapper/root /mnt/
mount -o subvol=@ /dev/mapper/root /mnt/

# verify that you mounted the right thing (you should see the contents of your root directory, including a boot folder
ls /mnt 

# mount the boot partition and fix grub
mount /dev/nvme0n1p1 /mnt/boot/efi/
manjaro-chroot /mnt/
/bin/install-grub 

# reboot
2 Likes
19

… just “open” instead of “luksOpen” will also do the job

… you do know that the word you use as the last in this command (“root” here) is totally arbitrary - you can choose whatever word you want?
If you didn’t - now you do :nerd_face:

It’s what the /dev/mapper/... will be named.
It’s just a name tag.

This command won’t work from within chroot.
But you didn’t say it would - you just meant to say:
… when done, reboot … :nerd_face:

It’s probably playing it a bit safer when you first exit the chroot environment before you reboot.

20

You saved my life, thank you.

3 Likes