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 20

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 11,221 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!
Anonymous

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.
Anonymous

2026-06-22T17:59:27.96+00:00

Hello David

Could you please share the VMsize and Node ID/Container ID??
Anonymous

2026-06-23T16:39:06.48+00:00

Hello Dovid Gross,

We have engaged our engineering team regarding the issue.

Based on their review, there are a few known issues related to this scenario, and fixes have already been rolled out. In a limited number of cases, this behavior can occur when hibernate is enabled on the VM.

To identify whether your VM is impacted by the known firmware issue and confirm the applicable fix status, our engineering team needs to verify the firmware currently loaded on the host.

Could you please provide the below details?

VM Size

Node ID / Container ID

Once we have these details, we will check further and provide the next steps.
Dovid Gross 20 Reputation points

2026-06-23T20:23:24.2633333+00:00

Thanks Hemalatha. Details:

The host Node/Container ID doesn't seem to be exposed to the guest via IMDS, so hopefully you can resolve the host and firmware version from the vmId.

I checked the hibernate angle. Hibernation isn't enabled on this VM (hibernationEnabled comes back empty), so that doesn't look like the trigger here. I can send fwupdmgr get-devices or dmesg EFI output if that helps.
Anonymous

2026-06-24T16:47:52+00:00

Hello Dovid,

Could you please confirm, rebooting the VM resolved the issue? Please let us know if issue persists?

Answer accepted by question author

Mike Slaunwhite 80

I have the same issue. I opened a MS case and the response listed the root cause of:

"Azure’s hypervisor presents a virtualized EFI variables filesystem (efivarsfs) that is read-only for Secure Boot key updates from within the guest. Manual writes to KEK or UEFI CA variables inside a Linux VM are blocked by platform policy. Certificate rotation for Azure VMs is handled at the host/firmware level by Microsoft, not by guest-initiated firmware updates."

Steps to fix:

In the Azure Portal, go to the VM’s blade.Under Support + troubleshooting, select Redeploy. Click Redeploy to reprovision the VM onto a new host cluster that includes the rotated certificates.
Once redeployed, re-run 'sudo fwupdatemgr update'

This allowed me to update UEFI CA signatures db from 2011 to 2023. It also updated the UEFI forbidden signratures ("dbx") from 20230501 to 20250902.

This required a reboot.

After reboot mokutil --db | grep 'Subject:' does list both 2011 and 2023 versions of the UEFI CA. But mokutil --kek | grep 'Subject:' only lists the 2011 KEK CA.

re-ran fwupdmgr again and now it shows:

$ sudo fwupdmgr update

Devices with the latest available firmware version:

• UEFI CA

• UEFI dbx

Devices with no available firmware updates:

• KEK CA

• SBAT

I am now unsure if I should expect the KEK CA to get updated or not.

Jakub Włodarczyk 0 Reputation points

2026-06-26T20:38:09.3633333+00:00
For me mokutil --kek did show only 2011 KEK CA as well.
What helped me was :

sudo fwupdmgr refresh --force sudo fwupdmgr update

Without force it said it was already up to date
Mike Slaunwhite 80 Reputation points

2026-06-26T20:45:45.9+00:00

MS just got back to me on my case. For my scenario of issuing a redeployment and UEFI CA was able to update but no update available for KEK CA, MS is thinking "We suspect the host cluster firmware rotation may still be in progress or the guest’s Secure Boot variables have not yet fully applied the 2023 certificates"

24 hours later after my prior post they had me run sudo fwupdatemgr update --verbose and this time it did detect the KEK CA. I don't think the verbose parameter had anything to do with it. I think it was just a timing issue.

4 additional answers

Your answer

Jose Benjamin Solis Nolasco 11,221 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!
Anonymous

2026-06-22T17:59:27.96+00:00

Hello David

Could you please share the VMsize and Node ID/Container ID??
Anonymous

2026-06-23T16:39:06.48+00:00

Hello Dovid Gross,

We have engaged our engineering team regarding the issue.

Based on their review, there are a few known issues related to this scenario, and fixes have already been rolled out. In a limited number of cases, this behavior can occur when hibernate is enabled on the VM.

To identify whether your VM is impacted by the known firmware issue and confirm the applicable fix status, our engineering team needs to verify the firmware currently loaded on the host.

Could you please provide the below details?

VM Size

Node ID / Container ID

Once we have these details, we will check further and provide the next steps.
Dovid Gross 20 Reputation points

2026-06-23T20:23:24.2633333+00:00

Thanks Hemalatha. Details:

The host Node/Container ID doesn't seem to be exposed to the guest via IMDS, so hopefully you can resolve the host and firmware version from the vmId.

I checked the hibernate angle. Hibernation isn't enabled on this VM (hibernationEnabled comes back empty), so that doesn't look like the trigger here. I can send fwupdmgr get-devices or dmesg EFI output if that helps.
Anonymous

2026-06-24T16:47:52+00:00

Hello Dovid,

Could you please confirm, rebooting the VM resolved the issue? Please let us know if issue persists?
Jakub Włodarczyk 0 Reputation points

2026-06-26T20:38:09.3633333+00:00

For me mokutil --kek did show only 2011 KEK CA as well.
What helped me was :

sudo fwupdmgr refresh --force sudo fwupdmgr update

Without force it said it was already up to date
Mike Slaunwhite 80 Reputation points

2026-06-26T20:45:45.9+00:00

MS just got back to me on my case. For my scenario of issuing a redeployment and UEFI CA was able to update but no update available for KEK CA, MS is thinking "We suspect the host cluster firmware rotation may still be in progress or the guest’s Secure Boot variables have not yet fully applied the 2023 certificates"

