OSDev.org

I'm trying to learn bare metal development with UEFI, I'm developing on Windows in Visual Studio, and I want to test my software in QEMU. The usual QEMU workflow that's described everywhere includes creating a FAT32 drive image file and specifying that file. But I don't know how to do this on Windows and I don't want to have to mess with it, I just want to use a local RAM disk, properly formatted and containing my EFI/BOOT/bootx64.efi file.

How to tell QEMU to use a local drive (e. g. Z:) for booting? What's the right command line incantation?

Booting from a physical drive is always open to problems. Get something wrong and you may erase your system drive.

Why not use qemu-img (which comes with qemu) to create and manage a disk image? It's very straightforward.

Corruption of the partition is not a problem, it's a ramdisk. Thanks for pointing me to qemu-img, but is there really no way to tell qemu to just boot from the damn partition I prepared for it?

You can give QEMU the UNC path to your disk.

But do you need to create a RAM disk at all? QEMU has built-in support for creating a FAT-formatted disk out of a directory. This is what I use for UEFI development.

I’m not thinking of corrupting the partition you want to use. Get something wrong and you could end up using the wrong partition.

You can certainly do what you want to - it’s described in the documentation ( https://www.qemu.org/docs/master/system/images.html ) but I would still recommend that you don’t. If you really don’t want to use a disk image use a virtual FAT image from a directory.

Octocontrabass wrote:But do you need to create a RAM disk at all? QEMU has built-in support for creating a FAT-formatted disk out of a directory. This is what I use for UEFI development.

Thank you, that does look like what I need! Could you please show your qemu invocation command line that works? I'm getting a "Block node is read-only" error (of course the boot partition should be read-only), and if I add "rw:" quemu does boot, but fails to see my bootloader, so I'm doing something wrong.

Does "fat" mean FAT32?

VioletGiraffe wrote:Could you please show your qemu invocation command line that works?

The EFI directory is inside the uefi-test directory.

VioletGiraffe wrote:Does "fat" mean FAT32?

Maybe, but it doesn't matter for testing in QEMU. OVMF works just as well with FAT12 and FAT16.

Any idea why it wouldn't work? Tried different options for the path - UNC/regular, absolute/relative, with/without the trailing slash, with/without quotes - it just boots into UEFI shell. Tried on a USB stick and a physical PC - boots fine.
The "BOOT" folder contains EFI\BOOT\bootx64.efi inside

VioletGiraffe wrote:

Code: Select all

OVMF_VARS.fd

Your NVRAM might have the boot order set incorrectly. Press ESC during boot to open the OVMF configuration, then use the Boot Maintenance Manager menu to fix the boot order.

Octocontrabass wrote:Your NVRAM might have the boot order set incorrectly. Press ESC during boot to open the OVMF configuration, then use the Boot Maintenance Manager menu to fix the boot order.

Spot on, thank you! Just removing the OVMF_VARS.fd drive from the command line did the trick.

I don't see anything here that addresses the real issue: that on Windows versions later than XP, ordinary software (such as the Windows port of the Unix dd utility) can't access the individual raw blocks of a hard drive as it could before, apparently for security reasons. It used to be that specifying the UNC path to the device (if you could figure it out; I can't) was sufficient to do it, but not anymore, as far as I can tell.

There must be ways to do it, of course, otherwise the OS itself couldn't function, but I've been waiting ten years now to find out how one does it in later versions of Windows. I vaguely recall having had a single instant of success with dd on a Windows 10 machine, but have never been able to reproduce whatever the magic incantation was that I hit by accident that once. Maybe I accidentally specified a device that wasn't a hard drive: CD-ROM and DVD-ROM discs seem to be exempt from the general ban on block-level access.

Relevance here is that QEMU seems to be happy to accept either N: or \\.\N: as a -hda device specification on the launch command, but clearly just hangs when it tries to actually access the drive, when N: is physically a SATA hard drive connected via a SATA-to-USB adapter. (It's even worse if the drive is a thumbdrive named O: -- QEMU rejects the attempt to specify either O: or \\.\O: out of hand, seemingly without even trying to access the device (though I can't really be sure, as there are no "drive activity lights" anymore, in this century).

So the question that's actually being asked, and has not yet been adequately answered, here is: How do we get QEMU to bypass the Windows-later-than-XP restriction against accessing raw hard-drive blocks, and use a physical hard drive as a drive for the emulated computer?

Discuss.

ChrisChiesa wrote:How do we get QEMU to bypass the Windows-later-than-XP restriction against accessing raw hard-drive blocks, and use a physical hard drive as a drive for the emulated computer?

Generally you don't, because it's a terrible idea to do that on Windows. If you must, the syntax to point QEMU to a whole drive is documented, but it might also require administrator privileges and making sure any volumes on that drive are unmounted.