Secure Boot toggle in 25.10-RC.1 virtual machines doesn't enable enrolled keys VARS

Per request from @Captain_Morgan I’m making this post regarding issue mentioned here: TrueNAS 25.10-RC.1 is Now Available! - #44 by TheJulianJES

I made one test VM for Windows 11 and one for Debian Trixie. Windows process below:


Checking the config with virsh since OS say Secure Boot not enabled:

Here we can see that <feature enabled='no' name='enrolled-keys'/> and that /usr/share/OVMF/OVMF_VARS_4M.fd is used as template for VARS.

Trying to set <feature enabled='yes' name='enrolled-keys'/>:

Checking if the VARS file used has Secure Boot keys:

Nothing.

Screenshot from UEFI Setup → Device Manager → Secure Boot Configuration in the non functional VM:

Looking at older pre 25.04 VM that has working Secure Boot with virsh:

It has enrolled keys enabled: <feature enabled='yes' name='enrolled-keys'/>

Checking if the VARS template file used has Secure Boot keys:

Screenshot from UEFI Setup → Device Manager → Secure Boot Configuration in the functional VM:

By the way, the pc-q35-6.2 machine type used as standard i TrueNAS is deprecated in the QEMU version used.

1 Like

Thanks…

So you had no problems with 25.04.2.x?

But 25.10.RC.1 has these issues?

No problem.

25.04.2.x:
I could get this working but had to use cli and replace a file. Take a look at NAS-137054.

This version actually DID enable enrolled-keys but used the wrong VARS file without the Microsoft keys.

Example for workaround in 25.04.2.x that worked with a Debian 13 VM (same procedure for Windows):

  • Change bootloader in cli:
    service vm update id=49 bootloader_ovmf=OVMF_CODE_4M.ms.fd
  • Replace VARS file:
    install -D -m 0600 -o libvirt-qemu -g libvirt-qemu /usr/share/OVMF/OVMF_VARS_4M.ms.fd /data/subsystems/vm/nvram/49_Debian_VARS.fd

25.10.RC.1 has introduced other issues:

  • It doesn’t enable enrolled-keys:
    <feature enabled='no' name='enrolled-keys'/>
  • It uses OVMF_VARS_4M.fd which does not have the Microsoft keys. Should use OVMF_VARS_4M.ms.fd which has both Microsoft keys and possibly Debian shim.
  • It uses incorrect OVMF_CODE_4M.secboot.fd and should use OVMF_CODE_4M.ms.fd

Extra info after more testing:

You seem to use the definitions in the json files in this directory: /usr/share/qemu/firmware/

If you take a look at /usr/share/qemu/firmware/50-edk2-x86_64-secure.json you find:

{
    "description": "UEFI firmware for x86_64, with Secure Boot and SMM, empty varstore",
    "interface-types": [
        "uefi"
    ],
    "mapping": {
        "device": "flash",
        "executable": {
            "filename": "/usr/share/OVMF/OVMF_CODE_4M.secboot.fd",
            "format": "raw"
        },
        "nvram-template": {
            "filename": "/usr/share/OVMF/OVMF_VARS_4M.fd",
            "format": "raw"

And then /usr/share/qemu/firmware/40-edk2-x86_64-secure-enrolled.json:

{
    "description": "UEFI firmware for x86_64, with Secure Boot and SMM, SB enabled, MS certs enrolled",
    "interface-types": [
        "uefi"
    ],
    "mapping": {
        "device": "flash",
        "executable": {
            "filename": "/usr/share/OVMF/OVMF_CODE_4M.ms.fd",
            "format": "raw"
        },
        "nvram-template": {
            "filename": "/usr/share/OVMF/OVMF_VARS_4M.ms.fd",
            "format": "raw"

I managed to get this working now by deleting the VARS file from /var/db/system/vm/nvram/ and changing the bootloader via SQLite (not ideal):
UPDATE vm_vm SET bootloader_ovmf='OVMF_CODE_4M.ms.fd' WHERE id=69;

And there you go:

Thanks for the comprehensive review. Given no other comments/suggstions, I’d recommend you submit another bug report with this data and referring back to previous bug report.

OK, done. NAS-137898

1 Like