1 files changed, 48 insertions, 0 deletions
diff --git a/results/classifier/118/none/1074 b/results/classifier/118/none/1074
new file mode 100644
index 000000000..a985e2361
--- /dev/null
+++ b/results/classifier/118/none/1074
@@ -0,0 +1,48 @@
+debug: 0.734
+boot: 0.701
+files: 0.683
+graphic: 0.671
+device: 0.660
+semantic: 0.543
+architecture: 0.512
+ppc: 0.492
+PID: 0.417
+vnc: 0.376
+register: 0.360
+x86: 0.358
+network: 0.347
+socket: 0.336
+risc-v: 0.330
+arm: 0.317
+i386: 0.300
+kernel: 0.290
+user-level: 0.276
+VMM: 0.267
+TCG: 0.260
+performance: 0.254
+permissions: 0.240
+virtual: 0.240
+hypervisor: 0.204
+mistranslation: 0.198
+peripherals: 0.198
+KVM: 0.171
+assembly: 0.083
+
+File under symlink gets corrupted when directory is mounted as FAT32 drive
+Description of problem:
+When mouting a directory as a FAT32 drive, the symlinked BOOTx64.EFI inside gets corrupted after booting it.
+Steps to reproduce:
+1. mkdir -p fat_dir/EFI/BOOT/
+2. ln -s BOOTx64.EFI fat_dir/EFI/BOOT/BOOTx64.EFI
+3. md5sum BOOTx64.EFI
+4. Run qemu with arguments like above.
+5. md5sum BOOTx64.EFI should print out different hash, confirming corruption.
+Additional information:
+[BOOTx64.EFI](/uploads/d0a6e899ec9331461179f8dc82fbc421/BOOTx64.EFI)
+
+The issue was not visible on earlier versions, but I don't know which one exactly was it.\
+I can only say, it was still working in April and it was possible that I was using Fedora 36 Beta.
+
+Copying the file instead of using a symlink can be used as a workaround.
+
+The binary should print some debug stuff, like avaliable memory regions and end with an infinite halt-loop.