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

as most users need to run grub-install to solve the issue.

from the link provided I did:

[liveuser@eos-2022.06.23 ~]$ sudo sudo grub-install --target=x86_64-efi --/run/media/liveuser/61a4b393-816a-4e46-b1c1-414fd890d68a/@/boot/efi/=/boot/efi --bootloader-id=EndeavourOS-grub
grub-install: unrecognized option '--/run/media/liveuser/61a4b393-816a-4e46-b1c1-414fd890d68a/@/boot/efi/=/boot/efi'
Try 'grub-install --help' or 'grub-install --usage' for more information.
[liveuser@eos-2022.06.23 ~]$ 

So this is pretty interesting. I can’t find any documentation that states that this is required. Almost none of the official grub documentation or the distro-specific documentation addresses upgrading grub at all.

However, if it is required, we(and many others) are doing it wrong.

I don’t think that is true. grub-mkconfig just creates a new grub config. It doesn’t reinstall the bootloader.


I wonder, will it be fixed upstream to avoid that manual intervention? :clown_face:

P.S. Holy crap, i think i’ve just hit an emoji-jackpot! :rofl:


Take it with a grain of salt since I’m not a dev or maintainer, but if the bug isn’t reproducible for them what else are they really supposed to do? If it works for them, hence why the updated the package, but it breaks for others, it might be something else with the other users, and that requires more investigations than just pulling back a package suddenly.

That is wrong. You need to follow the chroot instructions. Follow what is described here:

Yup - it’s definitely left as something implied, which probably isn’t great given e.g. security updates that rely on an updated loader. From IRC, it does look like many Arch users just reinstall the loader themselves as a matter of course, but it does kind of look like it should be documented.

It’s possible to add a post-update hook to do it, but that would have to match the initial installation options.


Got this message too and could fix it by typing

arch-chroot /mnt /bin/bash

before executing the grub-mkconfig

I wasn’t saying it was a solution. Just reporting what i did on btrfs and i was able to boot properly.

Can only be “short term”, according to @dalto.

Not sure what you mean?

It’s not clear if it’s broken? Could it just be a coincident that multiple ppl here can’t boot after the update?
And do you really think that the devs (I hope it’s not just one guy) didn’t get any reports yet?

Don’t get me wrong, that’s not sarcasm but serious questions.

On Android, I usually wait at least 3-4 hours before installing updates because if there’s the slightest chance that an update causes serious problems then it’s usually pulled within 2 hours. And it works, I never had any serious bugs caused by an update.

1 Like

Look upwards in this mega-thread…

There’s no bug been filed against the new grub-version on Arch, so far.

Anyone filing it from here!?

I am unable to fix it, chrooted almost 10 times and did the above mentioned steps ,but it still doesn’t work. Please help…

1 Like

If @jonathon is correct (and let’s face it he usually is) the problem is not with the updated grub package, but the lack of clarity in the Arch documentation for grub leading to incorrect implementations (that somehow have not exploded until now). I think I’ve summarised that correctly?


I still don’t know what you are telling me. I never said anything other than what i did on my system which is btrfs to get it to boot up properly doing an arch-chroot and downgrading grub.

Well, that sounds pretty unprofessional for me. In my opinion, if there’s the slightest chance that a update causes critical bugs it has to be pulled ASAP. Then the devs can research.

If you have a second computer on hand you could put this on an USB Stick:, boot from the USB stick and then via supergrub2 into your normal EndeavourOS. Then you can perform a downgrade or whatever on GRUB.

Is it loading directly to the BIOS or is it trying to load and stalling?

It directly goes to the BIOS.