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

I had the same problem with a desktop.

How did you restore from a timeshift snapshot without a bootable system?

Very strange; I reproduced the issue multiple times last night.

4 times with grub-tools = 4 failures to boot.

4 times without grub-tools = 4 successful boots.

I just now tried it once again; with grub-tools installed, a reboot fails:

UEFI_fail

Without grub-tools, the boot proceeds normally.

Extremely odd that I am getting such consistent results doing this, and a couple of other users have said that this seems to have worked for them, while others are not seeing a difference. Extremely odd.

Granted, I am using VMs, not bare metal, but I would have thought the results would be the same.

2 Likes

It doesn’t seem odd to me.

In your tests without grub-tools, you probably aren’t running grub-mkconfig.

The issue won’t occur if you don’t run grub-mkconfig which injects the problematic line into your grub config.

3 Likes

Boot off a live ISO and install timeshift on it.

1 Like

I updated GRUB while following the instructions from this link:

But now, each time I reboot, I get the following message:

  Booting 'EndeavourOS, on linux'

Loading kernel linux ...
452: out of range pointer: 0x631d9020

Aborted. Press any key to exit.

When I press any key to exit, it just continues on to the login screen as normal, but it’s still worrying to me that I am getting this message every time I boot into the system now, especially after this recent GRUB update. Not to mention that it’s annoying to have to press a key every single time.

How do I fix this problem? Or will it go away by itself when the next GRUB update comes out?

has to do bit on nvram. if you open efibootmgr there are multiple entries

endeavouros-Grub is the working entrie
with sudo efibootmgr -b xxxx -B you can remove the faulty ones
and sudo efibootmgr -o XXXX,YYYY,ZZZZ

to change the boot order if the bootorder not is correct
you see on top of efibootmgr

2 Likes

Confirmed and thank you!
I removed grub-tools with -Rcdns (which removed another dependency, don´t remember the name…) and updated 3 uefi machines, no problems at all!

edit: just to reiterate, one computer has 2 ssd’s. The first ssd (xfce) I updated with grub-tools and it got borked. The second ssd (cinnamon) I updated after removing grub-tools, ti worked flawlessly

That is bad. You now have a the grub issue and don’t know it.

As soon as you run grub-mkconfig the issue is going to show up. Also, when you install new kernels they won’t be added to the grub menu.

Thanks for the info, but I will change all to refind.
But out of curiosity, how is this different from the std arch installation hooks?
Has EOS changed this that much? I mean, this grub-tools package is really necessary?

Arch doesn’t have standard hooks for grub. Unless you install the hooks yourself, grub-mkconfig doesn’t get run.

1 Like

Ah ok! I remember doing this manually in the past, got it.

1 Like

if i did a clean install now, would the problem still be there? just asking

If you do an offline install, yes.

If you do an online install, no.

2 Likes

OK, maybe I’m missing something here, but if I remove grub-tools, update the grub package, and then run sudo grub-mkconfig -o /boot/grub/grub.cfg to regenerate the grub.cfg, I can boot the machine just fine. I’ve done it 4 times in a row now, with fresh (cloned) VMs.

After this, the machine boots:

ztest_04_no-tools_regen

And, for the record, I have not advocated removing grub-tools as a “solution” - I’m just reporting the results from experimenting in VMs.

I booted my EndeavourOS ISO then mounted and arch-chrooted into my hard drive where EOS was installed, then I was able to run timeshift from there.

I can reproduce this issue 100% of the time in a pure Arch VM.

That being said, I have some questions:

  • What version of grub were you using when you ran grub-install initially?
  • Have you verified that the VM is a UEFI machine?
1 Like

The version on the Artemis Neo ISO, grub 2:2.06.r261.g2f4430cc0-1. Good point, there was a version after that (grub 2:2.06.r297.g0c6c1aff2-1), I should have updated to that version first. I can try it with that version after lunch.

UEFI_00

Ok so, maybe the thing to try next is…

Boot into your VM UEFI system without grub-tools. (and latest grub of course)

Install grub-tools

run ‘grub-mkconfig -o /boot/grub/grub.cfg’

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

and see if it can reboot with grub-tools installed.

If you run grub-install afterwards, it will boot fine.