[SOLVED] EFI variables are not supported on this system

[halcon]

Hello, all.

It is a lot I haven't posted here.

I just updated (an usual emerge -vuND) a laptop via ssh. After that, as always when updated grub2, I launched grub-install. For not mixing grub options of this laptop with others, I copied accurately the exact command from this laptop bash history:

Code: Select all

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

But this time it doesn't work. It says

Code: Select all

Installing for x86_64-efi platform.
EFI variables are not supported on this system.
EFI variables are not supported on this system.
grub-install: error: efibootmgr failed to register the boot entry: No such file or directory.

I wonder, how is that possible, given that I used to use this command many times on this laptop. I took it from history. There are many entries of grub-install, and all of those with the same options.

Code: Select all

mount | grep boot
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=866,iocharset=utf8,shortname=mixed,errors=remount-ro)

ls -al /boot/efi
total 12
drwx------ 3 root root 4096 Jan  1  1970 .
drwxr-xr-x 4 root root 4096 Mar  2 00:30 ..
drwx------ 5 root root 4096 May 31  2021 EFI

file /sys/firmware/efi/efivars
/sys/firmware/efi/efivars: directory

cat /etc/portage/make.conf | grep GRUB
GRUB_PLATFORMS="efi-64"

What am I missing?

Edit:
The Gentoo system from which I am ssh'ing, was installed without efi support.

Edit2:

Code: Select all

lsmod | grep efivarfs

does not show nothing...

Edit3:

Code: Select all

modprobe efivarfs
modprobe: FATAL: Module efivarfs not found in directory /lib/modules/6.1.14-gentoo-v22

Edit4:
I remember, one time I couldn't boot this laptop, it didn't show the boot grub menu, just a black screen; I had to do a hard-reset (pushing power button for 10 sec). Possible issues with the SSD?

Edit5:
Should I run this command, as suggested in Gentoo efibootmgr wiki?

Code: Select all

mount -o remount,rw -t efivarfs efivarfs /sys/firmware/efi/efivars

But I don't understand why... Never ran it before.

[pietinger]

Maybe you are missing it in your kernel configuration. Be sure to have:

Code: Select all

Device Drivers  --->
    Firmware Drivers  --->
        EFI (Extensible Firmware Interface) Support  --->
# We need EFI runtime services for "efibootmgr" and disable the "Disable", so it is enabled ;-)
            [ ] Disable EFI runtime services support by default

File systems  --->
    Pseudo filesystems  --->
        <*> EFI Variable filesystem

