Description of problem: Installing from the image Mageia-9-alpha1-x86_64.iso (Sat Oct 22 09:14:15 PM CEST 2022) in to a QEMU/KVM (EFI) virtual machine fails at the final stages when setting up the EFI boot loader with the messages "EFI variables are not supported on this system" and "efibootmgr failed to register a boot entry: file or directory does not exist". See attached screenshot image and report. Version-Release number of selected component (if applicable): Mageia-9-alpha1-x86_64.iso (Sat Oct 22 09:14:15 PM CEST 2022) How reproducible: Always. Steps to Reproduce: 1. Setup a QEMU/KVM virtual machine. 2. Boot from Mageia-9-alpha1-x86_64.iso (Sat Oct 22 09:14:15 PM CEST 2022). 3. Add a HTTP repository (don't know if this is relevant, may not be needed). 4. Install to a virtual drive.
Created attachment 13438 [details] Install report.
Created attachment 13439 [details] Screen shot of error messages.
This occurs because the Linux 6.0 kernel has removed the old and deprecated interface to the EFI variables which was previously found at /sys/firmware/efi/vars. The new way to access the EFI variables is to mount the efivarfs filesystem at /sys/firmware/efi/efivars, but this is not done by the installer. 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.
CC: (none) => mageiaPriority: Normal => release_blockerAssignee: bugsquad => mageiatoolsSource RPM: (none) => drakx-installer-stage2
Interestingly it might/should work if you choose refind as bootloader as that already checks for efivars being mounted :)
ah, its part of write_refind_previous_boot_var(), so need more work. I guess we should factor out that checking/mounting/unmounting efivarfs and hook it into needed places...
(In reply to Martin Whitaker from comment #3) > This occurs because the Linux 6.0 kernel has removed the old and deprecated > interface to the EFI variables which was previously found at > /sys/firmware/efi/vars. The new way to access the EFI variables is to mount > the efivarfs filesystem at /sys/firmware/efi/efivars, but this is not done > by the installer. > > 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. When I do this I get the following error during bootloader installation: Error: <Installing for x86_64-efi platform. Could not prepare Boot variable: Function not implemented grub2-install: error: efibootmgr failed to register the boot entry: input/output error ...propagated at /usr/lib/libDrakX/any.pm line 278
CC: (none) => ftg
(In reply to Frank Griffin from comment #6) > When I do this I get the following error during bootloader installation: > > Error: <Installing for x86_64-efi platform. > Could not prepare Boot variable: Function not implemented > grub2-install: error: efibootmgr failed to register the boot entry: > input/output error > ...propagated at /usr/lib/libDrakX/any.pm line 278 That would appear to be a different issue. Best open a new bug report for that.
Status comment: (none) => fix added in git
CC: (none) => bequimao.de
(In reply to Martin Whitaker from comment #3) > mount -t efivarfs none /mnt/sys/firmware/efi/efivars That command solved the issue. The installation completed correctly and the system booted to a working Plasma desktop, after entering the username/password. Thanks.
I confirm the bug on Mageia9-alpha1 iso when installing on efi x86_64 system
CC: (none) => contact
The fix will be include in the next ISO build.
Status comment: fix added in git => fixed in drakx-installer-stage2-18.51
This was fixed in the second round of alpha1 ISOs, dated Sat Oct 29 07:52:30 PM CEST 2022. I have just retested and confirmed the fix.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED