On system update, Grub throws an error regarding EFI

Support
41

Thanks for your fast reply. Well, I run first grub-install (not install-grub) and afterwards I see that the boot order is correct. But everytime I reboot, it is lost and it is again as it was before where the relevant entry is absent from the boot order.

42

It is possible that your CMOS battery needs replacing. It’s a cell-type battery that powers both the non-volatile memory of your firmware and your real-time clock.

1 Like
43

Erm, I do not turn off my computer in between, I just reboot it. It is also not forgetting other “BIOS” settings, like password and time.

44

This is strange.

There is one more thing you can try - install to the fallback location which in theory will work even if there are no efi variables set.

The same procedure with the chroot, but with

grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable
45

There was already a poll about this subject in 2023:

1 Like
46

Indeed. And manjaro-reinstall-grub was the winner.

49

Boom, I have just noticed that this went under my radar for exactly one year:

[2024-10-08T08:20:50+0200] [ALPM] running '98-install-grub.hook'...
[2024-10-08T08:20:50+0200] [ALPM-SCRIPTLET] EFI variables are not supported on this system.
[2024-10-08T08:20:50+0200] [ALPM-SCRIPTLET] Grub will be installed on: EFI
[2024-10-08T08:20:50+0200] [ALPM-SCRIPTLET] x86_64-efi wird fĂźr Ihre Plattform installiert.
[2024-10-08T08:20:52+0200] [ALPM-SCRIPTLET] Installation beendet. Keine Fehler aufgetreten.
[2024-10-08T08:20:52+0200] [ALPM-SCRIPTLET] GRUB-Konfigurationsdatei wird erstellt …
[2024-10-08T08:20:52+0200] [ALPM-SCRIPTLET] Linux-Abbild gefunden: /boot/vmlinuz-6.6-x86_64
[2024-10-08T08:20:52+0200] [ALPM-SCRIPTLET] Initrd-Abbild gefunden: /boot/intel-ucode.img /boot/initramfs-6.6-x86_64.img
[2024-10-08T08:20:52+0200] [ALPM-SCRIPTLET] Found initrd fallback image: /boot/initramfs-6.6-x86_64-fallback.img
[2024-10-08T08:20:52+0200] [ALPM-SCRIPTLET] Warnung: Zur Erkennung anderer bootfähiger Partitionen wird os-prober nicht ausgefßhrt.
[2024-10-08T08:20:52+0200] [ALPM-SCRIPTLET] Die darauf befindlichen Systeme werden nicht zur GRUB-Bootkonfiguration hinzugefĂźgt.
[2024-10-08T08:20:52+0200] [ALPM-SCRIPTLET] Schauen Sie in den Dokumentationseintrag GRUB_DISABLE_OS_PROBER.
[2024-10-08T08:20:52+0200] [ALPM-SCRIPTLET] Bootmenü-Eintrag für UEFI-Firmware-Einstellungen wird hinzugefügt …
[2024-10-08T08:20:52+0200] [ALPM-SCRIPTLET] Found memtest86+ image: /boot/memtest86+/memtest.bin
[2024-10-08T08:20:52+0200] [ALPM-SCRIPTLET] abgeschlossen
[2024-10-08T08:20:52+0200] [ALPM-SCRIPTLET] Warning: GRUB bootloader at /boot/efi/EFI/manjaro was updated,
[2024-10-08T08:20:52+0200] [ALPM-SCRIPTLET] but it seems like you are not using it by default.
[2024-10-08T08:20:52+0200] [ALPM-SCRIPTLET] Please check your EFI boot priorities!
[2024-10-08T08:20:52+0200] [ALPM] running '99-update-grub.hook'...
[2024-10-08T08:20:53+0200] [ALPM-SCRIPTLET] GRUB-Konfigurationsdatei wird erstellt …
[2024-10-08T08:20:53+0200] [ALPM-SCRIPTLET] Linux-Abbild gefunden: /boot/vmlinuz-6.6-x86_64
[2024-10-08T08:20:53+0200] [ALPM-SCRIPTLET] Initrd-Abbild gefunden: /boot/intel-ucode.img /boot/initramfs-6.6-x86_64.img
[2024-10-08T08:20:53+0200] [ALPM-SCRIPTLET] Found initrd fallback image: /boot/initramfs-6.6-x86_64-fallback.img
[2024-10-08T08:20:53+0200] [ALPM-SCRIPTLET] Warnung: Zur Erkennung anderer bootfähiger Partitionen wird os-prober nicht ausgefßhrt.
[2024-10-08T08:20:53+0200] [ALPM-SCRIPTLET] Die darauf befindlichen Systeme werden nicht zur GRUB-Bootkonfiguration hinzugefĂźgt.
[2024-10-08T08:20:53+0200] [ALPM-SCRIPTLET] Schauen Sie in den Dokumentationseintrag GRUB_DISABLE_OS_PROBER.
[2024-10-08T08:20:53+0200] [ALPM-SCRIPTLET] Bootmenü-Eintrag für UEFI-Firmware-Einstellungen wird hinzugefügt …
[2024-10-08T08:20:53+0200] [ALPM-SCRIPTLET] Found memtest86+ image: /boot/memtest86+/memtest.bin
[2024-10-08T08:20:53+0200] [ALPM-SCRIPTLET] abgeschlossen

