NVRAM is not persistent across coldboots without attached r/w FAT32 hard drive

Host environment

• Operating system: Pop!_OS 21.04 (Ubuntu / hirsute)
• OS/kernel version: Linux stratosphere 5.13.0-7620-generic #20~1634827117~21.04~874b071-Ubuntu SMP Fri Oct 29 15:06:55 UTC x86_64 x86_64 x86_64 GNU/Linux
• Architecture: x86_64
• QEMU flavor: qemu-system-x86_64
• QEMU version: QEMU emulator version 6.2.91 (v6.2.0-rc1-94-g35133781bd)
• QEMU command line: Without hard drive attached:

  qemu-system-x86_64 -M q35 -drive if=pflash,format=raw,readonly=on,file=./OVMF_CODE_4M.fd -drive if=pflash,format=raw,file=./OVMF_VARS.fd -monitor stdio

  With hard drive attached:

  qemu-system-x86_64 -M q35 -drive if=pflash,format=raw,readonly=on,file=./OVMF_CODE_4M.fd -drive if=pflash,format=raw,file=./OVMF_VARS.fd -hda ./EXAMPLE.qcow2 -monitor stdio

Emulated/Virtualized environment

• Operating system: N/A
• OS/kernel version: N/A
• Architecture: x86_64

Description of problem

NVRAM variables are not persistent across coldboots without an attached readable / writable FAT32 hard drive.

Steps to reproduce

Without hard drive:

1. Start VM as above ("without hard drive attached"), and enter EFI shell.
2. Dump the contents of a NVRAM variable, e.g. Lang. Note the contents.
3. Edit the contents of that variable.
4. Shutdown and restart the VM (cold reboot), and enter the EFI shell.
5. Dump the contents of the same NVRAM variable. The contents have reverted to what they were in Step 2.

With hard drive:

1. Start VM as above ("with hard drive attached"), and enter EFI shell.
2. Navigate to the hard drive filesystem, e.g. FS0.
3. List the files in the filesystem. If NvVars exists, note the modification time.
4. Edit the contents of a NVRAM variable, e.g. Lang.
5. List the files of the filesystem. The NvVars file either now exists, or has notably been modified since Step 3.

Additional information

OVMF blobs used: Those found in the Debian Sid package "ovmf_2021.11_rc1-1_all.deb" (https://packages.debian.org/sid/ovmf)

Note that, without a hard drive attached, edited NVRAM variables persist across warm reboots, e.g. via the EFI shell command reset.

I have not tested filesystem formats other than FAT32 with the attached hard drive, though I assume that would be futile due to the UEFI specification stating that EFI only supports FAT-based filesystems by default.

Without HDD attached, before cold reboot:

Without HDD attached, after cold reboot:

With HDD attached (note modification date / time of NvVars):

This issue leads to modern macOS's installation process failing, as it relies on being able to modify NVRAM variables to know how far along in the installation process it is. Without these variables, the installation process will loop indefinitely, as it can't know when to move on to the next part of the overall process.

Let me know if more information is needed, or if this is an issue better suited for the OVMF bug tracker (which I do not know the location of).