fwupdmgr KEK 2011→2023 update fails with "efivarsfs: Invalid argument" on Trusted Launch Linux VM

Question

fwupdmgr KEK 2011→2023 update fails with "efivarsfs: Invalid argument" on Trusted Launch Linux VM

Dovid Gross 0

I'm following KB 5103014 ("Secure Boot certificate updates for Linux on Azure virtual machines") to replace the expiring Secure Boot 2011 certificates with 2023 on a Trusted Launch Linux VM. The fwupd update consistently fails when writing the KEK to the UEFI variable store. The VM still boots normally on the existing 2011 certificates, so nothing is currently degraded — I need the supported procedure to complete the update.

Environment

Azure Trusted Launch VM (Secure Boot + vTPM), Gen2, East US
Ubuntu 22.04.3 LTS, kernel 6.8.0-1031-azure
VM created 2023-10-19 (pre-April 2024, in scope per KB 5103014)
fwupd 2.1.4

Confirmed 2023 certs are absent

mokutil --db | grep "UEFI CA 2023" → no output
mokutil --kek | grep "KEK 2K CA 2023" → no output

Checks already done (rules out the common causes)

efivarfs mounted rw: efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
ESP mounted: /boot/efi on /dev/sdb15 (vfat, rw)
KEK variable is not immutable — lsattr shows no i flag

The failure sudo fwupdmgr refresh succeeds. sudo fwupdmgr update correctly offers "Upgrade KEK CA from 2011 to 2023 … signed by Microsoft Corporation Third Party Marketplace PCA", I confirm, and the write fails:

WARNING: UEFI ESP partition not detected or configured
...
failed to write-firmware: failed to write (null): failed to write data to efivarsfs: Error writing to file descriptor: Invalid argument

This matches a known fwupd issue reported across several platforms (e.g. fwupd GitHub issues #9483, #9191), with one report attributing it to an EFI variable-store space limitation.

Questions

What's the supported way to complete the KEK/db 2023 update on a Trusted Launch Linux VM when fwupd fails this way?
If the cause is EFI variable-store space, what's the safe, supported way to free space on a Trusted Launch VM without risking boot? (I'd rather not manually delete UEFI variables unless confirmed safe for this config.)
Will the efitools / efi-updatevar manual method in KB 5103014 succeed where fwupd fails, or hit the same limit?
Any vTPM / measured-boot impact from the recommended procedure?

I have a pre-change disk snapshot in place. Happy to provide fwupdmgr get-devices or dmesg'm following KB 5103014 ("Secure Boot certificate updates for Linux on Azure virtual machines") to replace the expiring Secure Boot 2011 certificates with 2023 on a Trusted Launch Linux VM. The fwupd update consistently fails when writing the KEK to the UEFI variable store. The VM still boots normally on the existing 2011 certificates, so nothing is currently degraded — I need the supported procedure to complete the update.

Environment

Azure Trusted Launch VM (Secure Boot + vTPM), Gen2, East US
Ubuntu 22.04.3 LTS, kernel 6.8.0-1031-azure
VM created 2023-10-19 (pre-April 2024, in scope per KB 5103014)
fwupd 2.1.4

Confirmed 2023 certs are absent

mokutil --db | grep "UEFI CA 2023" → no output
mokutil --kek | grep "KEK 2K CA 2023" → no output

Checks already done (rules out the common causes)

efivarfs mounted rw: efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
ESP mounted: /boot/efi on /dev/sdb15 (vfat, rw)
KEK variable is not immutable — lsattr shows no i flag

The failure sudo fwupdmgr refresh succeeds. sudo fwupdmgr update correctly offers "Upgrade KEK CA from 2011 to 2023 … signed by Microsoft Corporation Third Party Marketplace PCA", I confirm, and the write fails:

WARNING: UEFI ESP partition not detected or configured
...
failed to write-firmware: failed to write (null): failed to write data to efivarsfs: Error writing to file descriptor: Invalid argument

