Again? … 
Edit: I feel like I’m getting grubbed!
I think there is either an informer from the forum, or grub devs are watching this topic.
It seems this version is just a release bump. I am too tired to calculate or imagine a plot.
Just the facts:
Grub version change (11 ==> 12)
-AC_INIT([GRUB],[2.11],[bug-grub@gnu.org])
+AC_INIT([GRUB],[2.12~rc1],[bug-grub@gnu.org])
Arch is at
(2:)2.06(.r566.g857af0e17-1)
Of course, it is a coincidence 
.
1 Like
It’s getting a little grubby of course!
That is an interesting version, as it matches the version I got when I did a pacman -Syu and pacman -S grub 12 hours or so ago, and I don’t have any explicit testing repos enabled. So maybe out of testing now, and into core? Which also means I don’t have the version that has been giving problems.
$ grep '^\[' /etc/pacman.conf
[options]
[zfs-linux-lts]
[zfs-linux]
[archzfs]
[endeavouros]
[core]
[extra]
$ pacman -Si grub | grep -E '^(Repo|Name|Vers|Build|Packager)'
Repository : core
Name : grub
Version : 2:2.06.r591.g6425c12cd-1
Packager : Tobias Powalowski <tpowa@archlinux.org>
Build Date : Tue 04 Jul 2023 15:08:15
Per the Aug 2022 release announcement, both grub commands should be run when grub is upgraded.
https://archlinux.org/news/grub-bootloader-upgrade-and-configuration-incompatibilities/
The Grub team hasn’t done a release in a while, and may not do a release for a while. Arch has been pulling a dev branch in motion.
Taking the bullet for the community (
) I went ahead and updated grub to the latest version in core-testing on two systems (Intel and AMD -based)
[2023-07-11T12:10:32+0200] [ALPM] upgraded grub (2:2.06.r591.g6425c12cd-1 -> 2:2.12rc1-1)
[2023-07-11T12:10:32+0200] [ALPM-SCRIPTLET] :: To use the new features provided in this GRUB update, it is recommended
[2023-07-11T12:10:32+0200] [ALPM-SCRIPTLET] $ grub-install ...
[2023-07-11T12:10:32+0200] [ALPM-SCRIPTLET] $ grub-mkconfig -o /boot/grub/grub.cfg
Followed the “official” recommendation in the terminal and did a
sudo grub-install --no-nvram ## which is what has worked for me; your mileage might vary
sudo grub-mkconfig -o /boot/grub/grub.cfg
No issues on my end.
Please, check for extra folders in your $ESP.
Extra folders?
None apart from the --boootloader-id=arch and a Bios folder which is from Bios updates.
$ tree /boot/efi
/boot/efi
├── $RECYCLE.BIN
│ └── desktop.ini
├── BIOS
│ ├── 20221011.0914574
│ │ ├── Win64.bat
│ │ └── WIN64.exe
│ ├── 20222906.05510975
│ │ ├── Win64.bat
│ │ └── WIN64.exe
│ ├── 20230505.21000668
│ │ ├── Win64.bat
│ │ └── WIN64.exe
│ └── 20230505.21073070
│ ├── Win64.bat
│ └── WIN64.exe
├── EFI
│ ├── arch
│ │ └── grubx64.efi
│ └── BOOT
│ └── BOOTX64.EFI
└── System Volume Information
I need vacations, or another distro!
It looks like it was not installed with calamares, or is the installer doing this now?
How was the bootloader installed from initial system installation?
Was this done manually? If this option is omitted, it defaults to Arch (or GRUB_DISTRIBUTOR).
Did you check file timestamp?
I don’t do Calamares 
However, I like the fried ones!
Yes.
No 
Edit:
$ stat /boot/efi/EFI/arch/grubx64.efi
File: /boot/efi/EFI/arch/grubx64.efi
Size: 139264 Blocks: 272 IO Block: 512 regular file
Device: 259,3 Inode: 42 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2023-06-04 02:00:00.000000000 +0200
Modify: 2023-07-10 23:28:24.000000000 +0200
Change: 2023-07-10 23:28:24.000000000 +0200
Birth: 2022-08-29 12:43:15.390000000 +0200
I just installed the new grub package doing it the pebcak way! 
sudo grub-install --no-nvram
[ricklinux@eos-plasma ~]$ stat /boot/efi/EFI/endeavouros/grubx64.efi
File: /boot/efi/EFI/endeavouros/grubx64.efi
Size: 286720 Blocks: 560 IO Block: 4096 regular file
Device: 259,2 Inode: 6 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2023-04-17 20:00:00.000000000 -0400
Modify: 2023-07-11 16:04:34.000000000 -0400
Change: 2023-07-11 16:04:34.000000000 -0400
Birth: 2023-03-09 15:52:28.420000000 -0500
Edit: Thanks to @Kresimir for these commands
[ricklinux@eos-plasma ~]$ grub-probe --version
grub-probe (GRUB) 2:2.12rc1-1
[ricklinux@eos-plasma ~]$ grub-install --version
grub-install (GRUB) 2:2.12rc1-1
It is my fate to spoil the excitement…
The --version option does nothing different than pacman -Q grub. It prints the program version, not for the installed bootloader.
Sorry @Kresimir , I can’t hold myself 
Well … you have spoiled the fun. 
Edit: I had just wanted to know how to tell if the current grub package that is on the system is the version that is updated? Or not?
How to check…how to confirm?
Edit: Just for the benefit of ALL grub users!
There is no unique answer, but you can start from the obvious.
- If you have just upgraded
grubpackage and then rangrub-installwithout errors, then both versions should be the same. It doesn’t hurt (if your grub PTSD orders you ) to check the efi file timestamp, in case there was a copy error, that was not reported as such bygrub-install. Unfortunately, you can’t check (with conventional utilities) the MBR, in case your system is MSDOS-Legacy. - It seems (as it was nicely explained by @samarium) that whenever you grub-install the grub bootloader, all contents (modules) under
/boot/grub/i386-pc/(x86_64, or relevant arch-name) are updated to the current grub version at the time. So, if those files are older than yourgrubpackage installation timestamp, it means your grub bootloader is not the same version as your grub package, either.efifile, or the MBR content/dump.
IMHO, we should stop looking for someone to blame, and get responsible with what we do.
- Professionals should have backup plans.
- Lazy or non-technically competent should choose Windows (C) or other OS. Archlinux is for a certain type of users, not for everyone.
- There are plenty of knowledgeable forum users that can support cases with boot issues, but this requires peace and calm people. Panic is not a good friend.
- It is also important for forum users to suggest things they really know, and not something that happened to have worked for them. A significant part of the panic from grub phenomenon, was created from non-experts that panicked and rushed to give invaluable or bad advice to the people in pain, creating a bigger mess.
I have no paper to support my above opinion. It may be completely wrong.
The fact is I’m not having any issues. Rarely do i have the issues that i see users having. I’m just trying to understand grub and the issues that i see because honestly i don’t understand it! I don’t have these issues installing whether it’s dual boot or not. I don’t have these issues when updating. I do have a good understanding of UEFI and how it works at least in my mind. I may not be able to explain it. But i understand a lot of things related such as partitioning and UEFI etc. But I’m not an expert nor do pretend to be. I lack a lot of linux knowledge … i just know bits and pieces.
I officially (and seriously) suggest you change the forum account name to:
LuckyRick.
Faster than his shadow, never fallen down the horse!
I keep a rabbits foot under my pillow and carry around a lucky charm. 
1 Like
do we have a solution at this time that you know?
I thought you had already solved it for your system. What is exactly the question?
If you only added grub to IgnorePkgs, this is temporary (of course).
In your 1st post, it looks like you are using snapshots during boot. If so, you should make sure you are not booting into a snapshot.
IMHO, if you manually update package, re-install bootloader and re-create grub.cfg, then the system should not break.
Breaking points are
- Booting into a snapshot by mistake (saved previous boot in grub)
- Improper command options with
grub-install - Booting to a different bootloader (
.efifile) from the one grub created last. (invoke UEFI Boot Menu, to see available options)
not booting into snapshots, the error appeared for every menu entry, be it lts kernel, zen kernel, snapshot, mainline.
i first downgraded with ignorepkg but now i updated grub without installing and mkconfigging it.
at some point i’ll have to though and was wondering if someone figured out why the symbol grub_is_shim_lock_enabled not found appeared.
guess I will have to risk it again to check it out