Grub 2:2.06.r322.gd9b4638c5-1 won't boot and goes straight to the BIOS after update

If you try the procedure I followed replacing:

/dev/sda1 by /dev/nvme0n1p1
/dev/sda2 by /dev/nvme0n1p2

This should do the trick.

@Moppel I had the exact same error due to my mistake while mounting the ESP.
grub-install: error: /boot/efi doesn’t look like an EFI partition.

1 Like

Should we run the script again or just upgrade the package to 1.1 is enough?

Updating the package to 1.1 will fix the issue for future kernel installs.

If you want to fix it for currently installed kernels you can do so with:

while read -r kernel; do
    kernelversion=$(basename "${kernel%/vmlinuz}")
    echo "Installing kernel ${kernelversion}"
    sudo kernel-install add ${kernelversion} ${kernel}
done < <(find /usr/lib/modules -maxdepth 2 -type f -name vmlinuz)

Of course, the only difference will be in the fallback entries. If you don’t care about the fallback entries, you could just wait for the next kernel update.


I only one thing to say about this whole grub issue. There is so much different information in all of these posts one cannot follow anything. I’m very disillusioned right now with grub. It’s all fine and dandy i can get my system to boot by some of these methods but if you update grub anytime it’s just problem after problem. I don’t see any solution as fixing the issue i just see more confusion. :disappointed:

Truly sad. It really shouldn’t be that complicated. I had no issues with re-installing grub to /dev/sda (on non-UEFI systems).

As of right now, the problem is still being investigated. Arch devs as well as @dalto (who’s been a legend during all of this btw), are discussing the issue via the bug report here:

For a majority of users the solution @sradjoker has posted works here. That thread alone has seen over 4k views in only two days which just shows the gravity this grub issue has had. It is interesting to see whether this has affected more Arch or Arch-derivative users, but all things are still ongoing so it’s hard to say at the moment.

I fixed my own issue with method 2 since and everything has worked fine for me. But I am tempted to look into systemd-boot now as a possible alternative. I don’t want to knee-jerk anything on my system at the moment, so since everything is working, I’ll wait and see what the Arch devs and grub upstream determine. For now, just a wait and see! :broccoli:


Like i said it’s easy to fix it to boot but go ahead and update grub again and see what happens. :pouting_cat:

I think - as compared to Arch users - there’s a majority here running EnOS on UEFI systems who experience the issue.

As @dalto is doing all he can, answering one and every emerency-question in need for urgent help, the whole case may really need to end up being solved by the EnOS devs, as long as Arch does not consider it a bug, at least.

Kudos to @dalto !

1 Like

It is an upstream problem. The issue has nothing to do with EndeavourOS as a distro. This is a sit and wait event.

1 Like

Are you sure about this?

1 Like

Yup :hugs:

It really depends on what happens upstream with both grub and Arch.

If the grub team decides to consider this a bug, then it will likely get fixed or reverted, that will propagate to Arch and EOS and all will be well in the long-term.

If grub decides it isn’t a bug, then we will need to see what Arch decides to do about it.

If both grub and Arch decide to do nothing, then the EOS team will have to decide how we are going to handle it.

Unfortunately, we have to wait and see what happens before we can plot a firm course forward.


[raccoon@den ~]$ sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=EndeavourOS-grub
[sudo] password for raccoon:
Installing for x86_64-efi platform.
grub-install: error: failed to get canonical path of `/boot/efi’.

I’m on a laptop at work at the moment, so this issue is different from the one I mentioned on my other thread. I tried to update my system knowing that there was the sticky message on the forum. I updated and copypasted the command and received the output above.

The laptop is kinda old so no efi, is there another command I can use to prevent reboot failure?

What show:

test -d /sys/firmware/efi && echo UEFI || echo BIOS

lsblk -fs

cat /etc/fstab


[raccoon@den ~]$ test -d /sys/firmware/efi && echo UEFI || echo BIOS
[raccoon@den ~]$ lsblk -fs
sda1 btrfs 76932b02-4584-4d33-a12c-7dbb02df6b04 438,7G 4% /var/log
│ /var/cache
│ /home
│ /

sda2 swap 1 swap 71b32d9c-342e-4e6a-afda-61bb1ac4d205 [SWAP]

sdb1 ntfs vault 686BA3D0527BB94B

[raccoon@den ~]$ 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).

UUID=76932b02-4584-4d33-a12c-7dbb02df6b04 / btrfs subvol=/@,defaults,noatime,compress=zstd 0 0
UUID=76932b02-4584-4d33-a12c-7dbb02df6b04 /home btrfs subvol=/@home,defaults,noatime,compress=zstd 0 0
UUID=76932b02-4584-4d33-a12c-7dbb02df6b04 /var/cache btrfs subvol=/@cache,defaults,noatime,compress=zstd 0 0
UUID=76932b02-4584-4d33-a12c-7dbb02df6b04 /var/log btrfs subvol=/@log,defaults,noatime,compress=zstd 0 0
UUID=71b32d9c-342e-4e6a-afda-61bb1ac4d205 swap swap defaults 0 0
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0

Unrelated whining: Man using a laptop when used to a desktop feels clumsy as hell.

The command:

sudo grub-install --target=x86_64-efi –efi-directory=/boot/efi --bootloader-id=EndeavourOS-grub

is for UEFI boot mode. Your system boots on bios/mbr/legacy mode. That’s why:

If I have understood the recent Grub issue, only systems wit UEFI boot mode are affected.
So your’s should be fine.

At any rate, for reinstalling the bootloader in bios mode:

sudo grub-install --target=i386-pc /dev/sdX

Replace X with the letter of the device. In your case that would be a.

1 Like

Thank you very much for your help, I now realize it was a dumb question, I just got a bit paranoid with the issues that happened lately.


Thanks for making things clearer!



Done all but not when I try to boot I get this message

This usually means you need to manually set the correct EFI entry to boot from. Either by using efibootmgr or just going into your BIOS and picking the correct option in the boot section.