gmipf · 2026-07-13T13:17:26Z

OVMF_CODE_4M.fd is a 4 MiB build, but the repository only ships 128 KiB variable stores. QEMU maps both pflash images so the pair ends at the 4 GiB mark, and OVMF has the address of its variable store compiled in — so a 4M CODE image paired with a 128K VARS image looks for its variables 0x64000 bytes away from where they actually are.

This does not fail loudly, which is why it is easy to miss. The guest boots, the firmware setup opens and accepts changes, and nothing is written back:

"Preferred Resolution at Next Boot" stays Unset, however often it is committed
OpenCore's NVRAM writes are lost across reboots
the mtime of the nvram file never moves — the quickest way to confirm it

OVMF_VARS.fd, OVMF_VARS-1024x768.fd and OVMF_VARS-1920x1080.fd are all 2 MiB-era stores, and all three are byte for byte identical: empty templates whose file names promise a resolution that was never baked in.

This adds OVMF_VARS_4M.fd (540672 B, converted from the edk2 package with qemu-img convert -O raw) and uses it wherever OVMF_CODE_4M.fd is used. It also points the Catalina template at an OVMF file that is present at all — it currently references OVMF_CODE.fd, which is not in the repository.

OVMF-notes.txt gains a short section on the pairing, so the next person does not have to rediscover it.

Prepared with AI assistance (Claude Opus 4.8) and reviewed before submission.

OVMF_CODE_4M.fd is a 4 MiB build, but the repository only ships 128 KiB variable stores. QEMU maps both pflash images so the pair ends at 4 GiB, and OVMF has the address of its store compiled in, so a 4M CODE image paired with a 128K VARS image looks for its variables 0x64000 bytes away from where they are. This does not fail loudly. The guest boots, the firmware setup opens and accepts changes, and nothing is written back. Symptoms: - "Preferred Resolution at Next Boot" stays Unset however often it is committed - OpenCore's NVRAM writes are lost across reboots - the mtime of the nvram file never moves OVMF_VARS.fd, OVMF_VARS-1024x768.fd and OVMF_VARS-1920x1080.fd are all 2 MiB-era stores and are byte for byte identical: empty templates whose names promise a resolution that was never baked in. Add OVMF_VARS_4M.fd (540672 B, converted from the edk2 package) and use it wherever OVMF_CODE_4M.fd is used. Also point the Catalina template at an OVMF file that is actually present. OVMF-notes.txt explains the pairing so the next person does not have to rediscover it.

Navigation Menu

Uh oh!

Ship a 4M variable store so UEFI variables survive a reboot - #278