Right, but that was after the change so you would have already had the new file. Nothing has changed since then.
So I also ran into the GRUB update issue and tried to solve it via chroot. Just that it did not work for me and I strongly suspect it is because my encrypted setup (which uses the default EOS installation parameters) makes things more complicated.
I did the following steps:
[liveuser@eos-2022.08.28 ~]$ lsblk -l
loop0 7:0 0 1.6G 1 loop /run/archiso/airootfs
sda 8:0 1 57.7G 0 disk
sda1 8:1 1 1.7G 0 part /run/archiso/bootmnt
sda2 8:2 1 105M 0 part
nvme0n1 259:0 0 953.9G 0 disk
nvme0n1p1 259:1 0 300M 0 part
nvme0n1p2 259:2 0 919.7G 0 part
nvme0n1p3 259:3 0 33.9G 0 part
[root@EndeavourOS liveuser]# cryptsetup open /dev/nvme0n1p2 2
Enter passphrase for /dev/nvme0n1p2:
[root@EndeavourOS liveuser]# mount /dev/mapper/2 /mnt/
[root@EndeavourOS liveuser]# ls /mnt/
@ @cache @home @log timeshift-btrfs
[root@EndeavourOS liveuser]# mount --rbind /dev/ /mnt/@/dev/
[root@EndeavourOS liveuser]# mount --rbind /proc/ /mnt/@/proc/
[root@EndeavourOS liveuser]# mount --rbind /sys/ /mnt/@/sys/
[root@EndeavourOS liveuser]# mount /dev/nvme0n1p1 /mnt/@/boot/
[root@EndeavourOS liveuser]# chroot /mnt/@/
[root@EndeavourOS /]# grub-install --target=x86_64-efi --efi-directory=/boot/EFI/ --bootloader-id=EndeavourOS
Installing for x86_64-efi platform.
Installation finished. No error reported.
[root@EndeavourOS /]#
When I reboot I can select EndeavourOS as boot option in my (UEFI) boot manager but after entering m encryption password I am thrown back to the boot manager without seeing a second grub menu (which should be the case. Any ideas if I am missing something obvious?
Feel free to ask for more information 
Reboot to get a clean setup and then follow this guide:
Just replace his device names with yours.
Why was i still having problems then? This is what I’m trying to figure out. What was different in the old file other than that? I didn’t see the difference… Is there somewhere to look at what the old file had compared to the new one?
is because boot is not mounted … when you mount to /mnt dont do /mnt/ thats too much
when you mounted mount -subvol=@ device /mnt
mount your boot
then arch-chroot /mnt is fine ,
What problems are you having, specifically?
I’m not having any problems anymore. What I’m trying to understand is what changed in grub so i wanted to see the old file as compared to the new file. Was this whole file inserted in grub or was it always there?
This is the current file and i have no issues. I wanted to compared this to the old one that was giving the issues. What is different about it?
### BEGIN /etc/grub.d/30_uefi-firmware ###
fwsetup --is-supported
if [ "$grub_platform" = "efi" -a "$?" = 0 ]; then
menuentry 'UEFI Firmware Settings' $menuentry_id_option 'uefi-firmware' {
fwsetup
}
fi
### END /etc/grub.d/30_uefi-firmware ###
~~~
Edit: I guess I'm just trying to understand why reinstalling grub and running the config would change anything unless there is a new grub?This is why:
1 Like
I understand most of what you are saying but i would just like to see the old file as compared to the new file?
Here is what was there before but there is only one line that actually matters in this case.
The fact that fwsetup --is-supported was added. Running grub-install added support for that command. The fact that is already there before you ran grub-install is what caused the problem.
the old file
#! /bin/sh
set -e
# grub-mkconfig helper script.
# Copyright (C) 2020 Free Software Foundation, Inc.
#
# GRUB is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# GRUB is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.
prefix="/usr"
exec_prefix="/usr"
datarootdir="/usr/share"
export TEXTDOMAIN=grub
export TEXTDOMAINDIR="${datarootdir}/locale"
. "$pkgdatadir/grub-mkconfig_lib"
EFI_VARS_DIR=/sys/firmware/efi/efivars
EFI_GLOBAL_VARIABLE=8be4df61-93ca-11d2-aa0d-00e098032b8c
OS_INDICATIONS="$EFI_VARS_DIR/OsIndicationsSupported-$EFI_GLOBAL_VARIABLE"
if [ -e "$OS_INDICATIONS" ] && \
[ "$(( $(printf 0x%x \'"$(cat $OS_INDICATIONS | cut -b5)"\') & 1 ))" = 1 ]; then
LABEL="UEFI Firmware Settings"
gettext_printf "Adding boot menu entry for UEFI Firmware Settings ...\n" >&2
cat << EOF
menuentry '$LABEL' \$menuentry_id_option 'uefi-firmware' {
fwsetup
}
EOF
fi
Was this fwsetup --is-supported added to it here?
cat << EOF
menuentry '$LABEL' \$menuentry_id_option 'uefi-firmware' {
fwsetup
}
EOF
fi
Above that section. Yes.
It’s almost as if it was trying to load the UEFI firmware when it’s already loaded and then it becomes unstable. 
No. It is just taking you to the firmware. Because fwsetup is called.
I had it boot to firmware in the beginning. But then when i reinstalled grub and ran the grub update i was having other issues with it. I even moved from rEFInd just to see because i booted from grub using rEFInd but i was still having issues. Eventually it seemed to straighten out after i got the grub updates.
Now all is okay and it boots fast now and loads everything correctly with no issues. Just trying to understand what the change was doing to make it act this way. 
It’s all good now and i still like grub. So i continue to use it. systemd boot would be good but i understand it less than grub.
I got borked by the update partially fixed in chroot then after they brought the update back I ran grub install again and been having this weirdness lol
So, ever since the weird grub-update situation I’ve had a strange issue with GRUB. I followed the pinned post and ran grub install after the update and rebooted, and It’s given me this error every time I boot since: “Loading linux kernel: 452: out of range pointer”
but if I press enter 2 times the third attempt always boots my OS like normal…so I haven’t been worried about it but I’ve since tried to fix it by re-installing GRUB again via the command:
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub
to which the output is:
Installing for x86_64-efi platform.
grub-install: warning: disk does not exist, so falling back to partition device /dev/sda1.
grub-install: warning: disk does not exist, so falling back to partition device /dev/sda1.
grub-install: warning: disk does not exist, so falling back to partition device /dev/sda1.
grub-install: error: disk `hostdisk//dev/sda1' not found.
could anyone help me out with this please? It’s bothering the hell out of me lol
EDIT: I also ran efibootmgr - to which the output was:
BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0000,0004,0001
Boot0000* endeavouros-6946
Boot0001* EndeavourOS-grub
Boot0004* UEFI OS
to which I made sure the order was:
sudo efibootmgr -o 0001,0004,0000
2 Likes
Hi! I ran into the GRUB issue and reinstalled using the guide on this forum, as well as this one after the first one didn’t work, with the same issue happening each time; I would install it, reboot, and select the new boot option from my boot menu, and verify that it booted properly. After seeing that it booted properly, I would restart to fix the UEFI boot order, only to find that the boot option I had just used was now gone, and the only other one I could use dropped me directly into GRUB rescue.
thanks for your respond.
here you are
[liveuser@eos-2022.08.28 ~]$ lsblk -o NAME,TYPE,FSTYPE,LABEL,SIZE
NAME TYPE FSTYPE LABEL SIZE
loop0 loop squashfs 1.6G
sda disk 953.9G
├─sda1 part vfat 1000M
├─sda2 part swap 8G
├─sda3 part 1000M
├─sda4 part ext4 683.9G
└─sda5 part ext4 blackArch 260G
sdb disk iso9660 EOS_202208 7.5G
├─sdb1 part iso9660 EOS_202208 1.7G
└─sdb2 part vfat ARCHISO_EFI 105M
but the old non-working entry is still there?
i would recommend to not create a new entry and go to use the same entry and update/overwrite it…
--bootloader-id=grub use the same name here as you find under /boot/efi/EFI