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

My mirrors aren’t showing an updated grub, so…no it’s not fixed (unless I’m out of date).
I’m quite disappointed in how long this has remained an issue upstream.

Great place to look…

https://archlinux.org/packages/?sort=-last_update

1 Like

I got to step 8. then terminal prints this error

[root@EndeavourOS /]# sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=EndeavourOS-grub
Installing for x86_64-efi platform.
grub-install: error: /boot/efi doesn't look like an EFI partition.

Does anyone know whats the issue here?

Disk /dev/sda: 256.17 GiB, 275064201216 bytes, 537234768 sectors
Disk model: Crucial_CT275MX3
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6C90BC5C-7D01-5148-9B0A-52DAD03757DA

Device         Start       End   Sectors  Size Type
/dev/sda1       2048    616447    614400  300M EFI System
/dev/sda2     616448 107149311 106532864 50.8G Microsoft basic data
/dev/sda3  107149312 189069311  81920000 39.1G Linux filesystem
/dev/sda4  189069312 537233407 348164096  166G Microsoft basic data


Disk /dev/sdb: 14.32 GiB, 15376000000 bytes, 30031250 sectors
Disk model: Ultra USB 3.0   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x002a9742

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdb1  *     2048 30031249 30029202 14.3G  c W95 FAT32 (LBA)```

You probably mounted the wrong partition in /boot/efi

Reboot on the Live USB (to clear any mount actions).

Try:

sudo mount /dev/sda3 /mnt
sudo mount /dev/sda1 /mnt/boot/efi

then sudo arch-chroot /mnt

3 Likes

I’m getting an error that /boot/efi doesn’t look like an EFI partition when i try to do the 2nd command in the Grub Fixes article in the stickied post.

may this will get moved–


post the output of:

efibootmgr
lsblk -f

That did the job.

Thank you! :+1:

You’re welcome ! :slight_smile:

@makeixo I got the same error and had I seen that above from @joekamprad would not have resorted to a clean Artemis install.

It solved the booting problem, but I lost some important ssh keys, so it was not without consequences and of course retoring all my packages.

A refeshingly honest admission Rick.

It seems that until now no one was prepared to accept that following the same set instructions to the letter on different systems, in a small number of cases did not solve the boot problem.

No matter what I did, it stopped at the grub rescue mode prompt.

After seriously studying all the docs on rEFInd, I think we will be giving the GRUB (GRand Unified Bootloader) the :boot:

I agree with you because the other two (rEFInd and sytemd-boot) seems simpler (I prefer KISS in general)

I personally settled for systemd-boot because it seems to me the simplest (as my humble knowledge it is easy to maintain/fix in case needed, though by design and simplicity it will just work)

The only con, I can’t boot to an earlier snapshot! But still it is possible to restore a a snapshot.

So you can boot to snapshots you made since going to systemd and rEFInd, but not previous ones?

Are you using btrfs assistant?

You can’t reliably boot to snapshots with systemd-boot.

You can with refind, but it requires the proper setup and configuration.

1 Like

What I know is:

  • systemd-boot does not support sanapshots
  • Grub supports snapshots. (I tried before the Grub breaking)
  • I am not sure about rEFInd… haven’t used it with BTRFS.

Yes I am on BTRFS.
As far as I understood from @dalto, the worst case:

  • I can boot to a live session (from the flash disk or cd I installed from)
  • install BTRFS Assistant in the live session
  • mount the partition you previously had snapshots on
  • Restore a snapshot.
    But honestly I did not try the last two points.

If I knew that I would have restored a previous snapshot with a working Grub instead of making a fresh install.

So, I think from my post I understand a little about the snapshot story with no Grub? Did I get it right?

Worst case scenario install BTRFS Assistant and restore.

But generally speaking if systemd-boot runs it just runs. You would not need to do this (unless an update breaks the system! If this happens I can boot to the other kernel?)

Depends on how you define “simple”. systemd-boot is simple as in less features and less confusion. But it is not capable of detecting any OS IIRC. Also rEFInd is the “install and forget” type of bootloader thanks to autodetection but it is also very configurable.
For example, my PC boots a manually configured rEFInd and if I want snapshot booting, I chainload GRUB. Best of both worlds :innocent:

This is how I restored a snapshot from live USB, systemd-boot, using btrfs-assistant:

If the version of your kernel hasn’t changed, this is correct. If the snapshot has a different kernel version you will also need to chroot in and reinstall the kernel.

It will detect Windows and automatically add it to the boot menu. The fact that it doesn’t try to detect other Linux installs is, IMO, one of it’s best features. It allows each distro to add an entry for itself so each distro controls it’s own entries and they never step on each other.

1 Like

It looks like there are a few extra steps in there but they won’t hurt anything. :smile:

1 Like