Why Your QEMU VM is Booting to PXE Instead of Your Disk Image (And How to Fix It)

Have you ever set up a QEMU virtual machine, carefully prepared your disk image, and then found yourself staring at a PXE boot screen or UEFI shell instead of your operating system booting? This common frustration happens to many developers working with virtual machines. Let’s explore why this occurs and how to fix it.

The Problem: Unexpected PXE Boot

When you run a command like:

qemu-system-x86_64 -machine q35 -m 1024 -smp cpus=2 -cpu qemu64 \
  -drive if=pflash,format=raw,read-only=on,file=$PREFIX/share/qemu/edk2-x86_64-code.fd \
  -netdev user,id=n1,dns=8.8.8.8,hostfwd=tcp::2222-:22 \
  -device virtio-net,netdev=n1 \
  -nographic alpine.img

Instead of booting from your alpine.img disk, QEMU might start a PXE network boot or drop you into a UEFI shell:

UEFI Interactive Shell v2.2
EDK II
UEFI v2.70 (EDK II, 0x00010000)
Mapping table
     BLK0: Alias(s):
          PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell>

Why This Happens

1. Default Boot Order Behavior

QEMU typically defaults to a boot order that prioritizes network boot over disk boot. This behavior is especially common when using UEFI firmware (like EDK2/OVMF).

2. Missing Explicit Boot Device Specification

Without explicit instructions, QEMU relies on firmware defaults, which often try network boot first.

3. Drive Configuration Issues

The way the disk image is attached to the VM affects its detection as a bootable device.

4. UEFI vs Legacy BIOS Differences

UEFI systems have different boot behavior compared to legacy BIOS systems.

The Solutions

Solution 1: Explicit Boot Order Parameter

Add the -boot option to specify your boot preference:

qemu-system-x86_64 -machine q35 -m 1024 -smp cpus=2 -cpu qemu64 \
  -drive if=pflash,format=raw,read-only=on,file=$PREFIX/share/qemu/edk2-x86_64-code.fd \
  -netdev user,id=n1,dns=8.8.8.8,hostfwd=tcp::2222-:22 \
  -device virtio-net,netdev=n1 \
  -drive file=alpine.img,format=raw,if=virtio \
  -boot order=c \
  -nographic

Solution 2: Improved Drive Configuration

Modify how your disk is attached to the VM:

# Change from implicit interface to explicit virtio
-drive file=alpine.img,format=raw,if=virtio

The if=virtio parameter uses paravirtualized storage, which is both faster and more reliably detected.

Solution 3: Complete Boot Control

For maximum control over the boot process:

-boot order=c,menu=on,strict=on

This tells QEMU to:

• Boot from the hard disk first (order=c)
• Show a boot menu (menu=on)
• Strictly follow the specified order (strict=on)

Understanding Boot Order Options

The -boot order= parameter accepts these values:

• order=a - Floppy disk first
• order=c - Hard disk first (what we want)
• order=d - CD-ROM first
• order=n - Network boot first

What If You’re Already Stuck in the UEFI Shell?

If you find yourself at the UEFI shell prompt, here’s how to recover:

Exit the Shell:

exit

Reset the VM:

reset

Manually Boot from a Device:

fs0:  # or fs1:, fs2: - try different filesystems
ls    # list files to identify your Alpine installation
cd \EFI\BOOT
bootx64.efi

Force Quit QEMU:

Press Ctrl-A then X to quit QEMU completely.

Complete Working Command

Here’s the complete corrected command that should boot properly:

qemu-system-x86_64 -machine q35 -m 1024 -smp cpus=2 -cpu qemu64 \
  -drive if=pflash,format=raw,read-only=on,file=$PREFIX/share/qemu/edk2-x86_64-code.fd \
  -netdev user,id=n1,dns=8.8.8.8,hostfwd=tcp::2222-:22 \
  -device virtio-net,netdev=n1 \
  -drive file=alpine.img,format=raw,if=virtio \
  -boot order=c \
  -nographic

Key Takeaways

1. Always specify boot order — Don’t rely on QEMU defaults
2. Use explicit drive interfaces — if=virtio is more reliable than implicit interfaces
3. Understand UEFI behavior — UEFI firmware has different boot priorities than legacy BIOS
4. Test your images — Ensure your disk images are properly configured as bootable

By understanding these boot principles and using the explicit boot order parameter, you’ll avoid unexpected PXE boot attempts and ensure your virtual machines start exactly how you intend them to.

Have you encountered other QEMU boot issues? Share your experiences in the comments below!