Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#76238 - [edk2-ovmf] Set FD_SIZE_4MB for EFI targets

Attached to Project: Arch Linux
Opened by Konstantin Gizdov (kgizdov) - Tuesday, 18 October 2022, 19:47 GMT
Last edited by David Runge (dvzrv) - Sunday, 27 November 2022, 16:27 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Anatol Pomozov (anatolik)
David Runge (dvzrv)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


This seems to be a hard blocker for Windows guest VMs trying to keep up-to-date after KB5012170. Related upstream discussion: Fedora also seems to use 4MB FD size:
which apparently has resolved the issue.

Additional info:
* package version(s): 202208-1
* config and/or log files etc.: N/A
* link to upstream bug report, if any: see discussion link above, but also check known issues at

The relevant line in the PKGBUILD is at:

Steps to reproduce:
1. Build any Windows 10/11 guest VM with UEFI with OVMF firmware
2. Run Windows update
3. Get error 0x80248007
This task depends upon

Closed by  David Runge (dvzrv)
Sunday, 27 November 2022, 16:27 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with edk2-ovmf 202208-3
Comment by Konstantin Gizdov (kgizdov) - Tuesday, 18 October 2022, 20:18 GMT
I guess we have to provide 4mb variants for the secure boot ones. I am experimenting with some of them to see which ones work. If you know how to do it quickly, it'd would save me some hassle and I can test on my machine.
Comment by Konstantin Gizdov (kgizdov) - Tuesday, 18 October 2022, 20:40 GMT
I've got this so far -
Comment by Konstantin Gizdov (kgizdov) - Tuesday, 18 October 2022, 23:41 GMT
I've got all the json files and a working PKGBUILD in the zip for testing.
Comment by nl6720 (nl6720) - Wednesday, 19 October 2022, 06:58 GMT
If 4MB FD is the future, then there's no need for json files for non-4MB firmware.
Comment by Konstantin Gizdov (kgizdov) - Wednesday, 19 October 2022, 10:59 GMT
Sure, but I can't find a concrete confirmation that that's the case.
Comment by Konstantin Gizdov (kgizdov) - Wednesday, 19 October 2022, 11:22 GMT
edk2-ovmf-202208-2 is in testing - please have a look and test
Comment by Pascal Ernster (hardfalcon) - Wednesday, 19 October 2022, 18:43 GMT
edk2-ovmf-202208-2 causes my x86_64 libvirt VMs to fail during boot with the following error message:

!!!! X64 Exception Type - 06(#UD - Invalid Opcode) CPU Apic ID - 00000000 !!!!
RIP - 0000000000030000, CS - 0000000000000038, RFLAGS - 0000000000010246
RAX - 0000000000000000, RCX - 0000000000000000, RDX - 0000000000000000
RBX - FFFFFFFFFFFFFFFF, RSP - 000000007EFA7E18, RBP - 000000007EFA7EA0
RSI - 000000007E8EC018, RDI - 000000007EFC6938
R8 - 0000000000000000, R9 - 0000000003041001, R10 - 000000000000003C
R11 - 000000007EFBF5F8, R12 - 000000007EFA7E98, R13 - 0000000000000001
R14 - 000000008000F880, R15 - 000000008000F840
DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030
GS - 0000000000000030, SS - 0000000000000030
CR0 - 0000000080010033, CR2 - 0000000000000000, CR3 - 000000007EC01000
CR4 - 0000000000000668, CR8 - 0000000000000000
DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 000000007E9E2000 0000000000000047, LDTR - 0000000000000000
IDTR - 000000007E5B7018 0000000000000FFF, TR - 0000000000000000
FXSAVE_STATE - 000000007EFA7A70
!!!! Can't find image information. !!!!

I don't use a boot loader on these VMs, but use the following section in the VM's libvirt configuration:

<os firmware="efi">
<type arch="x86_64" machine="pc-q35-7.1">hvm</type>
<cmdline>root=/dev/vda rootfstype=btrfs rootflags=compress=zstd,subvol=/archlinux rw console=ttyS0,115200 add_efi_memmap intel_iommu=on lockdown=confidentiality usbcore.nousb</cmdline>
<bootmenu enable="no"/>
Comment by Pascal Ernster (hardfalcon) - Friday, 21 October 2022, 04:30 GMT
I've found two possible solutions for the problem:

a) Shut the VM down, then run something like
cat cp /usr/share/edk2/ovmf-4m/OVMF_VARS.fd > /var/lib/libvirt/qemu/nvram/nameofyourvirtualmachine_VARS.fd
Then start the VM again.
This solution results in the VM using the new 4M UEFI image with a 528K configuration storage file, but has the adverse side effect of loosing/resetting all your existing VM-specific EFI settings, EFI variables, etc for that VM.

b) Shut the VM down, then use "virsh edit nameofyourvirtualmachine" or virt-manager to edit the VM's XML definition/configuration.
Replace the line

<os firmware="efi">



and inside the <os> element, insert/add something like the following two lines:
<loader readonly='yes' type='pflash'>/usr/share/edk2-ovmf/x64/OVMF_CODE.secboot.fd</loader>

Then start the VM again.
This solution results in the VM using the old 2M UEFI image with a 128K configuration storage file, and has the advantage of keeping all your existing VM-specific EFI settings, EFI variables, etc for that VM. However, if you're running Windows 10 or Windows 11 inside your VM, recent Windows updates might require you to use solution A.
Comment by David Runge (dvzrv) - Friday, 21 October 2022, 12:36 GMT
@kgizdov: Please make sure to move the new files to the /usr/share/edk2-ovmf/ dir before moving this to [extra].
Comment by David Runge (dvzrv) - Friday, 11 November 2022, 08:15 GMT
@kgizdov: If this is better fixed with the 4M version of the firmware, we should just ship that then.

However, this will also come with a reset of the vars of those machines. It's a bit unclear how to best proceed here.
I'm not running any windows vms, so I don't really care, but users will.
Comment by David Runge (dvzrv) - Friday, 11 November 2022, 11:26 GMT
I have moved the 4M versions of the files to their (more correct) location below /usr/share/edk2-ovmf/ to adhere to our packaging guidelines.

When looking at the issues people would be facing all across the board (not just for specific versions of windows 10/11), it seemed better to provide the 4M versions separately.
This way people should not run into problems out-of-the-box, but we should add the information that Pascal is mentioning to the wiki somewhere.
Comment by Luis Bourgard (unnilquadium) - Wednesday, 23 November 2022, 20:21 GMT
@dvzrv: Thank you! I think this can be considered fixed. The new version works wonderfully.