This matches a known fwupd issue reported across several platforms (e.g. fwupd GitHub issues #9483, #9191), with one report attributing it to an EFI variable-store space limitation.

Questions

What's the supported way to complete the KEK/db 2023 update on a Trusted Launch Linux VM when fwupd fails this way?
If the cause is EFI variable-store space, what's the safe, supported way to free space on a Trusted Launch VM without risking boot? (I'd rather not manually delete UEFI variables unless confirmed safe for this config.)
Will the efitools / efi-updatevar manual method in KB 5103014 succeed where fwupd fails, or hit the same limit?
Any vTPM / measured-boot impact from the recommended procedure?

I have a pre-change disk snapshot in place. Happy to provide fwupdmgr get-devices or dmesg

Jose Benjamin Solis Nolasco 8,076 Reputation points Volunteer Moderator

2026-06-16T21:52:26.68+00:00
Hello @Dovid Gross I hope you are doing well,

You ruled out all the common issues...

The "Invalid argument" error usually doesn't mean your storage is actually full. Instead, it means the fwupd tool formatted the update file incorrectly, and the Linux kernel rejected it. To get around this, you should skip fwupd entirely and use the manual method (efi-updatevar) listed in the Microsoft KB article. This manual method works directly with the kernel and almost always bypasses this specific bug.

If the manual method actually tells you there is "No space left on device," the only files you can safely delete from the EFI system are old crash logs. You can delete them by running sudo rm -f /sys/firmware/efi/efivars/dump-*. Do not touch any other files!

Updating these certificates will change the security "fingerprint" of the VM. Standard Azure setups handle this fine, but if you have custom hard-drive encryption tied to that exact fingerprint, it might ask for a recovery key on reboot. Having a snapshot of your disk ready was a very smart move!

Recomendations:

Use efi-updatevar method from KB 5103014.

Avoid fwupd for this update on Trusted Launch Linux VMs.

Do not attempt manual variable deletion — unsafe and unsupported.

Confirm post‑update with mokutil verification.

If running a Confidential VM, follow Azure recreation guidance.

https://github.com/fwupd/fwupd/issues/9191

https://support.microsoft.com/en-us/topic/secure-boot-certificate-updates-for-linux-on-azure-virtual-machines-df51ba85-4e1e-4eda-b1d8-f0881970e997

😊 If my answer helped you resolve your issue, please consider marking it as the correct answer. This helps others in the community find solutions more easily. Thanks!
Hemalatha 14,445 Reputation points Microsoft External Staff Moderator

2026-06-16T22:31:04.8133333+00:00
Hello Dovid,

Hi Dovid,

Thank you for sharing the detailed information and the troubleshooting steps you have already completed. We reviewed the issue with the Secure Boot certificate transition from the 2011 certificates to the 2023 certificates on the Azure Trusted Launch Linux VM.

Based on the details provided, fwupdmgr is correctly detecting the available KEK 2023 update, but the failure occurs when the update is being written into the UEFI variable store:

failed to write data to efivarsfs: Error writing to file descriptor: Invalid argument

This indicates that the failure is happening during the UEFI variable update operation rather than during the certificate download or validation process. The Secure Boot update process depends on successfully updating UEFI variables such as KEK, DB, and DBX, and similar failures can occur when the firmware rejects a variable update due to firmware limitations or compatibility issues.

Since this is an Azure Trusted Launch VM, the UEFI firmware layer is managed by the Azure platform. Unlike a physical device, there is no customer-managed BIOS/UEFI update path available. We would need to validate whether the Azure Trusted Launch firmware is rejecting the KEK update due to a variable store limitation or another firmware-side restriction.

Regarding the manual efi-updatevar approach, it uses the same underlying UEFI variable storage mechanism. If the current issue is caused by the firmware rejecting the KEK variable write, switching tools may result in the same behavior. We would not recommend manually modifying or deleting Secure Boot variables (PK/KEK/DB/DBX) as these are part of the Secure Boot trust chain and incorrect changes could impact the boot configuration.

The current VM state is not impacted because it is still booting successfully with the existing 2011 certificates. The failed update attempt itself should not affect the vTPM or measured boot state. However, completing the certificate transition is required before the existing certificates reach expiration.

To continue the investigation, could you please provide the following outputs?

sudo fwupdmgr get-devices

