Вот так можно «загрузиться» с физического GPT-диска:
sudo qemu-system-x86_64 -enable-kvm -m 8G -cpu host -smp 4 -drive file=/dev/sdb,format=raw,if=virtio -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,readonly=on -drive file=/usr/share/OVMF/OVMF_VARS.fd,if=pflash,format=raw -net nic -net user -boot menu=on
Так как там местами битые файлы, в т.ч. местами битые системные файлы, включая winload.efi, то «загрузиться» только до этапа bootmgfw.efi, но вы поняли идею.
Вот так можно загрузить эту VM с ISO:
sudo qemu-system-x86_64 -enable-kvm -m 8G -cpu host -smp 4 -drive file=/dev/sdb,format=raw,if=virtio -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,readonly=on -drive file=/usr/share/OVMF/OVMF_VARS.fd,if=pflash,format=raw -net nic -net user -boot menu=on -cdrom ~/VMs/win10/Win10_22H2_Russian_x64v1.iso
Вот только тогда загруженная с ISO система вообще не будет видеть диска, (да - диска - не разделов,) о чём будет сообщать diskpart list disk.
Но тот же ISO, загруженный без виртуализации через Ventoy видит тот же диск и разделы на нём. Можно было починить многие файлы через chkdsk /f.
Не понимаю в чём разница, не дающая загруженной c ISO системе (установщик/recovery) увидеть sdb при загрузке через qemu, хотя, опять таки, можно загрузиться из kvm с sdb.
Смысл финта в том, чтобы сделать bootrec /rebuildbcd, не давая ему доступа к физическому диску с Linux и не прибегая к отвёртке.
