if you try to reinstall the bootloader (efi), it fails because efivars is not loaded. And it is not included in the image
LANGUAGE=C grub2-install /dev/sda Installing for x86_64-efi platform. EFI variables are not supported on this system. EFI variables are not supported on this system. grub2-install: error: efibootmgr failed to register the boot entry: No such file or directory. grub2-install: info: reading /usr/lib/grub/x86_64-efi/jfs.mod. grub2-install: info: reading /usr/lib/grub/x86_64-efi/part_gpt.mod. grub2-install: info: kernel_img=0x11826c0, kernel_size=0x1f000. grub2-install: info: the core size is 0x220b0. grub2-install: info: writing 0x26000 bytes. grub2-install: info: copying `/boot/grub2/x86_64-efi/core.efi' -> `/boot/efi/EFI/mageia/grubx64.efi'. grub2-install: info: Registering with EFI: distributor = `mageia', path = `\EFI\mageia\grubx64.efi', ESP at hostdisk//dev/sda,gpt1. grub2-install: info: executing efibootmgr --version </dev/null >/dev/null. grub2-install: info: executing modprobe -q efivars. EFI variables are not supported on this system. grub2-install: info: executing efibootmgr -c -d /dev/sda -p 1 -w -L mageia -l \EFI\mageia\grubx64.efi. EFI variables are not supported on this system. grub2-install: error: efibootmgr failed to register the boot entry: No such file or directory.
https://wiki.mageia.org/en/Installing_on_systems_with_UEFI_firmware#How_to_distinguish_between_UEFI_and_BIOS_mode_for_Mageia_boot_media The efi variables not supported indicates a system that was booted in bios firmware mode.
CC: (none) => davidwhodgins
Nope. The module is not available! Modprobe stated "file not found"
I'd suggest removing the "-q" switch from modprobe, so we get the output from that call as well.
to be precise: while grub2-install is running, modprobe must fail, as it runs in a chroot environment, where the kernel modules are not available (for the kernel used in rescue). But apart from that, I quit the chroot env, and did a modprobe, which told me, the module is not found in the kernel dir.
See https://bugs.mageia.org/show_bug.cgi?id=31008#c3
Thanks Dave for your input. Marc, did you try the indicated URL: "The temporary workaround is to wait until the installer reaches the Summary screen, then switch to the debug console by pressing Ctrl-Alt-F2 (or emulating that key press if you are using QEMU), entering the command mount -t efivarfs none /mnt/sys/firmware/efi/efivars then switching back to the installer GUI by pressing Ctrl-Alt-F7 and continuing with the installation." https://bugs.mageia.org/show_bug.cgi?id=31008#c11 "This was fixed in the second round of alpha1 ISOs, dated Sat Oct 29 ... 2022. I have just retested and confirmed the fix." On my EFI system: $ sudo modprobe -n efivars modprobe: FATAL: Module efivars not found in directory /lib/modules/6.6.28-desktop-1.mga9 but unsure if that is the right command. OTOH $ sudo lsmod | grep efi efivarfs 24576 1 & efibootmgr works. But $ sudo modinfo efivars modinfo: ERROR: Module efivars not found. Confusing!
CC: (none) => lewyssmith
if this is the case, that no module is needed anymore, why does grub2-install still try to load it, and does not try to do the mount as stated? Sorry - if you have to do a remote debugging session with a mageia laptop that does not boot anymore (grub2 stated some symbols were missing after the last update) and you have to guide a "stupid user" through the rescue system only via telephone - you don't have the time to find such information. And I'm not thinking about spelling someone this command: mount -t efivarfs none /mnt/sys/firmware/efi/efivars at least we could provide a "command" like "loadkeys" to do the mount. But really - if the system does not start anymore and you try to repair it, we should not have such culprits
It is late; need to research the basic error message "EFI variables are not supported on this system." Something is wrong. Tomorrow... > if you try to reinstall the bootloader (efi), it fails because efivars is > not loaded. And it is not included in the image grub2-install: info: executing modprobe -q efivars Certainly it looks as if this command is redundant. But it may be harmless, since efibootmgr etc work. Another case where Martin might have a useful comment.
CC: (none) => mageia
As noted in https://bugs.mageia.org/show_bug.cgi?id=31008#c3, efivars was removed in Linux 6.0. efivarfs is the replacement. grub2 still has support for both, trying the newer efivarfs first and falling back to efivars if that fails. This bug appears to be a duplicate of bug 31844, which I believed was fixed. And retesting in VirtualBox using the rescue system on the Mageia-9-x86_64.iso, it works. Which ISO are you using Marc?
I used the netinstaller, then started the rescue system. The command was executed in an up-to-date chroot env of the system which did not boot. The rescue system reported, reinstall bootloader failed, mounting partions failed. I guess the mount command must be integrated into the grub2-install command, in case this is not mounted to sys, like it is trying to add the module.
If the rescue system can't mount your root filesystem then it can't automatically mount the efivarfs filesystem within that filesystem, because the mount point doesn't exist. You haven't clearly stated what you did, but I'm guessing at: 1. Use the "Reinstall Boot Loader" option from the rescue system menu. 2. See that fail because it couldn't mount your root filesystem. 3. Use the "Go to console" option from the rescue system menu. 4. Manually mount the partition with the root filesystem on /mnt. 5. Run "chroot /mnt". 6. Run "install-grub2". If that wasn't what you did, please say precisely what you did do. If that was what you did, then you also needed to manually mount the efivarfs at /mnt/sys/firmware/efi/efivars. But the real question is why the rescue system couldn't mount your root filesystem and do the job automatically.
Thank you for your comments, Martin. I think detailed information of the disc/ESP might be useful.
Sorry, I have opened 2 tickets; one for efivars (this) and the other one for the rescuesystem itself. This bugtracker does not provide "references to other bugs",only depends/blocks which was not my intention - but now added as "dependend" The discimage etc. is visible there. The procedure you are describing is exactly what I did. Maybe the grub2-install script could give a better hint. Since the modprobe command was obvious it failed, I never thought about checking that newer kernels need to mount efivars. (btw. I'll be on holiday, so I can reply you after being back)
Depends on: (none) => 32723
I guess you could patch our grub2 package to remove the now obsolete 'modprobe -q efivars' command, although the error messages you see don't come from that, they come from efibootmgr, which grub2-install runs to examine and modify the EFI NVRAM boot variables.
I think we can leave Grub as-is. You said elsewhere it only tries efivars if it does not find efivarfs. I think this matters: (In reply to Martin Whitaker from comment #12) > If the rescue system can't mount your root filesystem then it can't > automatically mount the efivarfs filesystem within that filesystem, because > the mount point doesn't exist. > > But the real question is why the > rescue system couldn't mount your root filesystem and do the job > automatically.