sudo fwupdmgr get-report-metadata

sudo dmesg | grep -i -E "efi|efivar|secure"

efivar -l | wc -l

These details will help confirm whether the failure is related to the UEFI variable store handling on the Trusted Launch platform.

1 answer

Your answer

Jose Benjamin Solis Nolasco 8,076 Reputation points Volunteer Moderator

2026-06-16T21:52:26.68+00:00

Hello @Dovid Gross I hope you are doing well,

You ruled out all the common issues...

The "Invalid argument" error usually doesn't mean your storage is actually full. Instead, it means the fwupd tool formatted the update file incorrectly, and the Linux kernel rejected it. To get around this, you should skip fwupd entirely and use the manual method (efi-updatevar) listed in the Microsoft KB article. This manual method works directly with the kernel and almost always bypasses this specific bug.

If the manual method actually tells you there is "No space left on device," the only files you can safely delete from the EFI system are old crash logs. You can delete them by running sudo rm -f /sys/firmware/efi/efivars/dump-*. Do not touch any other files!

Updating these certificates will change the security "fingerprint" of the VM. Standard Azure setups handle this fine, but if you have custom hard-drive encryption tied to that exact fingerprint, it might ask for a recovery key on reboot. Having a snapshot of your disk ready was a very smart move!

Recomendations:

Use efi-updatevar method from KB 5103014.

Avoid fwupd for this update on Trusted Launch Linux VMs.

Do not attempt manual variable deletion — unsafe and unsupported.

Confirm post‑update with mokutil verification.

If running a Confidential VM, follow Azure recreation guidance.

https://github.com/fwupd/fwupd/issues/9191

https://support.microsoft.com/en-us/topic/secure-boot-certificate-updates-for-linux-on-azure-virtual-machines-df51ba85-4e1e-4eda-b1d8-f0881970e997

😊 If my answer helped you resolve your issue, please consider marking it as the correct answer. This helps others in the community find solutions more easily. Thanks!

Answer 1

Dovid Gross 0

Hi Jose, thank you for the guidance - it got us further than fwupd did.

Following your recommendation, I skipped fwupd entirely and used the efi-updatevar method from KB 5103014. Results:

sudo efi-updatevar -a -f DBUpdate3P2023.bin db - silent success (no output, no error)
sudo efi-updatevar -a -f KEKUpdate_Microsoft_PK1.bin KEK - Failed to update KEK: Invalid argument

The db update appears to have applied. The KEK update fails with the same "Invalid argument" error as fwupd, suggesting this is not a tooling issue but a platform-level rejection of KEK writes on this VM.

This VM matches the symptom description in the Known Issues article (KB 5085790) - "certain long-running Azure Trusted Launch Gen2 VMs where Secure Boot variables are maintained by the platform firmware." That article currently states "no required customer action; a resolution will be delivered through future updates."

A few questions - I know you are not MS support, but perhaps you know, or an MS engineer might chime in:

Is there any customer-actionable path to complete the KEK update on a Trusted Launch VM where the platform firmware is blocking KEK writes?
Given the db update succeeded but KEK did not, is the VM in a consistent/safe state, or is a partial update problematic?
Is the incoming platform fix expected before June 26?

VM details if helpful: Ubuntu 22.04.3, kernel 6.8.0-1031-azure, fwupd 2.1.4, Trusted Launch Gen2, created October 2023.Hi

Dovid Gross 0 Reputation points

2026-06-16T22:52:44.1833333+00:00

Thanks, Hemalatha. Here is the output:

Thanks, Hemalatha. Here is the output:

sudo fwupdmgr get-devices

WARNING: UEFI ESP partition not detected or configured

See https://github.com/fwupd/fwupd/wiki/PluginFlag:esp-not-found for more information.

Microsoft Corporation Virtual Machine

│

├─Hyper-V Firmware PK:

│ Device ID: 6924110cde4fa051bfdc600a60620dc7aa9d3c6a

│ Summary: UEFI Platform Key

│ Current version: 2013

│ Vendor: Microsoft

│ GUIDs: 4a40f2b0-625f-5e0c-a58e-e7e607c3829c ← UEFI\VENDOR_Microsoft&NAME_Microsoft-Hyper-V-Firmware-PK

