Share via

INACCESSIBLE BOOT DEVICE - after WinPE-installed Windows 11 on Qemu-KVM

lejeczek 0 Reputation points
2025-10-26T06:33:12.6133333+00:00

Hi guys.

I have winpe-deployed - over iPXE - win11 pro 24H2, whose installation works a ok, meaning installer reports no issues and then - very first time installer reboots - win11 fails to boot with the error as per title.

WinPE is rendered wholly on such one win11 with everything updated to date.

This deployment is in a VM on Qemu-KVM and relevant "hardware" drivers are included in WinPE - obviously, since winpe-install process works.

Now the "best" bit, the trick - the same everything, same configs, same binaries, only in the installer "previous installation method" (or whatever official nomenclature calls it, I loosely translate from another lang) - installation which looks (also works?) like win10 - is chosen, then..... bravo! NO issues.

I do not use windows so I'm guessing - seems like "win11" method does not whereas "win10" method does do "copy" necessary "stuff" across into resulting installed-target windows?

I'm thinking - it's only microsoft - but has anybody seen this or similar? If yes, then, if yes you do have a solution can you share it? But, all & any thoughts are much appreciated.

many thanks, L.

Windows for business | Windows Client for IT Pros | Devices and deployment | Set up, install, or upgrade
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. VivianPhan-0145 3,470 Reputation points Independent Advisor
    2025-10-26T11:31:19.8166667+00:00

    Hi lejeczek,

    My research shows that error you encountered possibly means that the storage controller driver used during setup was available in WinPE but not automatically carried over into the installed OS. The “Windows 10‑style” setup path you mentioned copies a broader set of drivers into the target image, which is why it succeeds. WinPE can see the virtual disk because you injected VirtIO drivers there, but the installed Windows 11 image doesn’t automatically inherit them unless explicitly staged. The newer installer is stricter about which drivers it carries forward. The “legacy” (Windows 10‑like) path still stages them, but the modern one doesn’t.

    The fix is to inject the VirtIO drivers into the offline Windows image with DISM before deployment, or continue using the “Windows 10” style installer which stages them automatically. You can try this instruction:

    1. Inject VirtIO drivers into the offline Windows image

    Mount the install.wim (or install.esd) you’re deploying.

    Use DISM to add the VirtIO storage drivers:

    powershell

    dism /Mount-Image /ImageFile:D:\sources\install.wim /Index:1 /MountDir:C:\Mount
dism /Image:C:\Mount /Add-Driver /Driver:D:\virtio\viostor\w11\amd64 /Recurse
dism /Unmount-Image /MountDir:C:\Mount /Commit

    Replace paths with your actual VirtIO ISO driver locations.

    1. Confirm boot device type

    If you’re using VirtIO SCSI or VirtIO Block, make sure the corresponding driver is injected.

    For NVMe emulation, ensure the Windows 11 inbox NVMe driver is present (it usually is).

    1. Adjust QEMU/KVM settings

    Use -device virtio-scsi-pci or -device virtio-blk-pci consistently.

    Ensure the VM firmware (OVMF/UEFI) is up to date.

    1. Test with “Windows 10” installer mode
    • As you noticed, the legacy installer path works because it stages more drivers. That’s a valid workaround, but injecting drivers properly makes the “Windows 11” path work too.

    If you find this information useful to some extent, don't forget to accept the answer so that your experience with the issue would help contribute to the whole community. Thank you :)

    Vivian

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.