What does "EFI Error 21" mean, and what might it cause (if anything)?

[RokeJulianLockhart]

The Pre-Requisites

1. 1. The Questions

      1. Which Linux distro are you using?

      2. Which release version?

   2. The Answer

      1. #!/usr/bin/env -S pwsh -File
         $OSRelease = [Ordered]@{}
         Get-Content /etc/os-release | ForEach-Object {
         	If ($_ -Match '^\s*([^=]+)=(.*)$') {
         		$Name  = $Matches[1]
         		$Value = $Matches[2]
         		If ($Value -Match '^"(.*)"$') {
         			$Value = $Matches[1]
         		}
         		If ($Value -Match '^[0-9]+$') {
         			$Value = [Int64]$Value
         		}
         		$OSRelease[$Name] = $Value
         	}
         }
         [PSCustomObject]$OSRelease |
         	Select-Object NAME, VARIANT, VERSION_ID |
         	Format-List |
         	yq -P
         

      2. NAME: Fedora Linux
         VARIANT: KDE Plasma Desktop Edition
         VERSION_ID: 44
         

2. Which kernel are you using?

   1. #!/usr/bin/env python3
      
      import os
      import rpm
      import yaml
      from datetime import datetime, timezone
      
      package = "kernel"
      
      kernel_release = os.uname().release
      
      transaction_set = rpm.TransactionSet()
      
      header = next(
      	(
      		header
      		for header in transaction_set.dbMatch(
      			rpm.RPMTAG_NAME,
      			package,
      		)
      		if f"{header[rpm.RPMTAG_VERSION]}-{header[rpm.RPMTAG_RELEASE]}.{header[rpm.RPMTAG_ARCH]}"
      		== kernel_release
      	),
      	None,
      )
      
      if header is None:
      	raise LookupError(
      		f"Running kernel {kernel_release!r} does not correspond "
      		f"to an installed {package!r} RPM"
      	)
      
      tags = (
      	"NAME",
      	"VERSION",
      	"RELEASE",
      	"ARCH",
      	"INSTALLTIME",
      	"SIZE",
      	"SIGPGP",
      	"SOURCERPM",
      	"BUILDTIME",
      	"BUILDHOST",
      	"PACKAGER",
      	"VENDOR",
      )
      
      properties = {}
      
      for name in tags:
      	value = header[
      		getattr(
      			rpm,
      			f"RPMTAG_{name}",
      		)
      	]
      
      	if name in (
      		"INSTALLTIME",
      		"BUILDTIME",
      	):
      		value = (
      			datetime.fromtimestamp(
      				value,
      				timezone.utc,
      			)
      			.isoformat(timespec="seconds")
      			.replace(
      				"+00:00",
      				"Z",
      			)
      		)
      
      	properties[name] = value
      
      print(
      	yaml.safe_dump(
      		properties,
      		sort_keys=False,
      		default_flow_style=False,
      	)
      )
      

   2. NAME: kernel
      VERSION: 7.2.5
      RELEASE: 200.fc44
      ARCH: x86_64
      INSTALLTIME: '2026-09-14T15:05:47Z'
      SIZE: 0
      SIGPGP: null
      SOURCERPM: kernel-7.2.5-200.fc44.src.rpm
      BUILDTIME: '2026-09-11T14:55:48Z'
      BUILDHOST: buildhw-x86-01.rdu3.fedoraproject.org
      PACKAGER: Fedora Project
      VENDOR: Fedora Project
      

3. Which BIOS version are you using?

   1. run0 dmidecode --string bios-version

   2. 04.03

4. Which Framework Laptop 16 model are you using? (AMD Ryzen™ 7040 Series)

   1. run0 dmidecode --string system-product-name

   2. Laptop 16 (AMD Ryzen 7040 Series)

My Problem

When I last attempted to update my installation of cpe:/o:fedoraproject:fedora:44 (via, verbatim, sudo pwsh -C 'flatpak update -y; dnf5 upgrade -y --refresh --offline && dnf5 offline reboot -y'), I observed:

@Andres_Quast

EFI Error 21

The relevant upgrade log is, per dnf5 history info 275, the undermentioned:

Transaction ID : 275
Begin time     : 2026-09-15 10:34:19
Begin rpmdb    : 8ee8a7a9927b627224314b28e0479070a10353dea542cbedd7e98ff0a964066f
End time       : 2026-09-15 10:34:21
End rpmdb      : 27cab2f9ec53821ec2dfe04ebc7559265e92fe6e8919b8f3223284d019e989e3
User           : 0 Super User <root>
Status         : Ok
Releasever     : 44
Description    : 
Comment        : 
Packages altered:
  Action   Package                           Reason     Repository
  Upgrade  libabw-0:0.1.4-1.fc44.x86_64      Dependency updates
  Upgrade  librevenge-0:0.0.6-1.fc44.x86_64  Dependency updates
  Upgrade  perl-DBI-0:1.653-1.fc44.x86_64    Dependency updates
  Replaced libabw-0:0.1.3-19.fc44.x86_64     Dependency @System
  Replaced librevenge-0:0.0.5-13.fc44.x86_64 Dependency @System
  Replaced perl-DBI-0:1.652-1.fc44.x86_64    Dependency @System

