Latest grub bricked my system (grub_is_shim_lock_enabled not found)

This is another pro.

I -personally speaking- have 2 rules of thumb:

  • better follow the defaults
  • I trust what EndeavourOS developers recommend

I have read many websites… etc, people saying no to systemd in general, what I could conclude why no, is that it almost does everything or controls everything, it is “complicated”… etc. So, I have tried some non systemd like Artix which is arch based, honestly it was nice but had some flaws (I had to work out some way to get my WiFi working, then to work out its very low speed…) till came a day there was an update it didn’t boot after doing it. So, for me it is over (this was even before the Grub issue was initially “introduced”)

But reading further I could simply conclude though all the “cons” about systemd, I see systemd as a new technology, as any new technology it is for sure a bit complicated than the “normal”, think the old gasoline lamp, then the electric lamp, then the neon lamp, then the led lamp. So, my personal point of view it systemd is like the computer that monitors and controls everything in your car. What’s wrong with the computer doing this.

Furthermore it became like the “default” for many Linux distros. For sure the developers are not that stupid to default to systemd.
So, I finally decided to forget about the pros and cons of systemd and just chose what really works.

One final thought, why would I consider even a 1950s Mercedes better than todays Mercedes because it was “simpler” and has no computer to manage every thing, and even another “pro” for the 1950s Mercedes, it was the driver who does the transmission manually with his own hand and leg not automatic and the computer and gearbox doing it for him!

Same here, on Linux since 2000, on Linux only since 2003 (other than at work where they still think Linux is “difficult” and it does not have Internet Explorer, MS Office… etc. They and many people still think this way, they did not think just Internet Browser, Office app.)

I still wonder how Micro$oft is still existing and selling while there is Linux!

1 Like

No problems here. I updated yesterday, didn’t even realise there was a GRUB update. Today ran grub-install & grub-mkconfig and rebooted. Everything is fine. :fire: :dog: :fire:

I always keep a USB with an ISO image tied to my PC’s power cable, just in case. :rofl:

That’s the problem with Artix. Arch runs soystemd, everything on Arch is packaged with that in mind. Artix tries to repackage everything that depends on soystemd, and they do a pretty good job, but it is still a pretty brutal hack. On top of that, it has the same problems with the AUR as Manjaro. So, it’s far from ideal.

If you want a good non-soystemd distro, try Void Linux, it’s wonderful (though slightly more advanced than Arch). It a distro that is not based on any other. Software availability on Void is not as great as on Arch, though.

The downside of making so much dependent on systemd is there is that it makes software less compatible with other Unix-like oses, for example BSD. Enough about that though, will just see how sytemd-boot gets a long.

1 Like

Also on some of my machines I experienced bsod while trying to boot W11 after systemd-boot installation. I don’t know the root cause but I feel systemd-boot or its calamres installation process somehow affects on windows boot files, while I’ve never experienced bsod using GRUB. However, GRUB has its own charms on the other hand :wink:

Anyone got this working? I put IgnorePkg = grub to pacman.conf

I found these on Arch Forums, but I haven’t tried them yet
mount /dev/nvme0n1p1 /boot
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB

That won’t update the package, why wouldn’t that work?

I wouldn’t do that unless you know what you are doing. You cant just go mounting partitions and installing grub without knowing how your system is built up.

EnOS mounts, by default, the ESP at /boot/efi.

1 Like

still haven’t seen any announcement or solution around. just added grub to ignorepkg too.

It works. I have complete working system here. But I have to update grub someday, don’t I? Just trying to understand this, sorry I’m not native english speaker.

I got this grub problem too on my old Antergos install.

The solution in this case was using command grub-install with option --bootloader-id with the correct value: antergos_grub

The install has the bootloader id as a subfolder in /boot/efi/EFI.
So the id name had to be correct, otherwise grub-install used the wrong id and the system didn’t boot.

Hope this helps in similar cases. :sweat_smile:

2 Likes

what are you referring to exactly?

it looks like the grub_is_shim_lock_enabled is a very recently introduced variable (days ago) as shown in the previous posts linking to the git commits

here

Yes, this is the issue I encountered. Typically I update this Antergos system regularly, usually many times a week.
Antergos is an Arch based system although its devs ended the maintenance 4 years ago. But I don’t need a reinstall, it just works like Arch based systems do.

when did you update and see this message on the antergos? this week?

Wait, I have to check…

I updated system including the grub package yesterday, grub from r566 to grub r591. After that system didn’t boot.
I fixed this with option --bootloader-id.

Previous system update (grub r566) was 1st of July, and the system worked with this version.

