Recovering a Timeshift snapshot ends with: ERROR: Symbol grub_is_shim_lock_enabled

Support
1

My system:
Mainboard: ASrock B850M Pro-A
CPU: Ryzen 5 7600X (with iGPU)
RAM: DDR5 32 GB
no overclocking
AMI-BIOS, latest
Virtualization in BIOS: active and locked

OS: Linux 6.12.39-1-MANJARO (x86_64) on BTRFS
BTRFS parameters: defaults,noatime,space_cache=v2,compress=zstd:6 0 0

Yesterday I had finished some experiments with KVM/Qemu and then wanted to go back to VirtualBox. I could deinstall the KMV/Quemu components by Pamac. But there were so many packages, that I thought, it would be better, to use a Timeshift snapshot, to get the system back with VirtualBox already installed.

First I tried to recover by Grub, pressing Esc at boot time and then selecting the right snapshot. But strange, it did not boot into the snapshot. Instead I get the message:

ERROR: Failed to mount 'UUID=d89e1484-027......' on real root
You are now being dropped nto an emergency shell.
sh: can't access tty: job control turned off
[rootfs ~]#

I remembered, that I could do the recovery of snapshots within Timeshift itself. I rebooted successfully started Timeshift and did select the snapshot and pressed “proceed…”.
After a short while, I got the success message and I thought, I should reboot now so that the recovery would be finished.
But then I got:

ERROR: Symbol >grub_is_shim_lock_enabled< not found.
Press any key to proceed...

After some seconds, an additional message appeared:

The main definition as well as the alternative definitions could not be booted. (translated from German)
Press any key to proceed...

After waiting several seconds, the Grub bootloader menu appeared so that I could also choose snapshots again. But each try, to boot from such a snapshot will lead to the message above:

ERROR: Symbol >grub_is_shim_lock_enabled< not found.
Press any key to proceed...

After doing intensive web search, I have found this source:
https://bbs.archlinux.org/viewtopic.php?pid=2157953#p2157953

When I check the not starting system by a live-stick, and do su efibootmgr, I get two different ways to boot the system: One is EFI/BOOT/BOOTX64.EFI and the other is EFI/BOOT/Manjaro/grubx64.efi (or similar)
In the BIOS, both can be chosen as if it were two different Manjaro installations on the same drive. This is similar to that, what is discussed in the forum above.

It seems, that this could be a solution for my case too. But I don’t understand the single steps, I have to go. Their solution is, to completely clean the bootloader and efi and after that reinstall Grub again. But how to reinstall Grub on a system, which cannot be started up???

Further I don’t understand the single steps, for example, how I can get access to the different directories and partitions and what to do there in detail step by step.

I also have a solution in my mind:
As I am on a BTRFS system, I have several Timeshift snapshots available. At least the latest could be the source to get my system up and running again. As the snapshots do contain /boot/efi/ and grub configurations, it should be possible to gain the necessary files from there and insert them into the actual not booting system.

But I cannot do this because of lack of knowledge, which files should be copied and how get I access to these files and how get I access to the right locations in the not booting system.

What I could do myself, is done. Any help welcome!

2

If they are actual btrfs snapshots, then they do not contain the contents of /boot/efi, because that’s a mountpoint to the EFI system partition, which is vfat.

If instead they are rsync backups, then you cannot boot into them, because that only works with btrfs snapshots.

There are however several threads on the forum already regarding the shim_lock issue with grub. Perhaps you will find an answer in one of the threads here.

3

This might be attributable to a mismatch of EFI/BOOT/Bootx64.efi and EFI/Manjaro/grubx64.efi - despite the differing file names, they should nonetheless be binary identical.

It’s possible that install-grub performed from a chroot environment might solve that, by replacing both copies (and grub at the same time).

One would need to boot from the Manjaro Installer, and enter a chroot environment from there; the link in your following post should provide sufficient instruction.

Regards.

4

I have already read this discussion here:
https://forum.manjaro.org/t/grub-is-shim-lock-enabled-not-found/159220
but the guy who looked for help, was able to boot into one of the two efi-boot-options and then could reinstall Grub with pacman.

The other source, I already had discovered is:

The user cites some code, how to proceed for reinstalling Grub. But it is not clear, that this would really work. He shares this proposal:

# mount the btrfs root subvolume
mount /dev/sda1 /mnt -o subvol=/
 
# (optional) set the default subvolume
btrfs sub set @ /mnt
 
mount /proc /mnt/proc --bind
mount /dev /mnt/dev --bind
mount /sys /mnt/sys --bind
 
chroot /mnt
 
grub-install /dev/sda
update-grub /dev/sda
 
# activate first partition
fdisk -l /dev/sda

And they refer to a wiki article which should be found here:
https://wiki.manjaro.org/index.php/GRUB/Restore_the_GRUB_Bootloader

but actually this website is down.

I also had found this source here:
https://bbs.archlinux.org/viewtopic.php?pid=2157953#p2157953

Someone describes a solution which could work for me also, but my knowledge is too limited and I cannot go the single steps, he has done.

At the end, there are too many questions unanswered, so that I am scared to try something which would perhaps ruin my system finally.

Oh I would like to mention:

  • disabled TPM
  • disabled CPM
  • disabled secure boot
  • List item
5

Yes, the Wiki is down.
The issue has been passed on to the maintainer.

1 Like
6

This (:point_up:) is for an MBR install and a legacy BIOS boot. It’s not the correct procedure for a UEFI boot and GPT.

There is a disk space problem with the Manjaro Wiki right now. The person administrating the server has been notified, but I don’t know whether he’s online right now, and if so, whether he has seen the ping.

7

@Aragorn Thank you for your advice. Of course I am on GPT. Mostly the success of a search depends on the right phrase for doing the search. Now I looked for “doing a grub reinstall on a non booting system” and I got an answer from AI:

To reinstall GRUB on a non-booting Manjaro system, you will need to use a
Manjaro installation media (USB or DVD) to boot into a live environment.
Once booted, follow these steps:

Open a terminal and switch to the root user context using su.

Identify your system partitions using tools like
lsblk -o PATH,PTTYPE,PARTTYPE,FSTYPE,PARTTYPENAME or
sudo fdisk -l /dev/sda

to locate your root (/), boot (/boot), and EFI system partition (/boot/efi).

Create a chroot environment to access your installed system.

You can use the manjaro-chroot -a command, which automatically detects and
mounts your Manjaro installation.

If this is not available or you prefer manual control, mount your root partition
to /mnt, your boot partition (if separate) to /mnt/boot, and your EFI partition
to /mnt/boot/efi.

Enter the chroot environment by running manjaro-chroot /mnt /bin/bash.

Reinstall GRUB:
For a UEFI system, run:
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck.

For a BIOS system, run:
grub-install --force --target=i386-pc --recheck --boot-directory=/boot /dev/sdX
(replace sdX with your disk, e.g., sda).

Update the GRUB configuration by running
grub-mkconfig -o /boot/grub/grub.cfg.

Exit the chroot environment with exit.

Reboot your system to test the restored GRUB bootloader.

If Windows was recently installed and is now the only boot option, running update-grub
(or grub-mkconfig) after reinstalling GRUB often resolves the issue by detecting the
Windows bootloader.

And I have found another one here on Github:
https://gist.github.com/dianjuar/a6e0d801a9f71f8edc06321178390320

These are the steps that worked for me, without having to install any new packages:

Boot into Manjaro installer

Open terminal

sudo manjaro-chroot -a (and select system to mount)

grub-install /dev/sda (it’s sda for me; make sure you choose the right drive!)

grub-install --recheck /dev/sda

update-grub

exit

reboot

manjaro-chroot is an AUR package which has to be installed on the live-system before.

Do you have any concerns about the solutions, I have cited above?
If not, I will have to choose, how to proceed.

8

Again, I’ll draw your attention to THIS mentioned in my previous post (scroll up) which may lead to a cure. Cheers.

9

This is again for legacy BIOS boot.

No, it is in the ISO which you put on the USB stick or optical medium.

I would advise installing install-grub in your system — not to be confused with grub-install. It’s a script that will make sure grub is properly installed on the EFI system partition.

10

One need to understand the relationship between the grub efi-loader and the grub.cfg

Despite the important connection between the two - they exist on two separate filesystems.

The grub config is found in /boot/grub/grub.cfg

And the efi-stub is located on a separate filesystem mounted at /boot/efi

  • EFI/Manjaro/grubx64.efi
  • EFI/BOOT/BOOTX64.EFI

