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

having multiple grub issues now, even after trying timeshift --restore. I think my EFI is broken

Oh! All what I saw here was about installing/downgrading/restoring… Grub, …Maybe I missed posts about restoring snapshots?
How to do it just in case?

In your case. Boot off ISO, install btrfs-assistant, mount any part of your btrfs filesystem. Restore as usual via btrfs-assistant.

1 Like

Follow the guide again, arch-chroot then grub-install, or maybe you can try to use rEFInd as suggested by others.

Other option would be to arch-chroot, downgrade grub and ignorepkg in pacman.conf

Lastly, you could follow Dalto’s guide and convert to systemd-boot
https://forum.endeavouros.com/t/tutorial-convert-to-systemd-boot/13290

Its Artemis and it boots fine now I would have preferred not to dò a clean install to fix an Arch maintainer’s screwup, but it’s working again :sweat_smile:

Appreciate the work that has been done thus far… What options can be provided when " I have already updated and my machine is broken, what should I do?" solution does not resolve the issue?

https://forum.endeavouros.com/t/grub-2-2-06-r322-gd9b4638c5-1-wont-boot-and-goes-straight-to-the-bios-after-update/30653/455?u=secdoc

It looks like you need to grub-mkconfig again. If that doesn’t work, try disabling os-prober first.

@dalto I have run grub-mkconfig -o /boot/grub/grub.cfg as well as the grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=EndeavourOS-grub over a dozen times this morning with no affect. Other than biting the bullet and completely re-imaging the system, what are the possible options?

This is what gets shown in efibootmgr:

[root@EndeavourOS boot]# efibootmgr
BootCurrent: 0019
Timeout: 1 seconds
BootOrder: 0000,001A,0018,0019
Boot0000* EndeavourOS-grub	HD(1,GPT,89187583-b98b-df4e-8e87-d5fa5c3cd5a0,0x1000,0x96000)/File(\EFI\EndeavourOS-grub\grubx64.efi)
Boot0018* UEFI: SMI USB DISK 1100, Partition 1	PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x8,0x0)/Pci(0x0,0x3)/USB(9,0)/HD(1,MBR,0xb2df2391,0x800,0x751f800)0000424f
Boot0019* UEFI: SMI USB DISK 1100, Partition 2	PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x8,0x0)/Pci(0x0,0x3)/USB(9,0)/HD(2,MBR,0xb2df2391,0x7520000,0x10000)0000424f
Boot001A* UEFI OS	HD(1,GPT,9cdd36fd-6d73-f84a-9a25-2b16e62b632c,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f

Since your grub is working and you are just missing the menu entry you could create a manual entry in grub.

Right now, it’s acting like I’ve booted BIOS instead of UEFI. No idea why.

This is what was happening to me once this grub problem began.
Maybe you should follow the recommended actions again and if that doesn’t work, you have the options mentioned above in my previous post, which would be:

  • try the suggested actions by the community: arch-chroot followed by grub-install
  • arch-chroot, downgrade grub and set ignorepkg for grub in pacman.conf, this will allow you to wait for a fixed version.
  • try rEFInd as suggested by others
  • convert to systemd-boot

Did you try to boot from original refind iso and see what happens?

https://www.rodsbooks.com/refind/getting.html
http://sourceforge.net/projects/refind/files/0.13.3.1/refind-cd-0.13.3.1.zip/download

Boot to Uefi setup, or Uefi quick boot menu and select the new EnOS/grub entry. The system is using the old entry and fails.

1 Like

not using reFind

I usually update my EOS every day and now I know that is a good idea to check some news before doing it. Anyway, I ended up in this mess.

I have a dual boot windows setup on separate drives. My PC boots directly to bios and if I change boot priority to windows drive I can boot to windows. Anyway, my EOS doesn’t work currently and I checked guide pinned on this forum how to fix it.

I admit that I didn’t educate myself enough in “fixing stuff through console” and now I have problem understanding what exactly I have to do.

Anyway, I booted to EOS live and this is my sudo fdisk -l and if I think that my EOS drive when also boot is located is “Disk /dev/sda” like mentioned in that guide. On that disk is only one device “/dev/sda1” and I don’t have “EFI” and “Linux filesystem” like in that example. Of course each setup can be different so I can’t blindly just copy paste stuff.

I don’t understand how current live OS is related to my installation and RFS means root of current installation or root on my EOS whis is currently unavailable? If I understand correctly I need to mount something from my drive to current live OS and fix it or tell “live OS” to use files on my drive.

after those two sudo commands for mounting I can’t find anywhere how I actually fix that grub? If I understand correctly chroot doesn’t fix it but just gives me the option to do it?

If anyone can give me a more detailed instruction for my case I will be very thankful.

I know, just to boot so you can check if you can boot into EFI mode. I mean, refind will only let you boot efi…

You have multiple EFI partitions and multiple disks with linux fileystems on them. Do you know where Endeavouros was installed? Which SSD?

@dalto looking at the Arch Wiki it does not provide a direct example for the scenario but implies it. The ArchWiki shows the following example:

menuentry "Arch Linux 64" {
    # Set the UUIDs for your boot and root partition respectively
    set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07
    set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a

    # (Note: This may be the same as your boot partition)

    # Get the boot/root devices and set them in the root and grub_boot variables
    search --fs-uuid $the_root_uuid --set=root
    search --fs-uuid $the_boot_uuid --set=grub_boot

    # Check to see if boot and root are equal.
    # If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)
    if [ $the_boot_uuid == $the_root_uuid ] ; then
        set grub_boot=($grub_boot)/boot
    else
        set grub_boot=($grub_boot)
    fi

    # $grub_boot now points to the correct location, so the following will properly find the kernel and initrd
    linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro
    initrd $grub_boot/initramfs-linux.img
}

Another reference shows a slightly different example as below:

menuentry "EndeavourOS" {
    search --set=root --fs-uuid "xxxxx-xxxx-xxxx-xxxx-xxxx"
  linux /boot/vmlinuz-* root=UUID="xxxxx-xxxx-xxxx-xxxx-xxxx" rw  quiet
}

My question is this, given that I am using btrfs, which UUID should be used based on the blkid below:

[root@EndeavourOS grub.d]# blkid | grep 'nvme1n1'
/dev/nvme1n1p2: UUID="da4f6dcb-c1c5-4b85-bc75-7a244a2dd94c" UUID_SUB="26169175-ae6f-4b95-b7f1-fa0d9772ff62" BLOCK_SIZE="4096" TYPE="btrfs" PARTLABEL="root" PARTUUID="ea25ddad-23dd-ab4b-8f01-3a99fb7014b4"
/dev/nvme1n1p1: LABEL_FATBOOT="NO_LABEL" LABEL="NO_LABEL" UUID="A5F7-18E4" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="89187583-b98b-df4e-8e87-d5fa5c3cd5a0"

You should use the main UUID. However, add subvol=@ to the line that that starts with linux for your root partition if you are using the default btrfs subvol names.

@dalto Is that for the ArchWiki reference or the second reference I listed? Also would it go at the beginning of the lines or need to be a specific point?