(from: https://wiki.gentoo.org/wiki/User:Pieti ... Must_Haves )

[halcon]

Maybe you are missing it in your kernel configuration. Be sure to have:

Code: Select all

Device Drivers  --->
    Firmware Drivers  --->
        EFI (Extensible Firmware Interface) Support  --->
# We need EFI runtime services for "efibootmgr" and disable the "Disable", so it is enabled ;-)
            [ ] Disable EFI runtime services support by default

File systems  --->
    Pseudo filesystems  --->
        <*> EFI Variable filesystem

(from: https://wiki.gentoo.org/wiki/User:Pieti ... Must_Haves )

Really...

Code: Select all

zgrep CONFIG_EFI /proc/config.gz 
CONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_EFI_MIXED=y
CONFIG_EFI_PARTITION=y
CONFIG_EFI_ESRT=y
# CONFIG_EFI_FAKE_MEMMAP is not set
CONFIG_EFI_DXE_MEM_ATTRIBUTES=y
CONFIG_EFI_RUNTIME_WRAPPERS=y
CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER=y
# CONFIG_EFI_BOOTLOADER_CONTROL is not set
# CONFIG_EFI_CAPSULE_LOADER is not set
# CONFIG_EFI_TEST is not set
CONFIG_EFI_DEV_PATH_PARSER=y
# CONFIG_EFI_RCI2_TABLE is not set
# CONFIG_EFI_DISABLE_PCI_DMA is not set
CONFIG_EFI_EARLYCON=y
# CONFIG_EFI_CUSTOM_SSDT_OVERLAYS is not set
# CONFIG_EFI_DISABLE_RUNTIME is not set
# CONFIG_EFI_COCO_SECRET is not set
# CONFIG_EFIVAR_FS is not set
# CONFIG_EFI_PGT_DUMP is not set

But how has this laptop been booting all these years? It is not a new install.

[pietinger]

Yes, you have found it:

Code: Select all

# CONFIG_EFIVAR_FS is not set

P.S.: This is only needed for "chating" with UEFI ... e.g. for "efibootmgr" ... BUT NOT for booting.

[halcon]

P.S.: This is only needed for "chating" with UEFI ... e.g. for "efibootmgr" ... BUT NOT for booting.

Aha

So, I can safely ignore these error messages; grub-install did all that is necessary for booting; do I understand right?

[grknight]

P.S.: This is only needed for "chating" with UEFI ... e.g. for "efibootmgr" ... BUT NOT for booting.

Aha

So, I can safely ignore these error messages; grub-install did all that is necessary for booting; do I understand right?

GRUB has done everything except inform the system firmware which image to boot. Normal calls invoke efibootmgr automatically.

When this fails, you can either use the --removable option to place an image to the common backup location or else, if it allows, inform the system firmware of the new image location manually in its menu system.

[pietinger]

So, I can safely ignore these error messages; grub-install did all that is necessary for booting; do I understand right?

No. You will need it, because the installation routine of grub uses "efibootmgr" to talk to your UEFI (telling UEFI about a new boot entry for itself). You must have efivarfs before installing grub.

[halcon]

inform the system firmware of the new image location manually in its menu system.

I see!

As I said, it is an old install, and I haven't changed anything in its boot options for a long time. And yes, its grub is configured manually via:

Code: Select all

menuentry "Gentoo Linux x86_64 6.1.14 v22" --class gentoo --users "" {
        load_video
        insmod gzio
        insmod part_gpt
        insmod fat
        set root='hd0,gpt4'
        linux /boot/vmlinuz-x86_64-6.1.14-gentoo-v22 root=/dev/sda4 rootfstype=ext4 resume=/dev/sda5 net.ifnames=0 rcu-nocbs=0-15 idle=nomwait spec_store_bypass_disable=on acpi=force acpi_osi=linux i8042.nopnp snd-hda-intel.index=1,0 acpi_enforce_resources=lax xhci_hcd.quirks=270336 apm=power_off
}

Should it be enough?

I wonder if there were no these efibootmgr error messages before, or I didn't notice them?

[halcon]

the installation routine of grub uses "efibootmgr" to talk to your UEFI (telling UEFI about a new boot entry for itself)

Considering my manual configuration above, should it work? (Continue to work)

[grknight]

inform the system firmware of the new image location manually in its menu system.

I see!

As I said, it is an old install, and I haven't changed anything in its boot options for a long time. And yes, its grub is configured manually via:

Not GRUB's menu, your system firmware (which some mistakenly call BIOS still) menu must point to the GRUB EFI file location (often grubx64.efi). This is what the failed messages are referring to.

[halcon]

Not GRUB's menu, your system firmware (which some mistakenly call BIOS still) menu must point to the GRUB EFI file location (often grubx64.efi)

So low-level... Then I have to repeat the question: how has this laptop been successfully booting for several years? It failed only one time, and hard-reset helped.

Edit:
And other question: if, let us think that it has been booting for some unknown magic , and won't do that again, can I fix this by just re-compiiing the kernel? This kernel won't be loaded, just compiled and moved to the boot directory. I guess, it won't be enough for efibootmgr to be able to inform the system firmware about grubx64.efi, as it is supposed? So, if doing everything according to the rules, someone has to reboot this laptop with a CD/DVD? it is impossible in this moment...

[NeddySeagoon]

halcon,

efivars are not required for booting. Its an interface that the kernel uses to expose the efivars to user space.
Its of no interest until the kernel is running as it cannot exist.

Updating from one grubx64.efi to another grubx64.efi does not require any efivar changes, its the same file name in the same EFI/.../ location.

The EFI firmware reads grubx64.efi usung the path stored in the efivars and its not changed.
Only the file content has changed. The EFI firmware won't care.

efivars are required to make new entries. Like if you wanted to add syslinux beside grub, so the EFI firmware could boot either.

From the point of view of the EFI firmware. Nothing has changed, so the error can be ignored.
Were this the first install of grub, it would matter a geat deal. The EFI firmware boot entry for grub would be missing.

[halcon]

NeddySeagoon,

The EFI firmware reads grubx64.efi usung the path stored in the efivars and its not changed.
Only the file content has changed. The EFI firmware won't care.

A very good news!

Were this the first install of grub, it would matter a geat deal. The EFI firmware boot entry for grub would be missing.

You made me understand how, maybe, this *magic situation* could arise. I bought this laptop with Mint installed (or did I install Mint myself? oh my memory... I don't remember). In any case, there was Mint before. After some time, I moved it to Gentoo. I don't remember all the details, how I was doing that, maybe in some moment of time there were both on one SSD, and, so, it could explain the magic?

Edit:
Yes, exactly, they both co-existed on one SSD, I remember that I compared the functionality presented in Mint with that in Gentoo.

[halcon]

Thank you very much, all who replied!

It's been very nice to talk to you again

When this laptop is rebooted, I will make a new post (or edit this one).

[sMueggli]

You could add "--no-nvram" to the "grub-install" command and the "error" should not appear, as the boot entries in the NVRAM are not touched/updated.

[halcon]

You could add "--no-nvram" to the "grub-install" command and the "error" should not appear, as the boot entries in the NVRAM are not touched/updated.

A good hint! Thank you.

[halcon]

...Laptop rebooted, everything boots like a charm

[Frautoincnam]

Code: Select all

# CONFIG_EFIVAR_FS is not set

But how has this laptop been booting all these years? It is not a new install.

I had EXACTLY the same situation today after updating grub 2.06-r7 to 2.06-r8.
Solved in EXACTLY the same way.
Thanks

[dpaddy]

I had faithfully followed the installation document but nothing would work for me until the following:

Code: Select all

 grub-install --efi-directory=/efi --target=x86_64-efi --no-nvram 

I conjecture the issue was related to my attempt to install using an old rescue usb that performed a legacy boot.

This thread saved my bacon. THANKS

OUT OF PLACE COMMENT: I believe it would be helpful to include the command above in the installation documentation... I tried and failed to do so (neither can I manage using the "talk" feature), so perhaps someone less inept than I might do it