Cool!!
I was so confused last night in interpreting “sdaXn” and mounted the wrong partitions. It took some time reading through archwiki and this forum.
Glad that this solved your issue.
1 Like
I am unsure if I use UEFI. Can I still use the command?
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=EndeavourOS-grub
Have yet to update my system, I assume I could also wait for another grub update that fixes this bug?
Run the command efibootmgr to check. The issue only applies to people with UEFI systems so if you aren’t using UEFI, you don’t need to anything.
It isn’t yet clear if this is considered “broken” by grub or if there will be a “fixed” version or not.
1 Like
Well—hopefully, that will be the “fix” for the current problem…You are right–I should go back to a stock configuration.
Seems like EFI:
BootCurrent: 0003
Timeout: 2 seconds
BootOrder: 0003,0002,0001,0018,0019,0000
Boot0000* EndeavourOS VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
Boot0001* Windows Boot Manager HD(1,GPT,583c49b6-9ed3-e04b-bfee-27f5968deac1,0x1000,0x96000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000061000100000010000000040000007fff0400
Boot0002* endeavouros-9389 HD(1,GPT,583c49b6-9ed3-e04b-bfee-27f5968deac1,0x1000,0x96000)/File(\EFI\ENDEAVOUROS-9389\GRUBX64.EFI)
Boot0003* endeavouros-2684 HD(1,GPT,583c49b6-9ed3-e04b-bfee-27f5968deac1,0x1000,0x96000)/File(\EFI\ENDEAVOUROS-2684\GRUBX64.EFI)
Boot0018* UEFI OS HD(1,GPT,583c49b6-9ed3-e04b-bfee-27f5968deac1,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot0019* Hard Drive BBS(HD,,0x0)0000474f00004e4fb10000000100000075005700440043002000570044003400300045005a0052005a002d00300030004700580043004200300000000501090002000000007fff040002010c00d041030a0000000001010600030101010600010003120a000000ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce62000200020002000570020002d004400430057003700430034004b0053004500330035003600350000007fff04000000424f00004e4fb10000000100000075005700440043002000570044003400300045005a0052005a002d00300030004700580043004200300000000501090002000000007fff040002010c00d041030a0000000001010600030101010600010003120a000100ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce62000200020002000570020002d004400430057003700430034004b0058005300330052004e00530000007fff04000000424f00004e4fb10000000100000075005700440043002000570044003400300045005a0052005a002d00300030004700580043004200300000000501090002000000007fff040002010c00d041030a0000000001010600030101010600010003120a000200ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce62000200020002000570020002d004400430057003700430035004b0053005300450054005400320000007fff04000000424f00004e4fa70000000100000075004300540031003000300030004d005800350030003000530053004400340000000501090002000000007fff040002010c00d041030a0000000001010600010801010600020003120a000300ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce63900310033003000310045003400450037003200430046002000200020002000200020002000200000007fff04000000424f00004e4fbf000000010000007d00530061006d00730075006e006700200053005300440020003900370030002000450056004f00200031005400420000000501090002000000007fff040002010c00d041030a0000000001010600030101010600020001010600000401010600000003171000010000000025385991b1d9bb7fff040001043400ef47642dc93ba041ac194d51d01b4ce653003400360037004e00580030004d003900310034003300300035004a0000007fff04000000424f00004e4fa300000001000000610053005400350030003000300044004d003000300030002d00310046004b003100370038002000300034003000310000000501090002000000007fff040002010c00d041030a000000000101060001070101060003000305060007007fff040001042e00ef47642dc93ba041ac194d51d01b4ce630003000300030003000300030003000340038003900390000007fff04000000424f
Yes, EFI for sure.
For me this is a fatal mistake! But anyway thanks to this incident I looked around and found rEFInd which is OK, but I found systemd-boot much simpler. So, I just did it and converted to systemd-boot thanks to @dalto and his tutorial [Tutorial] Convert to systemd-boot
By the way, I am not by any means saying Grub is bad or rEFInd is not that good.
As long as there is software there are bugs.
I just thought this is what suits me more! Simpler and easier to maintain or fix (I think) if it happened!
So far so good and enjoying.
Heyo, just wanting to add my 2c to the mix and explain how I got this resolved (for the meantime) on my system.
For reference, my system is an infinity laptop (rebranded Taiwan OEM). I have two NVME drives, one which I use to boot windows, one of which I have a revolving door of Linux distros and even freeBSD at one point. I already installed endeavour on my janky 10 year old toshiba yesterday without issues, and then went to put it on this one. Installed fine, didn’t get past GRUB. Tried following the steps in posts here (originally commented this on reddit) and on the forum, didn’t work.
What did work was installing fresh, then going into efibootmgr and changing the boot order to the endeavour-numbers one. That boots fine now, but opens in a terminal grub page instead of the nice one on my jankmachine. Another reboot and it’s back to being pretty again.
When I went back and used the grub install command it changed my boot order back into a non-functional one again. I’d suggest if this works for you, for now at least do not rerun the grub insta thing.
I hope this is useful for someone, so I thought I’d post here as well as the subreddit.
Hello dear community!
After being affected by the recent grub update that results in an unbootable OS, I now need help with the reinstalltion of GRUB.
With help of this article on how to chroot with luks and btrfs I managed to finally chroot into my system.
But now I’m stuck following this GRUB repair tutorial.
[liveuser@eos-2022.08.05 mapper]$ sudo umount /mnt
[liveuser@eos-2022.08.05 mapper]$ sudo mount -o subvol=@ /dev/mapper/mycryptdevice /mnt
[liveuser@eos-2022.08.05 mapper]$ sudo mount -o subvol=@log /dev/mapper/mycryptdevice /mnt/var/log
[liveuser@eos-2022.08.05 mapper]$ sudo mount -o subvol=@cache /dev/mapper/mycryptdevice /mnt/var/cache
[liveuser@eos-2022.08.05 mapper]$ sudo mount -o subvol=@home /dev/mapper/mycryptdevice /mnt/home
[liveuser@eos-2022.08.05 mapper]$ sudo mount /dev/mapper/mycryptdevice /mnt/boot/efi
[liveuser@eos-2022.08.05 mapper]$ sudo arch-chroot /mnt
[root@EndeavourOS /]#
[root@EndeavourOS /]# grub-install --target=i386-pc /dev/mapper/mycryptdevice
Installing for i386-pc platform.
grub-install: error: cannot read `/dev/mapper/mycryptdevice': Bad file descriptor.
[root@EndeavourOS /]# grub-install --target=i386-pc /dev/nvme0n1p2
Installing for i386-pc platform.
My fstab looks like this:
[root@EndeavourOS /]# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=47E9-0411 /boot/efi vfat umask=0077 0 2
/dev/mapper/luks-64943aac-427f-4753-807f-e2916b279cda / btrfs subvol=/@,defaults,noatime,compress=zstd 0 0
/dev/mapper/luks-64943aac-427f-4753-807f-e2916b279cda /home btrfs subvol=/@home,defaults,noatime,compress=zstd 0 0
/dev/mapper/luks-64943aac-427f-4753-807f-e2916b279cda /var/cache/pacman/pkg btrfs subvol=/@var-cache-pacman-pkg,defaults,noatime,compress=zstd 0 0
/dev/mapper/luks-64943aac-427f-4753-807f-e2916b279cda /var/cache btrfs subvol=/@cache,defaults,noatime,compress=zstd 0 0
/dev/mapper/luks-64943aac-427f-4753-807f-e2916b279cda /var/log btrfs subvol=/@log,defaults,noatime,compress=zstd 0 0
/dev/mapper/luks-64943aac-427f-4753-807f-e2916b279cda /swap btrfs subvol=@swap,defaults,compress=no 0 0
/swap/swapfile none swap defaults 0 0
Can someone point me into the right direction? If you need any more information feel free to ask. 
Thank you in advance!
Don’t follow that tutorial. Follow these instructions:
I think i did?
This tutorial is linked in the instruction. Or am I mistaken?
Its step 3.
In that case. Once you get into the chroot, just do this:
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=EndeavourOS-grub
Thank you, I’m confronted with this now:
[root@EndeavourOS /]# sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=EndeavourOS-grub
Installing for x86_64-efi platform.
grub-install: error: /boot/efi doesn't look like an EFI partition.
That sounds like you didn’t setup the chroot properly.
What does lsblk -o name,type,fstype,size show?
Is it possible that my EFI partition is the nvmen1p1 one?
[root@EndeavourOS /]# lsblk -o name,type,fstype,size
NAME TYPE FSTYPE SIZE
loop0 loop 1.6G
sda disk 14.9G
├─sda1 part 1.7G
└─sda2 part 104M
nvme0n1 disk 238.5G
├─nvme0n1p1 part 400M
└─nvme0n1p2 part 238.1G
└─mycryptdevice crypt 238.1G
Yes. Mount it and look inside it to know for sure.
[root@EndeavourOS /]# sudo mount /dev/nvme0n1p1 /mnt
[root@EndeavourOS /]# ls /mnt/
EFI
yep?
Are these the correct next steps?
[root@EndeavourOS /]# sudo umount /dev/nvme0n1p1
[root@EndeavourOS /]# sudo mount /dev/nvme0n1p1 /mnt/boot/efi
No, after unmounting that, you need to mount the root on /mnt. Unless it is mounted underneath the efi partition
Hello,
Just in case it can help others, here is what I did to solve this grub issue on encrypted btrfs disk.
First boot on live usb from the last EndeavourOS iso downloaded on the website.
Then I followed the expected procedure: The latest grub package update needs some manual intervention
But since it might not be obvious to everyone, here his a quick summary.
Get the actual partitions name:
sudo fdisk -l
sda1: EFI
sda2: Linux File System
(pay attention to adapt the partition name to your case)
Unlock encrypted partition:
sudo cryptsetup open /dev/sda2 mycryptdevice
It’s now available in /dev/mapper/mycryptdevice
Now mount all btrfs subvolumes from the unlocked partition:
sudo mount -o subvol=@ /dev/mapper/mycryptdevice /mnt
sudo mount -o subvol=@log /dev/mapper/mycryptdevice /mnt/var/log
sudo mount -o subvol=@cache /dev/mapper/mycryptdevice /mnt/var/cache
sudo mount -o subvol=@home /dev/mapper/mycryptdevice /mnt/home
Then mount the ESP from /dev/sda1: (pay attention its indeed /dev/sda1)
sudo mount /dev/sda1 /mnt/boot/efi
Now I’m able to chroot on my install:
sudo arch-chroot /mnt
Finally I was able to repair grub with:
grub-mkconfig -o /boot/grub/grub.cfg
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=EndeavourOS-grub
Reboot, and it worked !
What I missed was that I mounted /dev/sda2 in /boot/efi instead of /dev/sda1 … small mistake that took me a few minutes to figure out.
Hope this will simplify the procedure for you if you have the same kind of setup.
Best luck to you,
Lugh.
Edit: you will end-up with a new UEFI entry EndeavourOS-grub (previous one was EndeavourOS). You may need to select the new one after reboot is your BIOS boot menu.
1 Like
Ok
[root@EndeavourOS /]# sudo umount /dev/nvme0n1p1
[root@EndeavourOS /]# sudo mount /dev/nvme0n1p1 /mnt/
After all this fiddling I’m a bit confused what to do next. I’m sorry. 
How do I mount the efi partition correctly to reinstall grub from then on?
Edit: I’ll check what @Lugh wrote.