add deepseek and gemma results

1 files changed, 37 insertions, 0 deletions

diff --git a/results/classifier/gemma3:12b/boot/745 b/results/classifier/gemma3:12b/boot/745
new file mode 100644
index 00000000..b606c77c
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/745
@@ -0,0 +1,37 @@
+
+NVRAM is not persistent across coldboots without attached r/w FAT32 hard drive
+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:
+![no_hdd_pre-coldboot](/uploads/cb1da3e72a852ff1e7fd1b47afc9ba6e/no_hdd_pre-coldboot.png)
+
+Without HDD attached, after cold reboot:
+![no_hdd_post-coldboot](/uploads/d9622d4571ad8c046f51a00b26e8354e/no_hdd_post-coldboot.png)
+
+With HDD attached (note modification date / time of NvVars):
+![hdd_attached](/uploads/30135dd688f8c7e7ec2feccd69007258/hdd_attached.png)
+
+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).