packer-plugin-qemu QEMU Builder Fails EFI Boot on Ubuntu 24.04 Due to Missing OVMF Firmware Files

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
Please do not leave "+1" or other comments that do not add relevant new information or questions; they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Overview of the Issue

Starting with Ubuntu 24.04, the ovmf package no longer provides the expected EFI firmware files at their default locations. Instead, it includes only 4MB firmware variants.

Since Packer’s QEMU builder relies on the default paths, EFI boot fails out-of-the-box on Ubuntu 24.04 unless users manually override the paths in their templates.

This creates two major issues:

Breaking backward compatibility: Users must update all Packer templates referencing EFI boot.
Loss of portability: Hardcoding Ubuntu 24.04-specific paths forces templates to depend on a single distro version.

Reproduction Steps

Install ovmf on Ubuntu 24.04:
```
apt install ovmf
```

Use Packer with default EFI boot settings:

{
  "builders": [{
    "type": "qemu",
    "efi_boot": true
  }]
}

The build fails because Packer cannot find the expected EFI firmware files.

Packer version

Packer v1.12.0

Simplified Packer Template

packer {
  required_plugins {
    qemu = {
      version = "~> 1"
      source  = "github.com/hashicorp/qemu"
    }
  }
}

variable "iso_url" {
  type = string
}

variable "iso_checksum" {
  type = string
}

source "qemu" "test_efi" {
  accelerator      = "kvm"
  boot_wait        = "5s"
  communicator     = "none"
  disk_size        = 10240
  efi_boot         = true
  format           = "qcow2"
  headless         = true
  iso_checksum     = var.iso_checksum
  iso_url          = var.iso_url
  memory           = 1024
  output_directory = "output-test"
}

build {
  sources = ["source.qemu.test_efi"]
}

Operating system and Environment details

OS: Ubuntu 24.04 (Noble)
Architecture: x86_64
QEMU Version: EMU emulator version 8.2.2 (Debian 1:8.2.2+ds-0ubuntu1.6)
OVMF Package Version: 2024.02-2ubuntu0.1

Suggested Fix

Modify Packer’s QEMU builder to automatically fallback to the new 4MB firmware files when the previous defaults are missing:

First try: The existing default EFI firmware paths.
If missing, fallback to: The 4MB firmware variants provided by Ubuntu 24.04.

This would maintain backward compatibility while supporting Ubuntu 24.04+ without requiring manual template modifications.

Log Fragments and crash.log files

Enable detailed logging:

export PACKER_LOG=1
packer build -var-file win11.pkrvars.hcl -only qemu.test_efi bug.pkr.hcl

2025/03/15 16:25:27 packer-plugin-qemu_v1.0.9_x5.0_linux_amd64 plugin: 2025/03/15 16:25:27 Looking for available port between 5900 and 6000 on 127.0.0.1
2025/03/15 16:25:27 packer-plugin-qemu_v1.0.9_x5.0_linux_amd64 plugin: 2025/03/15 16:25:27 Found available port: 5920 on IP: 127.0.0.1
2025/03/15 16:25:27 packer-plugin-qemu_v1.0.9_x5.0_linux_amd64 plugin: 2025/03/15 16:25:27 Found available VNC port: 5920 on IP: 127.0.0.1
==> qemu.test_efi: failed to read from efivars file at /usr/share/OVMF/OVMF_VARS.fd: open /usr/share/OVMF/OVMF_VARS.fd: no such file or directory
2025/03/15 16:25:27 packer-plugin-qemu_v1.0.9_x5.0_linux_amd64 plugin: 2025/03/15 16:25:27 failed to unlock port lockfile: close tcp 127.0.0.1:5920: use of closed network connection
==> qemu.test_efi: Deleting output directory...
2025/03/15 16:25:27 [INFO] (telemetry) ending qemu.test_efi
==> Wait completed after 11 seconds 246 milliseconds
2025/03/15 16:25:27 machine readable: error-count []string{"1"}
==> Some builds didn't complete successfully and had errors:
2025/03/15 16:25:27 machine readable: qemu.test_efi,error []string{"Build was halted."}
==> Builds finished but no artifacts were created.
Build 'qemu.test_efi' errored after 11 seconds 246 milliseconds: Build was halted.
2025/03/15 16:25:27 [INFO] (telemetry) Finalizing.

==> Wait completed after 11 seconds 246 milliseconds

==> Some builds didn't complete successfully and had errors:
--> qemu.test_efi: Build was halted.

==> Builds finished but no artifacts were created.
2025/03/15 16:25:28 waiting for all plugin processes to complete...
2025/03/15 16:25:28 /home/wenzel/.config/packer/plugins/github.com/hashicorp/qemu/packer-plugin-qemu_v1.0.9_x5.0_linux_amd64: plugin process exited

Logs showing the failure:

qemu.test_efi: failed to read from efivars file at /usr/share/OVMF/OVMF_VARS.fd: open /usr/share/OVMF/OVMF_VARS.fd: no such file or directory

Would it be possible for Packer to implement a fallback to the 4MB firmware files?

Thanks !

Mar 15 '25 15:03 Wenzel

@Wenzel Thanks for reporting this, packer template has the support, where you can mention the path for efi firmware related files efi_firmware_code and efi_firmware_vars. So this is the work around for this. Please try this out and let us know if this is solves your issue.

Apr 08 '25 03:04 anshulsharma-hashicorp

@anshulsharma-hashicorp Thanks for the quick reply.

Yes, manually specifying efi_firmware_code and efi_firmware_vars does work as a workaround. However, this issue is about Packer’s defaults breaking on modern systems:

Ubuntu 24.04 removed the default firmware files (OVMF_CODE.fd, OVMF_VARS.fd) that Packer expects.
As a result, any template using just efi_boot = true (without custom firmware paths) now fails out of the box.
This reduces portability across distros and versions—exactly what Packer aims to abstract away.

Why It Matters

This isn’t a configuration bug on the user side—it’s a systematic regression in how Packer handles firmware detection.

I'm happy to implement a fallback mechanism (e.g., try OVMF_CODE.fd, then fallback to OVMF_CODE_4M.fd), if you're open to a PR. Just point me to the relevant section of the QEMU builder code.

Let me know if this is acceptable and I’ll move forward.

Apr 09 '25 05:04 Wenzel

Hey @Wenzel as you rightly mentioned packer picks the default if the efi_boot is set to true, so instead of doing another lookup for another firmware file, we should be explicitly assigning those fields in the template, else this default lookup can keep on increasing.

I think it would be better to make efi_firmware_code and efi_firmware_vars fields mandatory in that case which will be a breaking change, that would take some time and should be highlighted with a major release.

Apr 09 '25 11:04 anshulsharma-hashicorp

You can have the same template on multiple systems and it might work on some but not on others because the EFI file names have changed. I can specify efi_firmware_code but whatever I specify may not work on a different system.

I really think it should work out of the box and let efi_firmware_code/vars be something that's configurable rather than required.

Sep 26 '25 22:09 computerquip-work