My motherboard is UEFI but I think the efivarfs module don’t support it, every time I try to mount the efivar partition I get fsopen operation not supported, and efibootmgr returns EFI variables are not supported also modprobed efivarfs, and yes I’m sure im booting with uefi,
Is possible to install fedora KDE without touching efivars?
Absolutely - you shouldn’t have to do anything with efivars at all to install Fedora (or any other Linux system for that matter). What makes you think you do - what are you trying to accomplish, or what error message is making you think you have efi fiddling to perform?
What model is the board? I wonder if other users have had the same problem with the same hardware.
The thing is, anaconda seems to be hard coded to use efivars on the start of the installation and it fails
OK - can you post the anaconda log showing the failure or at least the error message it fails with - details are going to be required to troubleshoot your issue.
It’s a local brand Pichau b550m-chronos (probably some Chinese white label remark) and it’s running the latest bios
here Jan 30 15:45:10 localhost-live org.fedoraproject.Anaconda.Modules.Storage[4538]: - Pastebin.com
It appears to read efivars without any issues in line 43-45
Jan 30 15:45:10 localhost-live org.fedoraproject.Anaconda.Modules.Storage[4538]: DEBUG:blivet: EFIVarFS.setup: device: efivarfs ; type: efivarfs ; status: False ;
Jan 30 15:45:10 localhost-live org.fedoraproject.Anaconda.Modules.Storage[4538]: INFO:program:Running... udevadm settle --timeout=300
Jan 30 15:45:10 localhost-live org.fedoraproject.Anaconda.Modules.Storage[4538]: DEBUG:program:Return code: 0
The error I see is in mounting the ext4 device at /dev/sda2, which as you’ve not formatted or installed anything yet, I assume can only be from the live media you’re using to boot this live environment.
Jan 30 15:45:10 localhost-live anaconda-webui[5199]: ErrorBoundary caught an error: mount failed: fsopen() failed: Operação sem suporte Installation of the system failed: Criando ext4 em /dev/sda2
The live media device you’re using here to run this - how did you create it and is it a known good device? Additionally, what version of the ISO did you download to create this live environment?
It’s a common cheap pendrive, it seems to work because debian and endeavour os install fine, the image is written with ventoy, but some weeks ago I tried with the fedora media creator and it gave the same error
Ah - so /dev/sda on the machine is potentially already formatted as ext4 from a previous installation of some other distribution.
If you boot the live environment can you tell which device /dev/sda is and what it currently contains?
Its my default OS drive, a 120gb SSD
sda
├─sda1 vfat FAT32 78BA-4B87
└─sda2 xfs 61876369-4651-4cb1-8624-9c380c10260d
sdb
└─sdb1 xfs HD2000 b4ec47dd-9bb4-49db-b4f3-f3bb8bc7a917
sdc
└─sdc1 f2fs 1.16 de68efee-dbe2-43db-8992-1c68f7e2b732
its on xfs now but thats because i tried to manually partitioning after sending the first log, it gives me the same error
here, a new try with a clean and new partition table
Hmm - how about formatting it as ext4, or even just dropping it entirely and leaving it as raw disk?
You beat me to it - posted crossed.
On the plus side we can note that this has nothing to do with efivars, as it’s now failing to format /dev/sda2 as ext4.
On the negative side, I have zero idea why /dev/sda2 will fail to be formatted as ext4 with an operation not permitted error if it’s blank. Is there some kind of lock on the device in the BIOS, or a knackered/failing device?
Anything in the SMART table for that device?
smart says the drive is okay, and i think there is no bios lock os something like that bcus debian installs fine
tried anaconda on terminal
===============================================================================
Um erro desconhecido ocorreu
anaconda 43.44 exception report
Traceback (most recent call first):
File “/usr/lib/python3.14/site-packages/dasbus/client/handler.py”, line 509, in _handle_method_error
raise exception from None
File “/usr/lib/python3.14/site-packages/dasbus/client/handler.py”, line 483, in _get_method_reply
return self._handle_method_error(error)
File “/usr/lib/python3.14/site-packages/dasbus/client/handler.py”, line 450, in _call_method
return self._get_method_reply(
File “/usr/lib64/python3.14/site-packages/pyanaconda/ui/tui/spokes/installation_progress.py”, line 134, in _on_installation_done
self._task_proxy.Finish()
File “/usr/lib/python3.14/site-packages/dasbus/signal.py”, line 53, in emit
callback(*args, **kwargs)
File “/usr/lib/python3.14/site-packages/dasbus/client/handler.py”, line 365, in _signal_callback
callback(*unwrap_variant(parameters))
File “/usr/lib/python3.14/site-packages/dasbus/client/handler.py”, line 133, in _signal_callback
callback(parameters, *callback_args)
pyanaconda.modules.common.errors.general.AnacondaError: mount failed: fsopen() failed: Operação sem suporte
Ok after hours of hitting my head in the wall I was able to install it and fix the efivar issue
What worked for me for fixing the fsopen() operation not supported and efi variables are not supported appearing even on a UEFI boot was changing on BIOS:
NX-MODE = enabled
ACPI auto config = enabled
SATA mode = AHCI
2 Likes
I think you have mixed up a few things. What you need for a (U)EFI installation is an ESP (EFI System Partition) and a GPT paritioned drive. Nothing else. And those options in the UEFI are largely irrelevant to that or efivars. efivars are variables that the firmware has and are exposed to the OS so the OS can interact with the firmware. Support for that is provided by the kernel (efivarfs module). EFI variable support is NOT required to boot or install in UEFI mode.
By what you have written, the problem seemed to be that either your drive had a MBR (legacy style) partition table instead of GPT and/or you did not have an ESP set (or installer was not creating one because of the first reason if you used automatic partitioning).
That is not correct. You can boot in UEFI mode from disk with a MBR partition table and you can boot in legacy BIOS mode from a disk with a GPT partition. That is, as long as you are not booting Windows.
You can tell if you are booted in UEFI mode by checking if /sys/firmware/efi/ exists.
No it is not incorrect, you are just being pedantic. The UEFI specification dictates the presence of ESP partition only and does not mandate GPT partition table, that is true. BUT the best practice is to keep the disks with GPT partition table as installers may refuse to work with MBR (Windows as you already mentioned) AND, most importantly, motherboard firmware may automatically enable CSM if it sees MBR style partition table on the boot disk, depending on implementation, firmware bug or locked firmware settings on laptops. CSM can force legacy mode, load BIOS OpROMs instead of UEFI drivers etc etc (and it is why Windows enforces GPT in the first place).
So just because you can, doesn’t mean you should and it should never be suggested, especially to users who may not be able to understand and troubleshoot these things (as it’s obvious by the OP here thinking ACPI autoconfiguration, SATA mode, No eXecute bit or efivars have anything to do with UEFI booting).
EDIT: As a funny sidenote. Do try to mass provision baremetal servers with Debian in UEFI mode and Debian preseed, with MBR style partitions and let me know how it goes. 