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

This is wrong I think. That is your EFI partition. It gets mounted on /mnt/boot/efi after you mount your root partition on /mnt

1 Like
[root@EndeavourOS /]# sudo mount /dev/nvme0n1 /mnt/
mount: /mnt: /dev/nvme0n1 already mounted or mount point busy.
       dmesg(1) may have more information after failed mount system call.
[root@EndeavourOS /]# sudo mount /dev/nvme0n1p1 /mnt/boot/efi
mount: /mnt/boot/efi: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.

:confused:

Maybe i should start over again.

Its really confusing my disk ist named nvmeXXXX and not the sdX thing.

That isn’t even a partition. What are you trying to do there?

This should be fixed now with version 1.1

I just tried to follow the guides on how to fix the grub issue. But as my system is on btrfs and luks its quite complicated.
Obviously too complicated for my level of knowledge.

I installed it this way with a tutorial on automatic snapshots with btrfs so I can easily go back.
Thought this would be nice for a Beginner - to revert things with one click.

But now it seems this Idea was quite dumb. :sweat:

I’m still trying to mount the efi partition. :confused:

What @lugh posted above should work for you. He has a very similar setup to yours.

Where he uses /dev/sda2, you should use /dev/nvme0n1p2 instead.

Where he uses /dev/sda1, you should us /dev/nvme0n1p1 instead.

1 Like

Also, you might want to reboot clean before you start that.

1 Like

If you try the procedure I followed replacing:

/dev/sda1 by /dev/nvme0n1p1
and
/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.

2 Likes

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: https://bugs.archlinux.org/task/75701

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:

6 Likes

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.

8 Likes

[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?