I tried with the following commands:

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=endeavouros
sudo grub-mkconfig -o /boot/grub/grub.cfg

But no luck, had the same shim_lock error and had to resort to chrooting and restoring the previous version of GRUB via downgrade.
I noticed that i have the following situation in my /boot/efi/EFI directory:

ls -al /boot/efi/EFI               
total 16
drwxr-xr-x 4 root root 4096  5 dic  2022 .
drwxr-xr-x 3 root root 4096  1 gen  1970 ..
drwxr-xr-x 2 root root 4096  5 dic  2022 boot
drwxr-xr-x 2 root root 4096  5 dic  2022 endeavouros

Idk if having 2 folders in there is good or not tbh.

Some points to check:

  • What’s the version of the grub package installed in the system? You need to arch-chroot into it if unknown.
  • Can you show the output of ls -la /boot/efi/EFI/endeavouros?
  • What’s the output of command efibootmgr?

It shouldn’t matter if you have some more folders in /boot/efi/EFI.

  • What’s the version of the grub package installed in the system? You need to arch-chroot into it if unknown.
pacman -Qi grub | grep -i version
Version         : 2:2.06.r566.g857af0e17-1

the newer version I’m trying to install is this one:

pacman -Ss grub                  
core/grub 2:2.06.r591.g6425c12cd-1 [installed: 2:2.06.r566.g857af0e17-1]
    GNU GRand Unified Bootloader (2)
  • Can you show the output of ls -la /boot/efi/EFI/endeavouros?

Sure, here’s both endeavouros and boot:

┌──(chromiell🔒endeavour-laptop)-[~]
└─$ ls -la /boot/efi/EFI/endeavouros                             
total 360
drwxr-xr-x 2 root root   4096  5 dic  2022 .
drwxr-xr-x 4 root root   4096  5 dic  2022 ..
-rwxr-xr-x 1 root root 360448  7 lug 14.57 grubx64.efi
                                                                                                       
┌──(chromiell🔒endeavour-laptop)-[~]
└─$ ls -la /boot/efi/EFI/boot            
total 376
drwxr-xr-x 2 root root   4096  5 dic  2022 .
drwxr-xr-x 4 root root   4096  5 dic  2022 ..
-rwxr-xr-x 1 root root 376832  5 dic  2022 bootx64.efi
  • What’s the output of command efibootmgr?
┌──(chromiell🔒endeavour-laptop)-[~]
└─$ efibootmgr
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0001,2001,2002,2003
Boot0000* HDD0: HFM512GD3JX016N	PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/NVMe(0x1,AC-E4-2E-00-1A-31-11-D4)/HD(1,GPT,3fe1f943-c9cf-a244-83df-d58dfb1c5ff8,0x1000,0x96000)RC
Boot0001* endeavouros	HD(1,GPT,3fe1f943-c9cf-a244-83df-d58dfb1c5ff8,0x1000,0x96000)/File(\EFI\endeavouros\grubx64.efi)
Boot2001* EFI USB Device	RC
Boot2002* EFI DVD/CDROM	RC
Boot2003* EFI Network	RC

I might also add that I’m using BTRFS, LUKS encryption for root and swap and i currently have grub-btrfs package to boot into a snapshot.

Here’s my partition setup, but I don’t think it should make any difference :frowning:

┌──(chromiell🔒endeavour-laptop)-[~]
└─$ lsblk -f                 
NAME                 FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1                                                                                     
├─nvme0n1p1          vfat   FAT32       7A37-5497                             298,7M     0% /boot/efi
├─nvme0n1p2          crypto 1           2f9f5668-7b60-4b4e-9e93-3df9e311e38b                
│ └─luks-2f9f5668-7b60-4b4e-9e93-3df9e311e38b
│                    btrfs              edffef8f-c285-454d-9889-cb03930f2102  143,2G    69% /var/log
│                                                                                           /var/cache
│                                                                                           /home
│                                                                                           /
└─nvme0n1p3          crypto 1           8c9f6a9d-6937-46c2-99d7-704ca94368f5                
  └─luks-8c9f6a9d-6937-46c2-99d7-704ca94368f5
                     swap   1     swap  9135661b-2817-48f3-97a7-ed1e7ebbefb7                [SWAP]

EDIT: Forgot to mention, this is the situation after I already downgraded to the previous version, did you mean to run these commands after I upgraded to the newer version of GRUB?

/boot/efi/Efi/boot is the fallback bootpath. If I’ve got it it right , that is where the UEFI firmware will be looking if there is no other boot EFI entry in NVRAM or if the “main” entry fails to boot.

15 posts were split to a new topic: Remove unknown boot entries found after updating grub

What are you trying to accomplish with that?