| Summary: | GRUB2: error efibootmgr fails | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Marc Krämer <mageia> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins |
| Version: | 9 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | grub2 | CVE: | |
| Status comment: | |||
|
Description
Marc Krämer
2024-01-16 11:19:22 CET
I suspect this was an install where the installation media was booted by selecting the efi mode entry from the uefi boot menu, but when the rescue is being run, the iso being booted was booted by selecting the bios compatibility mode uefi boot menu entry. When the iso is booted in bios compatibility mode, the nvram storage is not made available by the uefi firmware for the kernel to access it. It's physically impossible to mount /sys/firmware/efi/efivars. When booting an iso, it MUST be booted in the same mode that was used for prior installations. The terminology used in the uefi menu varies between vendors, and even between models and firmware versions by the same vendor. Various screen shots are available by doing an image search for "uefi with csm or without csm" CSM stands for "Compatibility Support Module". By the time the iso has started to boot, the decision of whether the system is using uefi firmware mode or legacy bios firmware mode has been made. It can not be changed by any software on the iso image. CC:
(none) =>
davidwhodgins Nope. I get this error on almost any running mageia which boots on efi. This specific output comes from magei-netinstall boot-stick where I tried to reinstall the bootloader (reregister the efi entry). The entry was removed from the bios by an firmware update :( On my aarch64 rpi 4b which uses grub2-efi, the path is /boot/EFI/EFI/mageia/ though a symlink does exist. [dave@rp4 ~]$ ll /boot/EFI/EFI/ total 8 drwxrwxrwx 2 root root 4096 Mar 21 2022 BOOT/ drwxrwxrwx 2 root root 4096 Sep 1 11:48 mageia/ [dave@rp4 ~]$ ll /boot/EFI/EFI/mageia/ total 164 -rwxrwxrwx 1 root root 167936 Oct 30 00:14 grubaa64.efi* [dave@rp4 ~]$ ll /boot|grep -i efi drwxrwxrwx 3 root root 4096 Dec 31 1969 EFI/ lrwxrwxrwx 1 root root 3 Feb 20 2021 efi -> EFI/ [dave@rp4 ~]$ ll /boot/EFI|grep -i efi drwxrwxrwx 4 root root 4096 Mar 21 2022 EFI/ [dave@rp4 ~]$ ll /boot/EFI/EFI total 8 drwxrwxrwx 2 root root 4096 Mar 21 2022 BOOT/ drwxrwxrwx 2 root root 4096 Sep 1 11:48 mageia/ [dave@rp4 ~]$ ll /boot/EFI/EFI/mageia/ total 164 -rwxrwxrwx 1 root root 167936 Oct 30 00:14 grubaa64.efi* Does the symlink exist? $ file /boot/efi /boot/efi: symbolic link to EFI Is the file system mounted and a vfat file system? $ mount|grep -i efi efivarfs on /sys/firmware/efi/efivars type efivarfs (ro,nosuid,nodev,noexec,relatime) /dev/mmcblk0p1 on /boot/EFI type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro Note the /boot/EFI being mounted with errors=remount-ro If it's being remounted ro due to errors, you'll need to run fsck.vfat on the file system to correct them. Looking back at the description above though, the message ... grub2-install: Info: executing modprobe -q efivars. EFI variables are not supported on this system indicates an attempt to boot in bios compatibility mode caused by selecting the wrong uefi menu entry. Hmm, I'll check that. I guess you might be right. closing Status:
NEW =>
RESOLVED |