24 hours later after my prior post they had me run sudo fwupdatemgr update --verbose and this time it did detect the KEK CA. I don't think the verbose parameter had anything to do with it. I think it was just a timing issue.

Answer 1

Anonymous

Thanks for sharing details Dovid,

We reviewed the details with our engineering team. Based on their analysis, the VM appears to be running an older firmware version. A firmware update containing the relevant fix was rolled out during the April/May timeframe; however, the current firmware on the affected node appears to predate that update.

To ensure the VM picks up the latest firmware and associated fixes, we recommend performing a reboot of the VM at your earliest convenience during an appropriate maintenance window.

After the reboot, the system should load the updated firmware components. For validation, the file version of vmfirmwarehcl.dll should be 26100.1577 or later.

Please let us know once the reboot has been completed, and confirm whether the issue persists afterward. We will be happy to continue assisting if any further investigation is required.

Dovid Gross 20 Reputation points

2026-06-24T18:05:47.7466667+00:00
Hi, Hemalatha,

The reboot did help, but leaves an open item.

Post boot, fwupdmgr was able to apply the db update. The signature database now contains the Microsoft UEFI CA 2023 cert (confirmed with mokutil --db), alongside the existing 2011 one. So that part is resolved.

However, the KEK and dbx did not complete:

mokutil --kek still shows only "Microsoft Corporation KEK CA 2011". The 2023 KEK is not present, and fwupdmgr update now reports "no available firmware updates" for KEK CA, so it isn't offering it.

fwupdmgr get-devices shows UEFI dbx with: Update Error: Not updatable as UEFI ESP partition not detected.

The recurring warning throughout is "UEFI ESP partition not detected or configured", even though /boot/efi is mounted (vfat on /dev/sdb15, rw). Engiineering noticed that fwupd here is the snap build (/snap/fwupd/...), and suspect may not be able to see the mounted ESP due to snap confinement.

Questions:

Is the db update alone sufficient for the 2011 certificate expiry concern, or do the KEK and dbx also need to be updated?

If KEK/dbx are needed, what's the supported way to get fwupd to detect the ESP here? Should I be using the distro (apt) fwupd rather than the snap build?

Even if unneeded, do you advise resolving KEK and dbx anyway?

VM is back up and serving clients normally. fwupdmgr get-devices output available if useful.
Anonymous

2026-06-25T00:35:22.5+00:00

Thank you for the update.

We reviewed the latest status with our engineering team. We are glad to see that after the reboot, the DB update completed successfully and the Microsoft UEFI CA 2023 certificate is now present in the signature database. This confirms that the DB update portion has been completed.

Regarding the remaining KEK and DBX updates, the engineering team confirmed that the firmware changes involved are not directly visible from within the guest operating system. The related fixes have been rolling out, and based on the current rollout status, a reboot resolves the KEK update issue in most cases.

At this point, the VM is running normally. As a best practice, the Microsoft UEFI CA 2023 KEK certificate should ideally also be present. However, the VM is expected to continue operating with the current state until a new bootloader update is required.

Please let us know if you see any further changes after monitoring the VM status.

Answer 2

Dovid Gross 20

Hemalatha's thread provides the definitive answer to the core issue. Jose's and Sunoj's posts were useful but not decisive. Mike's answer is an important follow-on to what Hemalatha provided.

0 comments

Answer 3

Hello @Dovid Gross,

Thank you for reaching out Q&A forum.

Fix ESP detection in /etc/fwupd/fwupd.conf
Check/free EFI variable store space (orphaned boot entries)
Retry fwupdmgr update for KEK
Separately enroll db 2023 via mokutil --import (independent of fwupd)
Record PCR 7 before and after
Reboot and verify: mokutil --db and mokutil --kek show 2023 certs
Keep the disk snapshot until verified

The failed to write data to efivarsfs: Error writing to file descriptor: Invalid argument error on a Trusted Launch VM is not a generic fwupd bug — it is almost certainly one of two things (or both):

EFI variable store space exhaustion — Azure Trusted Launch VMs have a fixed virtual NVRAM size. The 2011 KEK/db entries plus MOK entries plus runtime variables can fill it, leaving insufficient space for the append-write of the 2023 certs.
fwupd ESP detection failure — the WARNING: UEFI ESP partition not detected or configured line is a secondary issue. fwupd is writing via the efi-updatevar path but failing because it cannot locate the ESP capsule drop path. On Azure Gen2 VMs the ESP is often on sdb not sda, which confuses fwupd's heuristics.

Supported Way to Complete the Update When fwupd Fails

The supported fallback path per KB 5103014 is efi-updatevar + cert-to-efi-sig-list (efitools manual method). Before going there, first fix the fwupd ESP detection issue

Confirm ESP location

findmnt /boot/efi

Set ESP path explicitly in fwupd config

sudo mkdir -p /etc/fwupd

sudo tee /etc/fwupd/fwupd.conf > /dev/null <<EOF

[uefi_capsule]

OverrideESPMountPoint=/boot/efi

EOF

Retry

sudo fwupdmgr update

If the ESP warning disappears but the write still fails with Invalid argument, you are hitting the variable store space issue.

If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.

Answer 4

Dovid Gross 20

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 20 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
Anonymous

2026-06-18T00:45:23.96+00:00

Thank you for sharing details. We will check with internal team and get back to you. Thanks
Anonymous

2026-06-18T19:55:30.0433333+00:00

Hello Dovid,

Could you please check the private message and provided the necessary details.