Latest grub bricked my system (grub_is_shim_lock_enabled not found)

General system Newbie
61

In some cases as in mine it booted with a shim lock error. It’s just that the wrong drive was being selected. I just had to switch the drive it needed to boot from in the UEFI settings. Even though it technically could be the right hard drive it is the path that the newly installed grub might change? :thinking: Mine had the drive listed but the other entry was endeavouros. This is the one it needed to boot from.

62

Here we go again… :face_with_head_bandage: and it is never a PEBCAC, but grub to blame.

Hopefully there will be a better conclusion after this is over.

1 Like
63

Try the latest commits here.

1 Like
64

Would be more helpful if you could be more explicit as to where and what things went wrong :wink:

65

https://git.savannah.gnu.org/cgit/grub.git/commit/?id=7082a5ca8abd79c1e8840c59759f53c4c80e286d

this one mentions shim lock

66

Not now, it’s hot.
You may look for my posts at the previous event topics.
If one line suits you,

Do not install grub to disk/efi after each grub package update. If it breaks, fix it.

67

Honestly i really don’t understand it because some people say they did this and others say to do it this way. Some have success or they think they do but actually maybe there wasn’t even a change. I know because the first commands i tried didn’t work. The ones that did show me that grub actually did install and after that i ran the grub update command. The one computer that gave me an a shimlock error later had somehow change the boot device priority.

68

If by this you mean using --no-nvram, that is what I did first and I ended up with the error.

1 Like
69

I had this on a laptop with only one disk. :thinking:

70

I had it on the desktop with 3 drives. Only single boot.

71 
efi: Drop __grub_efi_api attribute from shim_lock->verify() function
... because (surprisingly) it does not use specific EFI calling convention...

Fixes: 6a080b9cd (efi: Add calling convention annotation to all prototypes)

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>

image
image1134×504 57.6 KB

looks like this could have caused it?

72

It may be a combination of commits.
This introduces the new variable.

73

Looks like I misunderstood this!
So no more paying attention to

:: To use the new features provided in this GRUB update, it is recommended
   to install it to the MBR or UEFI. Due to potential configuration
   incompatibilities, it is advised to run both, installation and generation
   of configuration:
     $ grub-install ...

?

74

I’m still not sure what one is supposed to do if there is a new grub package. :man_shrugging:

Whats the point of a grub update package then if it doesn’t get applied?

3 Likes
75

Exactly! My thinking as well.

1 Like
76

I wasn’t able to resize my root partition with gparted probably because I had FDE on my disk, so I decided to reinstall since it’s not that much work since all my important files are on my nfs server. I’ve also noticed unlocking an encrypted filesystem is faster with systemd-boot compared to grub. From what I’ve seen so far from systemd-boot it looks like it’s easier to use as well.

77

Not every attitude is for everyone. It depends on several conditions. We have exhausted the discussion on this during the previous grub event.
Nevertheless, the more, the better :smiley: .

  • Grub is not an exclusive tool for EnOS, nor for Archlinux, not even for Linux only.
  • Each distro has a specific focus with regard to avoid broken systems without user intervention.
  • Those who have high priority on that rule, do exhaustive testing on system critical package changes (i.e. Debian).
  • Archlinux cares about security, but do not have the manpower to test packages exhaustively, like Debian can, who then nitpick security related commits and apply them to their frozen packages. That’s why they decided to follow grub master branch for best security, as it is assumed that their users are aware they must be able to fix a broken system because of an uncaught bug from their limited testing branch.
  • (sorry but…) EnOS, as well as other Arch-based distros, would like to achieve the unachievable target of avoid broken systems without user intervention. This case is one of them that they can’t completely control.
  • Why? Too many factors with possible bugs, since all of them are human designed program code ; thus, a bug is always possible!
  • Firmware is code. Too many HW models.
  • Grub (as well as systemd-boot) is code. Part of gub is early loaded (efi stub, or MBR), part is late loaded (grub.cfg).
  • Init system (systemd etc.) is code, as well as GPU drivers.
  • The possibility of a failed boot is the algorithmic result of the multiplication of all the above players (forgive my poor English and math :face_holding_back_tears: ).
  • On the grub topic, early grub must be able to communicate with late grub in the same language (code version). That’s why the optimal thing to do is to install (early) grub with every package upgrade and recreate (late) grub.cfg at the same time. But,
  • What if there is a bug? If you are on an Arch-based distro, you have a broken system. If there is a bug, the first users that will face it are those on Arch.
  • Can we (in Arch) avoid this with a workaround? Maybe. If we can find a method/behavior/procedure that keeps both grub parts in sync with each other, and at the same time avoid a partial upgrade (NoUpgrade=grub).
  • Arch devs decision to keep the same kernel name despite version is (coincidentally?) helping with this. Grub’s role (as a bootloader) is to run the kernel. Since the kernel file name is always the same before and after a grub upgrade, if grub parts (early and late) do not change, the result will normally always be the same as the previous one (unless it was broken before, it will be successful). This translates to Do not install grub to disk/efi after each grub package update and do not recreate grub.cfg. :tada: :partying_face:

It depends on what your system is used for and how critical it is for you.

  • If you can live with a small inconvenience (troubleshoot, chroot, repair), there is no problem.
  • If your system is mission-critical, then you should take (have taken) precautions (study Linux, train yourself on system administration, use another distro, apply backup plans, etc.)
  • The actual difficulty is the above-mentioned (sorry but…) EnOS, as well as other Arch-based distros, would like to achieve the unachievable target of avoid broken systems without user intervention. When/if you advertise that the distro is so smart and capable and user-friendly that you can run it even you cannot be your system’s System Administrator, then you get frustrated when just a bug disproves your promises.
  • On the question, if you want to update early and late grub, prepare yourself and do it. You can never know if the result will be successful (bug-free). Grub updates (when there are no bugs) are improving functionality, hardening security, or do nothing serious (code improvement, documentation improvement, improve things that do not affect your own HW and SW, etc.). Since updating bootloader components is always a risk, take your time, choose the time and place for the fight, and go for it. :gun: :person_fencing:

I hope, at least, this helps some readers understand my opinion. I am no know it all guy. I just know what I think I know. I may be wrong. Think for yourselves :man_shrugging: .

1 Like
78

I only had one that booted to

error: symbol `grub_is_shim_lock_enabled` not found

I had first tried just grub-install and sudo grub-install with no result. So that’s when i used sudo and gave it the path. Then it worked and i updated grub after. I did this on 5 different systems. Only the one that i had tried the command without the path did i have an issue as it later gave me the shim lock error. I just changed the drive in the UEFI settings for boot order and it was fine. It’s because it gave it the name endeavouros.

1 Like
79

So you did it! Congratulations :clap:
Now you will enjoy a wonderful EndeavourOS.
Just update as usual without worrying boot loader breaks.

It is much faster and safer. It is easier to manage.

Just curious, your machine is only EndeavourOS or you have other OS?

Just enjoy!

1 Like
80

I was already having great experience with EndeavourOS, Grub hadn’t broke yet :slight_smile:
I did have a look at how systemd-boot works and it seems simpler than Grub. I thought if so
many people are having issues with Grub and the default for EndeavourOS is now systemd-boot
might as well take the advise of those recommending it. Especially if it’s the default has been made systemd-boot by the Endeavour team and it can’t hurt to try something new. I do have to be honest though I’m not a systemd hater but I dislike the fact that so much is dependent on systemd now days.

I only run one OS on my system, EndeavourOS :sunglasses: I started with Linux around 2008 and been Linux only since around 2011-2012ish.