Is this [potentially] problematic, and if so, [how] should I resolve this?

[Squiggler]

A good level of detail in your post, but I am not fully sure of the problem. I take it you just got the EFI error in a log somewhere, and your machine is not bricked by a BIOS update?

[RokeJulianLockhart]

@Squiggler

I take it you just got the EFI error in a log somewhere?

@Squiggler, it appeared, in very large letters, after the OS reinitialised. I presume that the firmware rendered the message to the screen-buffer.

@Squiggler

…and your machine is not bricked by a BIOS update?

It does not appear to have been negatively affected. (It is my first failed firmware installation that has not rendered a motherboard unusable.)

I shall be surprised if it does not indicate a fault whatsoever, even if that fault is merely that FWUPDMgr has not provided the correct update files.

[Squiggler]

@RokeJulianLockhart

[that message] appeared, in very large letters, after the OS reinitialised

OK, gotcha. Did it appear just once, or does it always appear on boot? If it is just once then I would be minded not to worry about it.

It looks like your upgrade (via your package manager) is not the brickable kind anyway. Given the other topics in the forum about that topic, I assume only fwupdmgr update/upgrade ops can do that.

What does sudo fwupdmgr get-updates give you? (My own view is that the get-updates sub-command cannot do any damage, but do ask questions before running if you are nervous; no doubt another forum member will be happy to give a second opinion).

[RokeJulianLockhart]

@Squiggler,

@Squiggler

Did it appear just once, or does it always appear on boot?

Once that I confidently recall, thus far, although it may have appeared once more, some months ago.

@Squiggler

What does sudo fwupdmgr get-updates give you?

[run0] fwupdmgr get-updates returns:

Devices with no available firmware updates:
 • Windows Production PCA
 • Bolt Receiver
 • Hub
 • KEK CA
 • Laptop DB
 • Laptop KEK
 • MX Master 4
 • Option ROM UEFI CA
 • Touchpad
 • WD BLACK SN850X 1000GB
Devices with the latest available firmware version:
 • System Firmware
 • Fingerprint Sensor
 • Laptop 16 Keyboard Module - ISO
 • Laptop 16 Numpad Module
 • UEFI CA
 • UEFI dbx
Successfully uploaded report
No updates available

[Squiggler]

Nice. You’ve no pending firmware updates of, erm, the brickable kind!

[James3]

EFI Error 21 does not mean much. It just means “Operation Aborted”.
It does not imply any reason why it was aborted.

[RokeJulianLockhart]

@James3 and @Squiggler, superb to hear. However, it has reproduced again. Consequently, does anyone know what best to search for, in something like JournalCtl, to ascertain why it continues to fail to apply? I ask because, if feasible, I do not want my firmware to be outdated. (My laptop occasionally stores sensitive documents, so it must be secure!)

[James3]

I would not advise anyone to upgrade their BIOS at the moment.
Wait until FW report on why BIOS updates are bricking laptops, and then use their proposed fix for that bricking.
From a security perspective.
Just keep the laptop with you at all times. That is the only way to know someone else has not been at it.
I don’t know what level of sensitive documents you might have, but the author of those documents will likely have security handling requirements for them. I.e. What computer systems they are allowed to be or or not, and what sort of Data-at-Rest Encryption is needed.

[Squiggler]

@RokeJulianLockhart

However, it has reproduced again.

If you mean you got an error in your logs with no discernible degradation of laptop performance, then I would absolutely ignore it.

@RokeJulianLockhart

My laptop occasionally stores sensitive documents, so it must be secure!

Sure. Security is hard though; it is as weak as your weakest defence. If you clear up your logs, but don’t encrypt your local disk, then your computer security comes to naught if someone can just snatch your laptop when you leave it for thirty seconds in a cafe. If you don’t run 2FA on your password manager and someone gets into your email account, then they’ll just grab your documents from your cloud storage. And so on.

@RokeJulianLockhart

I do not want my firmware to be outdated

I think we established that, for now, your BIOS firmware is not outdated.

[RokeJulianLockhart]

@Squiggler

If you mean you got an error in your logs with no discernible degradation of laptop performance, then I would absolutely ignore it.

@Squiggler, rather, I observe a full-screen error every few OS reinitialisations, when I presume that FWUPDMgr (via Plasma Discover) attempts to apply updates.

[Squiggler]

Ah, interesting. I would imagine that it’s not exactly fwupdmgr, but it could be related. If fwupdmgr finds and installs a new BIOS update, it will put your BIOS in a mode that does final initialisations at boot time, because it cannot reload the BIOS while the BIOS is running. So I wonder if the BIOS knows there is a new version, but it can’t quite switch to it due to an error.

[pkunk]

This is one of the reasons I personally prefer the UEFI boot from a USB update method. The system is already in a state where it can be updated and nothing else is loaded into the system at that time to cause a potential issue.

It is not as convenient, but the old school updating methods were the only choice we had for a long time and worked well for what needed to be done.

[RokeJulianLockhart]

If anyone knows how to ascertain whether an update for my EFI firmware exists, how to re-initiate it (to acquire logs), and how to extract the relevant logs, I shall be glad. Otherwise, I suppose that I shall ask an LLM in the meantime, because if a bug exists, I shall report it at FW’s relevant GitHub repository.