When you restore from a timeshift backup you may be restoring a grub.cfg which is not matching the efi loader.

This will create issues, where grub_shim_lock message is just one of them.

As already mentioned above the two loaders - despite the different names must be binary identical.

See the → [root tip] [recovery] Basic Manjaro Linux Recovery

When you have established a chroot - run the install-grub script - a Manjaro specific tool - designed to ensure correct function.

install-grub
1 Like
11

Sorry but I am feeling really helpless and somehow overwhelmed by all this. I have understood, that there are two loaders and they must match in order that booting is possible.

Actually I have problems with chroot:
I am on the life-system. when I do chroot -a I will get chroot: invalid option -- 'a'.
When I type manjaro-chroot -a I get:
grub-probe: error: cannot find a GRUB drive for /dev/sdg1. Check your device.map

Of course /dev/sdg1 is the live stick and it has no boot partition.

When I type manjaro-root /dev/nvme1n1p1 which is the root partition on my btrfs system, I get:
Can't create chroot on non-directory /dev/nvme1n1p2

So I am stuck in very basic things. Then I followed the hint from @linux-aarhus and discovered:
Because - at time of writing [date=2025-03-08 timezone="Europe/Copenhagen"] - manjaro-chroot and the --automount option does not support *btrfs* .

OK, so I have to proceed with chroot.
My not booting system is located on nvme1n1.
Root is on nvme1n1p1
boot is on nvme1n1p2 and there is linux-swap.

I have found out by using gparted on the live stick. Then I saw, that the boot partition had a black i for Info on it, telling, that this partition cannot be read because of fat32.
Then I discovered by right click on this partition, that there is a “check function” in gparted. I activated it and let it perform. Then the “i” disappeared and it has the lock symbol just like it shows up on the root partition.

Then I try to follow the good advices here: https://forum.manjaro.org/t/root-tip-recovery-basic-manjaro-linux-recovery/175302#p-761121-btrfs-filesystem-19 which were new to me.

Next I wanted to mount the subvolumes of my system using:
mount -t btrfs -o subvol=@ $root /mnt but then I get:
mount: /mnt: can't find in /etc/fstab

But it seems, that I first have to mount the partitions and subvolumes of the non booting system and after that I should use chroot! – Do you see my lack of knowledge?

The help in the above mentioned source is really good, but inspite I cannot follow the instructions there. Some additional help is necessary and I have no friends who I could ask.

12

You first have to mount that partition. In the live USB environment, issue the following commands… :point_down:

sudo -i
mount -t btrfs -o subvol=@ /dev/nvme1n1p1 /mnt
manjaro-chroot /mnt

This should normally take care of mounting everything needed — /dev, /sys, /proc, /boot/efi, /home, et al.

13

Just had a break in my internet connection again. So my post crossed yours @Aragorn

After I made the check of the efi partition in GParted as I described in the pervious post, I just have tried to reboot this system, hoping, the problems could eventually be solved.

But now a really damage must have occured because the BIOS does not recognize any bootable device!!!

After all these days I have invested in this system, I hope this cannot be the end – so that I have to begin again to install and setup all this stuff!!

14

Not even the USB stick? :astonished:

15

Yes the Bootstick is recognized. I just try to follow your latest hints. Thank you for your patience with me! You can be sure, I do the very best, to get rid of the Problems.

16

Okay, that’s good.

After chroot’ing, run the command… :point_down:

grub-install --recheck && grub-install --recheck --removable
update-grub
17

Sorry but now it seems, that the complete device nvme1n1 is corrupt. I just booted with Live-Stick and This is what I got:

sudo -i                         
[manjaro ~]# mount -t btrfs -o subvol=@ /dev/nvme1n1p1 /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/nvme1n1p1, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.

Then I tried dmesg:

[    5.669027] EXT4-fs (nvme1n1p1): orphan cleanup on readonly fs
[    5.669253] EXT4-fs (nvme1n1p1): mounted filesystem af158780-691a-4ed8-a59d-1faee064e5e3 ro with ordered data mode. Quota mode: none.
[    5.669995] EXT4-fs (nvme1n1p1): unmounting filesystem af158780-691a-4ed8-a59d-1faee064e5e3.

That’s crazy because it is definitiv btrfs!
Then I tried lsblk:

lsblk
nvme1n1     259:0    0 465,8G  0 disk 
└─nvme1n1p1 259:1    0 465,8G  0 part

When I look at the nvme1n1 by Thunar, I see the content of root with
@
@home
@log
timeshift-btrfs

and all content of the folders and subvolumes is visible. In case, I have to really install all that stuff again, I have one little plus: I had this system setup to a second “home”, where all the configuration data of the software is contained, so that this would save some work.

I am just copying all this stuff from /home/user to a separate disk.

In this situation, do you think, that it is better to do a complete reinstall and not try to get it up again?

18

Well, to be honest, I have no idea what’s going on there anymore. :astonished:

Your dmesg output says that it’s ext4, but this may be a result of having the “fsck” hook in /etc/mkinitcpio.conf. That hook is not needed with btrfs, and in fact, fsck is intended for conventional filesystems, not for btrfs. It may actually do more harm than good.

I don’t think this will be part of the main problem, but it is most likely a separate problem in its own right.

As I told you earlier, the configuration data should remain where it is — there are too many competing standards between applications and system components on account of which directories and/or files it must be stored in — and only your actual documents (et al) may be put on a different volume, if that is what you want to do. But even that is not necessary, as long as you make backups on a separate storage medium.

For now, try removing the “fsck” hook from the “HOOKS=( ...” line in /etc/mkinitcpio.conf and rebuilding the initramfs, like so… :point_down:

mkinitcpio -P && update-grub
19

fsck is commented out in the /etc/mkinitcpio.conf

Then I did the update-grub and this is, what I have got:

[manjaro ~]# mkinitcpio -P && update-grub
==> Building image from preset: /etc/mkinitcpio.d/linux612.preset: 'default'
==> Using default configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-6.12-x86_64 -g /boot/initramfs-6.12-x86_64.img
==> Starting build: '6.12.37-1-MANJARO'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
==> WARNING: cannot detect type of overlayfs root filesystem
  -> Running build hook: [microcode]
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
==> WARNING: consolefont: no font found in configuration
  -> Running build hook: [block]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-6.12-x86_64.img'
  -> Early uncompressed CPIO image generation successful
==> Initcpio image generation successful
==> Running post hooks
  -> Running post hook: [sbctl]
Secureboot key directory doesn't exist, not signing!
==> Post processing done
==> Building image from preset: /etc/mkinitcpio.d/linux612.preset: 'fallback'
==> Using default configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-6.12-x86_64 -g /boot/initramfs-6.12-x86_64-fallback.img -S autodetect
==> Starting build: '6.12.37-1-MANJARO'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [microcode]
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
==> WARNING: Possibly missing firmware for module: 'ast'
  -> Running build hook: [keyboard]
==> WARNING: Possibly missing firmware for module: 'xhci_pci_renesas'
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
==> WARNING: consolefont: no font found in configuration
  -> Running build hook: [block]
==> WARNING: Possibly missing firmware for module: 'aic94xx'
==> WARNING: Possibly missing firmware for module: 'bfa'
==> WARNING: Possibly missing firmware for module: 'qed'
==> WARNING: Possibly missing firmware for module: 'qla1280'
==> WARNING: Possibly missing firmware for module: 'qla2xxx'
==> WARNING: Possibly missing firmware for module: 'wd719x'
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-6.12-x86_64-fallback.img'
  -> Early uncompressed CPIO image generation successful
==> Initcpio image generation successful
==> Running post hooks
  -> Running post hook: [sbctl]
Secureboot key directory doesn't exist, not signing!
==> Post processing done
/usr/bin/grub-probe: error: failed to get canonical path of `overlay'.

I am sorry, I have mixed up my two nvme devices:
The Manjaro installation is on nvme0n1. I just checked it with lsblk:

nvme0n1p1 = root
nvme0n1p2 = boot
nvme0n1p3 = linux-swap

But it is strange, that the nvme0n1 device was not detected as a boot device by the BIOS and formerly it did

20

Apparently not, because… :point_down:

As you can see, the hook is still active. :point_up:

I already suspected something like that, but of course, I can only go by the information you provide. :wink:

That is usually the result of either a UEFI firmware update — which resets everything to factory defaults and wipes out the EFI variables — or in the event of a system that dual-boots with MS-Windows, a Windows update, which does similarly hideous things.