│ 1742ef01-f7c7-5363-8fd9-d066222df9c0 ← UEFI\CRT_2F4224E08F34C7A237CCBB8FB71753558826EA6E

│ Device Flags: • Internal device

│

├─SBAT:

│ Device ID: 6469856584e2f5873b2f148302e46c9313c7d054

│ Summary: Generation number based revocation mechanism

│ Current version: 1.5.4

│ Vendor: OS:ubuntu-core

│ GUID: 009def40-8820-52da-8435-8353cfe3d72c ← UEFI\OS_ubuntu-core&VAR_SbatLevelRT

│ Device Flags: • Updatable

│ • Needs a reboot after installation

│ • Signed Payload

│

├─TPM:

│ Device ID: 1d8d50a4dbc65618f5c399c2ae827b632b3ccc11

│ Current version: 8224.786.18.3

│ Vendor: Microsoft (TPM:MSFT)

│ GUIDs: 2a65d4b6-60a0-5e8c-acfa-d86cc3cbe4c3 ← TPM\VEN_MSFT&DEV_0001

│ 936e3099-9e84-5969-8b85-5b56de5a5903 ← TPM\VEN_MSFT&MOD_TPMSimulator

│ 5bea8d58-c840-513e-a5ad-0184cbaa9821 ← TPM\VEN_MSFT&DEV_0001&VER_2.0

│ 8489be3e-126f-52bb-8409-649516c6047c ← TPM\VEN_MSFT&MOD_TPMSimulator&VER_2.0

│ Device Flags: • Internal device

│ • System requires external power source

│ • Needs a reboot after installation

│ • Device can recover flash failures

│ • Signed Payload

│ • Can tag for emulation

│

├─UEFI Key Exchange Key:

│ │ Device ID: 2a4c23bfb79b5dabe474cb7b1b3e604645d6f9c6

│ │ Device Flags: • Internal device

│ │

│ └─KEK CA:

│ Device ID: b7a1d3d90faa1f6275d9a98da4fb3be7118e61c7

│ Current version: 2011

│ Vendor: Microsoft (UEFI:Microsoft)

│ Update State: Failed

│ Update Error: failed to write-firmware: failed to write (null): failed to write data to efivarsfs: Error writing to file descriptor: Invalid argument

│ Last modified: 2026-06-16 20:16:10

│ GUIDs: 814e950f-1449-566a-a190-42c9d3a3a2df ← UEFI\VENDOR_Microsoft&NAME_Microsoft-KEK-CA

│ dfa66406-6568-5bdf-bb8e-b53ddb4be4cf ← UEFI\CRT_9F402B1CC0243CBEDC58A525789816CCCA7687A9

│ Device Flags: • Internal device

│ • Updatable

│ • Supported on remote server

│ • Needs a reboot after installation

│ • Device is usable for the duration of the update

│ • Signed Payload

│ • Can tag for emulation

│

├─UEFI Signature Database:

│ │ Device ID: 0352a8acc949c7df21fec16e566ba9a74e797a97

│ │ Device Flags: • Internal device

│ │

│ └─UEFI CA:

│ Device ID: 5bc922b7bd1adb5b6f99592611404036bd9f42d0

│ Current version: 2011

│ Vendor: Microsoft (UEFI:Microsoft)

│ GUIDs: 26f42cba-9bf6-5365-802b-e250eb757e96 ← UEFI\VENDOR_Microsoft&NAME_Microsoft-UEFI-CA

│ c34a7e6a-bd86-5244-8bd0-7db66fd3c073 ← UEFI\CRT_E30CF09DABEAB32A6E3B07A7135245DE05FFB658

│ Device Flags: • Internal device

│ • Updatable

│ • Supported on remote server

│ • Needs a reboot after installation

│ • Signed Payload

│ • Can tag for emulation

│

└─UEFI dbx:

Device ID: 362301da643102b9f38477387e2193e57abaa590

Summary: UEFI revocation database 55b99b0d

Vendor: Microsoft (UEFI:Microsoft)

Install Duration: 1 second

