Skip to content

Correct paths for ovmf code & vars files - #540

Open
dharmit wants to merge 1 commit into
SUSE:mainfrom
dharmit:ovmf-file-path
Open

Correct paths for ovmf code & vars files#540
dharmit wants to merge 1 commit into
SUSE:mainfrom
dharmit:ovmf-file-path

Conversation

@dharmit

@dharmit dharmit commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

The files ovmf-x86_64-ms-code.bin and ovmf-x86_64-ms-vars.bin were recently removed from Tumbleweed. However, cookbook still carries the now inexistent file paths which are removed in this PR because:

  1. libvirt chooses helpful defaults by itself
  2. paths to these files could differ between distros, making libvirt the best judge to find and determine the required firmware files.

@dharmit
dharmit requested a review from a team as a code owner July 23, 2026 11:50
Comment thread docs/cookbook-first-time-use.md Outdated
--virt-type kvm \
--import \
--boot uefi,loader=/usr/share/qemu/ovmf-x86_64-ms-code.bin,nvram.template=/usr/share/qemu/ovmf-x86_64-ms-vars.bin
--boot uefi,loader=/usr/share/qemu/ovmf-x86_64-ms-4m-code.bin,nvram.template=/usr/share/qemu/ovmf-x86_64-ms-4m-vars.bin

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we just remove the loader parameters alltogether?

is this addressing the SL 16.1 issue that Joe reported? a bit more rationale would be nice

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a bit more rationale would be nice

Agree. Aplogies. Updated the PR description.

is this addressing the SL 16.1 issue that Joe reported?

I'm not sure as I am on a Tumbleweed system, but him mentioning this on Slack and a call reminded me to fix this problem I had noticed long back.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we just remove the loader parameters alltogether?

I gave this a shot and VMs spun up just fine. There was a difference in the firmware file that libvirt chose, but in a conversation Gemini suggested it's best to leave it to libvirt to choose thsee files.

Sharing some snippets from virsh dumpxml <vm>:

Without loader and nvram arguments

<loader readonly='yes' type='pflash' format='qcow2'>/usr/share/qemu/ovmf-x86_64-ms-4m-code.qcow2</loader>
<nvram template='/usr/share/qemu/ovmf-x86_64-ms-4m-vars.qcow2' templateFormat='qcow2' format='qcow2'>/var/lib/libvirt/qemu/nvram/node01_VARS.qcow2</nvram>

With the arguments

<loader readonly='yes' type='pflash' format='raw'>/usr/share/qemu/ovmf-x86_64-ms-4m-code.bin</loader>
<nvram template='/usr/share/qemu/ovmf-x86_64-ms-4m-vars.bin' templateFormat='raw' format='raw'>/var/lib/libvirt/qemu/nvram/node01_VARS.fd</nvram>

Without arguments for iso output. It sets the loader.type and loader.readonly as we need:

<loader readonly='yes' type='pflash' format='qcow2'>/usr/share/qemu/ovmf-x86_64-ms-4m-code.qcow2</loader>
<nvram template='/usr/share/qemu/ovmf-x86_64-ms-4m-vars.qcow2' templateFormat='qcow2' format='qcow2'>/var/lib/libvirt/qemu/nvram/customize-iso_VARS.qcow2</nvram>

Signed-off-by: Dharmit Shah <dharmit.shah@suse.com>

Removed the `loader` and `nvram` arguments from `--boot` flag because
without those libvirt is choosing the defaults that work just fine.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants