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

General system
1322

I’ve never seen that before,
And these entries are to my knowledge also auto-created by the firmware itself…

Boot0000* endeavouros   HD(1,GPT,18e01f-4e4e-a397-ce065c,0x1000,0x100000)/File(\EFI\endeavouros\grubx64.efi)

looks totally fine you even do not have the device entry for the harddrive what would look like this:
Boot0033* UEFI OS HD(1,GPT,e996000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f

You could check about if you have the efi fallback image?

ls /boot/EFI/boot/bootx64.efi
what will give back /boot/EFI/boot/bootx64.efi if present or file not found …

1323

Oh! I didn’t expect that :sweat_smile:

It shows me file not found

1324

must be ls /boot/efi/EFI/boot/bootx64.efi
missing the first efi …

1325

Now it show me this

[root@endeavour ehudd]# ls /boot/efi/EFI/boot/bootx64.efi
/boot/efi/EFI/boot/bootx64.efi
[root@endeavour ehudd]#
1326

If you add option -l to the ls command, you will see the date of the file.
Has the date changed?

ls -l /boot/efi/EFI/boot/bootx64.efi

Also

ls -l /boot/efi/EFI/endeavouros
1327

Hi!

Using the -l argument the date of those files is diferent:

[root@endeavour ehudd]# ls -l /boot/efi/EFI/boot/bootx64.efi
-rwx------ 1 root root 143360 sep 23  2021 /boot/efi/EFI/boot/bootx64.efi
[root@endeavour ehudd]# ls -l /boot/efi/EFI/endeavouros
total 148
-rwx------ 1 root root 151552 sep 15 12:26 grubx64.efi
[root@endeavour ehudd]#
1328

You could arch-chroot into the installed system (using e.g. a TTY if possible, of the USB installer stick). Then can you show the output of

lsblk -f
sudo fdisk -l
cat /etc/fstab | eos-sendlog
1329

I just chroot using a TTY and these are the results:

IMG_20220927_113207

IMG_20220927_113229

IMG_20220927_113336

1330 
/boot/efi/EFI/boot/bootx64.efi

is what is used by the uefi OS entire sin the nvram… it will not get recreated with grub-install only if you run it a second time and add --removable option grub-install --removable so it will include latest changes to grub stuff too…

yours is from last year

sep 23  2021
1331

So, I just need to update my system normaly and then run the grub-install --removable to fix this issue?
Or there is something else?

Thanks for all your help

1332

it is a fallback boot entry that will be available with this… and to update it you need to run grub-install --removable in addition to grub-install
But only if grub package gets an update… not regular after each update… …

1333

I was under the impression that this had finally been address with the updates after Grub 2:2.06.r322.gd9b4638c5-1 for which the current is Grub 2:2.06.r322.gd9b4638c5-4. Fresh install of a just released XeroLinux and without additional steps after install booting just fine? If I missed something please let me know. Thanks

1334

It depends what you mean by “this”. The issue with booting directly to firmware is the same still with that release.

The issue is caused by having an old version of grub EFI installed and a newer version of grub.conf installed. With an install from a recent ISO, the issue shouldn’t occur because both would be new.

1335

So if I install EOS next to Xero which already created the boot partition I should see any issue?

1336

If you install off the most recent EOS ISO, you should not be impacted for the same reason as above, the ISO version of grub is newer. EOS will install it’s own copy of grub to the EFI.

1 Like
1337

Thanks dalto for clarifying that for me. It’s much appreciated.

1 Like
1338

So, I can now be sure that if I reinstall Grub there will never ever be these Grub issues? It is not the same upstream Grub?! It is our own reliable Grub?
Do I get it correctly?

1339

no not that.
We do still use grub from arch repos… and if there is a grub package update you will need to run grub-install manually… but if you do install a new instance of EndeavourOS you will not have any issue because independently from what install you choose grub package used to create the grub files inside target and grub package version will be the same.

1340

So, just to learn more, the special EOS Grub on its own works OK, but the problem will be back if an update from main stream (Arch Grub) comes through.

I wonder if there is a way to “block” Grub in particular from being updated from Arch and update it only from EOS?

Mmmm… I wonder why it is so in Arch repos!

1341

There is no special eos grub. we just use arch grub. We don’t ship system packages independent of arch

1 Like