Update Error: Not updatable as UEFI ESP partition not detected

GUID: f8ba2887-9411-5c36-9cee-88995bb39731 ← UEFI\CRT_A1117F516A32CEFCBA3F2D1ACE10A87972FD6BBE8FE0D0B996E09E65D802A503&ARCH_X64

Device Flags: • Internal device

• Supported on remote server

• Needs a reboot after installation

• Device is usable for the duration of the update

• Updatable

• Only version upgrades are allowed

• Signed Payload

• Can tag for emulation

────────────────────────────────────────────────

Devices that were not updated correctly:

• KEK CA (2011 → 2023)

Uploading firmware reports helps hardware vendors to quickly identify failing and successful updates on real devices.

Review and upload report now? (Requires internet connection) [Y|n]: n

Do you want to disable this feature for future updates? [y|N]: y

Authenticating… ▕ ⣷ ▏

Declined upload

======================================

sudo fwupdmgr get-report-metadata

WARNING: UEFI ESP partition not detected or configured

See https://github.com/fwupd/fwupd/wiki/PluginFlag:esp-not-found for more information.

Command not found

Use /snap/fwupd/8528/bin/fwupdmgr --help for help

============================================

sudo dmesg | grep -i -E "efi|efivar|secure"

[ 0.000000] efi: EFI v2.7 by Microsoft

[ 0.000000] efi: ACPI=0x3fffa000 ACPI 2.0=0x3fffa014 SMBIOS=0x3ff85000 SMBIOS 3.0=0x3ff83000 TPMFinalLog=0x3eb39000 MEMATTR=0x3ebce018 MOKvar=0x3ff81000 RNG=0x3ffd1018 TPMEventLog=0x3eb00018

[ 0.000000] secureboot: Secure boot enabled

[ 0.000000] Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7

[ 0.000000] DMI: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024

[ 0.019490] secureboot: Secure boot enabled

[ 0.321050] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns

[ 0.672913] efivars: Registered efivars operations

[ 1.192379] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing: 61482aa2830d0ab2ad5af10b7250da9033ddcef0'

[ 1.199165] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2017): 242ade75ac4a15e50d50c84b0d45ff3eae707a03'

[ 1.206837] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (ESM 2018): 365188c1d374d6b07c3c8f240f8ef722433d6a8b'

[ 1.212903] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2019): c0746fd6c5da3ae827864651ad66ae47fe24b3e8'

[ 1.218771] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2021 v1): a8d54bbb3825cfb94fa13c9f8a594a195c107b8d'

[ 1.226649] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2021 v2): 4cf046892d6fd3c9a5b03f98d845f90851dc6a8c'

[ 1.234249] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (2021 v3): 100437bb6de6e469b581e61cd66bce3ef4ed53af'

[ 1.242523] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing (Ubuntu Core 2019): c1d57b8f6b743f23ee41f4f7ee292f06eecadfb9'

[ 1.274246] integrity: Loading X.509 certificate: UEFI:db

[ 1.278107] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'

[ 1.285263] integrity: Revoking X.509 certificate: UEFI:dbx

[ 1.288818] blacklist: Revoked X.509 cert 'Canonical Ltd. Secure Boot Signing: 61482aa2830d0ab2ad5af10b7250da9033ddcef0'

[ 1.295059] integrity: Revoking X.509 certificate: UEFI:dbx

[ 1.299618] blacklist: Revoked X.509 cert 'Debian Secure Boot Signer: 00a7468def'

[ 1.305055] integrity: Revoking X.509 certificate: UEFI:dbx

[ 1.309072] blacklist: Revoked X.509 cert 'Cisco: Virtual UEFI SubCA: 13df2e3f54ebf347dcaecebf21d3cbb2355a4c9a'

[ 1.322774] integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table)

[ 3.383179] systemd[1]: Starting Load Kernel Module efi_pstore...

[ 3.408402] pstore: Registered efi_pstore as persistent store backend

===============================================

efivar -l | wc -l

30

Share via

fwupdmgr KEK 2011→2023 update fails with "efivarsfs: Invalid argument" on Trusted Launch Linux VM

1 answer

Your answer