In the meanwhile, I have removed the other entry which is detected by the live boot loader. But I still cannot make it boot.

One question: Is it possible that support of my old hardware (9 years old) got dropped?

So, to summarise:

  • In EFI mode → No bootable device
  • In Legacy mode: Grub in rescue mode with the error message error: file ‘/boot/grub/i386-pc/boot.mod’ not found
50

For the time being, I could fix it by forcing Legacy mode:

# LC_ALL=C grub-install --force --target=i386-pc --recheck --boot-directory=/boot /dev/sda 
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
Installation finished. No error reported.

However, I am not sure if this is the correct solution.

51

This seems to confirm what I suspected; looks like the partition table wasn’t set up for Legacy boot and GRUB appears to be taking over the EFI partition for this.

The “No bootable device” message does rather point to a hidden UEFI setting (accessible only via administrator password) where secure boot needs to be disabled? :man_shrugging: I’ve had to deal with this on a couple of occasions with an Acer machine with a failing CMOS cell.

52

@rexkogitans

A question or two to help understand your scenario…

Are you (or have you previously been) multi-booting with Windows on that disk? The relative size of the $ESP tends to indicate that you have (the $ESP defaults to 300 MB on a typical Manjaro install).

Please provide the outputs of;

lsblk -f

…and…

sudo tree -d /boot/efi/EFI
1 Like
53

This is an Acer Swift 3 which is 8 years old now. I would not be surprised if the CMOS battery was empty, but it does not show other symptoms like forgetting the time when switched off.

When I bought this computer, it had a Windows on it. The first thing I did back in 2017 was replacing it with Manjaro Linux. IIRC, the size of 100 MB was set manually by me during installation.

# lsblk -f
NAME   FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                           
├─sda1 vfat   FAT32       50CD-CDFC                              99,2M     0% /boot/efi
├─sda2 ext4   1.0         91eafab7-9744-4637-9577-fc0155925324  940,2M    90% /
├─sda3 swap   1           764f03c4-86f4-4321-95b2-a1288584e771                [SWAP]
├─sda4 ext4   1.0         4fc714b2-8f1e-4669-8697-4d2a5cf6d378    2,7G    89% /home
└─sda5 ext4   1.0         1d46b8ec-0da1-4047-8a8a-0096fd485c2c   10,4G    73% /data
# tree -d /boot/efi/EFI/
/boot/efi/EFI/
└── manjaro

2 directories
54

Since there is obviously some peculiarity with the efi variables on this system, you can try the woraround i mentioned above with the --removable option.
Changing the battery is of course a good idea. Those can fail anywhere between 5 and 10-15 years, so it could be it.
And if we go with the hypothesis that the efi forgets its memory on reboot it is also good to check if the secure boot setting is still disabled. Although that should have thrown a different error, but who knows.

3 Likes
55

/EFI/boot – also known as the fallback location on your $ESP – appears to be completely missing, which also means a required file ( /EFI/boot/bootx64.efi) is likewise missing.

You might be able to re-create both the directory and file manually:

sudo mkdir /boot/efi/EFI/boot
sudo cp /boot/efi/EFI/manjaro/grubx64.efi /boot/efi/EFI/boot/bootx64.efi

Then check the results:

sudo tree -d /boot/efi/EFI
sudo tree -f /boot/efi/EFI

There should now be a /EFI/boot/bootx64.efi.
If the directory and file were created, reboot to test.

Note: Your system must already be configured to boot as UEFI, and depending on the state of your system, this may need to be done via a chroot environment.

2 Likes
56

That is also what i meant. Alternative to the --removable option is just manually copying the file.

1 Like
57

Or running install-grub. :man_shrugging:

58

If the boot method would accidentally change from EFI to Legacy the surprise would be why the system would still boot.

The “EFI variables are not supported on this system.” message indicates you were running on Legacy mode. Perhaps this was always the case since 2017 or did you reinstall the system at some point? The install-grub package was introduced last year around the time and I think it won’t be installed automatically since I never had this on my systems.

Now assuming you installed on Legacy originally the only questions would be why the BIOS Boot Partition is missing and where the EFI stuff comes from. Maybe you were always on blocklists without noticing until now?

Well, the device is always part of the equation. Perhaps there is a BIOS update available (on the Acer support site) fixing some issues? At least you can boot on EFI, too, just with manual selection - could be worse :man_shrugging:

61

There are two untypical details:
Your ESP is starting already at block 34, (i.e. no proper alignment, usual block 2048 would be desirable) and it’s rather small. Maybe, when booting in BIOS mode and restoring the boot loader, grub was trying to store core.img behind GPT’s partition entry array because of not finding a BIOS_grub partition and this damaged the ESP, accidently. I would try to boot in UEFI mode via Manjaro live ISO, reformat the ESP, manjaro-chroot and then to restore the boot loader.

3 Likes
62

This indeed seems possible, given peripheral factors; a hybrid boot might have been in place (whether by accident or intent) since the OS was installed.