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

What ISO are you booting off of?

Is it possible for the members of the EndeavourOS team to create a program that one could download, copy to a thumb drive, insert the drive into the affected computer(s), and (semi-)automatically fix the GRUB problem?

The instructions given above are certainly clear enough but I’m afraid that actually implementing them might be a bit too complex for me. We now have two computers which are affected by this bug; I am not updating any of our other EOS computers at this time.

Thanks for considering my suggestion and for any other ideas.


It is possible, but the time it would take to develop it would likely be substantial.
There are many things to consider that make it complicated to handle generically.

  • btrfs
  • lvm
  • luks
  • md
  • multiboot scenarios
  • identifying the correct device.

You should be following these instructions instead anyway:

The latest

how would i go about getting the other updates, but not grub?

1 Like

Here is what worked for me and my setup. I did not need to downgrade grub, but I did need to run grub-install.

1: Boot into an EndeavourOS Live USB.
2: Open terminal
3: Check disks: sudo fdisk -l

Device              Start        End    Sectors   Size Type
/dev/nvme0n1p1       2048    2099199    2097152     1G EFI System
/dev/nvme0n1p2    2099200    2131967      32768    16M Microsoft reserved
/dev/nvme0n1p3    2131968  421529599  419397632   200G Microsoft basic data
/dev/nvme0n1p4  421529600 1470105599 1048576000   500G Microsoft basic data
/dev/nvme0n1p5 1470105600 1953525134  483419535 230.5G Linux filesystem

The above is my output:

nvme0n1p1 has type EFI System. This is the boot partition. This will be mounted to /mnt/boot/efi
nvme0n1p2, nvme0n1p3, and nvme0n1p4 are my Windows partitions. They are ignored because they still boot.
nvme0n1p5 has type Linux filesystem. This is the root partition. This will be mounted to /mnt

4: Mount disks:

sudo mount /dev/nvme0n1p5 /mnt
sudo mount /dev/nvme0n1p1 /mnt/boot/efi

5: Arch-chroot:

sudo arch-chroot /mnt

6: Check for my user:

ls home

should return adjagu for me, will be different for everyone.

7: Repair GRUB on EFI/UEFI:

sudo grub-mkconfig -o /boot/grub/grub.cfg

8: Reinstall GRUB on EFI/UEFI:

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

9: Exit Arch-Chroot:


10: Unmount mounts:

sudo umount /mnt/boot/efi
sudo umount /mnt

11: Reboot:

sudo reboot

After rebooting I choose EndeavourOS-grub from my computers BIOS UEFI boot menu.

Computer boots into the EndeavourOS boot loader (like it used to do before the last update) and all of my OS’s (including Windows) are available for selection.


Either add it to ignorePkg in /etc/pacman.conf or pass --ignore to pacman/yay/paru

1 Like

You are not out anything if you try. Just choose one system a go for it. Otherwise you will not grow as a Linux user.

As @dalto said, that is very time intensive and the amount of variables involved are way more than what he listed. To be honest, I do not know of any OS that has something like that. The closest would be that computer company that stole their name from the Beatles record company. They are only dealing with a limited set of hardware. Even using boot repair on Windows is not a sure thing.


sudo pacman -Syu --ignore grub


Just now I had seen this topic :open_mouth:, was not even aware of this :sweat_smile: .

Though, my 11 years old PC with KDE, kernel 5.19.3-arch1-1 is still booting inside 8 seconds.

Also, I had executed shutdown-power on process 5-6 times to find the error, but Old is still Gold !

Well, I am trying to follow the Endeavouros wiki:

mount: /dev/mapper/mycryptdevice: can't find in /etc/fstab.

Is the endeavour wiki instructions correct for encrypted systems or am i doing something wrong?

The wiki could be better written I think it is a little hard to follow.

I think most people will try to reinstall. This is a fall flat on the face disaster for the grub devs - how does a major bug not get discovered in testing - have they been cutting corners?

Did you follow this section: For encrypted systems: (by the end of the page)

The other option is to chroot into the system then run sudo downgrade grub
A list will appear and select the previous Grub version and let the system do its work. Log of and boot into your system again.

Downgrade like Yay is installed by default on Endevaour.

You just saved my install and I cannot thank you enough


I wonder if there’s some automated way to convert grub to system-boot or refind?

For now I’ve ignored pkg = grub in pacman.conf and was lucky to have spotted the issue with grub before I updated. But seriously thinking about changing to something else which is, hopefully, fail proof.

there is a how to in the forum the dalto way :slight_smile:

1 Like

Seen his guidelines already but I’m not experienced enough yet to try it, also breaking my system now is not a good idea. Need a working system for at least another 3~4 weeks.

After that I could try.

Maybe also make systemd-boot / refind as an option when using calamares installer?!

1 Like

How to convert to systemd boot: [Tutorial] Convert to systemd-boot

Converting to refind typically just involves installing the package and running the command to install it.

Switching bootloaders is probably not a good option for you right now then. There is always some risk in doing so.

Is there any refind tutorial?