It is unfortunately possible to have driver perfectly installed and STILL get "inaccessible boot Device." The reason is a bit shocking (I find): a Win 10 installation "remembers" the drivers that were required when it was first installed, and by default WILL NOT load other storage drivers at boot time. This is done, it seems, to "piracy" -- it makes it difficult to run the "same" installation on different hardware. There is some great documentation on this "feature" in this post from the gentoo forums. The essence is as follows:
The Drivers that are targeted for forbidden-to-load-at-boot can be determined as follows:
Within the registry key Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services there is one subkey for every driver known to the installation. The name of this subkey is just the name of the driver. Within each driver subkey, there will be a subkey "STARTOVERRIDE" if that driver is to be prevented from loading at boot. In particular, within the STARTOVERRIDE subkey there is a parameter whose name is "0" . IF the value of this parameter is "3", it will not be loaded at boot time. Setting this value to 0 instead will 'override' behavior.
I myself just go to Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services and search for "STARTOVERRIDE". Each time i find it, if there is name under it called "0" with value "3", I change to "0". This seem to be overkill, you only need to change the drive that needs to load. In my case there are several of them, and I never remember which, so I just do an "F3-search" within that 'services' section.
And one final tip which isn't needed for current, signed, virtio storage, but might be to someone else reading this if they want to use a more experimental driver that is not (yet) signed: I found that EVEN after doing the above trick, I ALSO needed to boot into the advanced options screen and choose F7 ("disable driver signature verification"). Annoyingly, it wasn't enough to set the bcd flag to disable driver verification, because the driver needs to load before the machine reads the BCD and finds out that it doesn't need to verify the signature.
All in all, not Microsoft's most shining hour. You really have to hate your users if you'd rather give legit users a made-up artificial Blue-Screen than allow people to (say) replace a SATA disk with an NVMe disk and have it "just work."
+1. I couldn't figure out this issue myself. Following various workarounds for previous versions of Windows, I tried installing the VirtIO driver on the Windows VM after plugging in a VirtIO block device, but I still got
INACCESSIBLE_BOOT_DEVICE
blue screen. I ended up reinstalling on a VirtIO boot device. – Deltik – 2016-03-27T19:01:03.580Because I’m lazy, I’ll post it as a comment for you to verify: Add an additional disk, with virtio “controller”. Install driver when Windows asks you to. No need to create partitions or anything. Then switch the boot disk to virtio. Because a controller driver instance is now installed (very important), it should work. – Daniel B – 2016-03-31T18:53:38.553
@DanielB: That's exactly what I did. It appears that your suggestion works for previous versions of Windows, but not Windows 10. – Deltik – 2016-04-01T08:01:13.623
Hm, okay. Well I guess then I have the single best way not to solve your problem (lol): Just modify the Windows ISO and include the drivers. Keep in mind it needs to remain bootable. That way you can (hopefully) install straight to virtio. – Daniel B – 2016-04-01T21:21:01.940
1@DanielB: The VirtIO driver can be loaded in the installation process with a separate driver disc. If Windows 10 is installed with the VirtIO driver, there is no problem. It's just that the existing instructions on the Internet to switch Windows from IDE to VirtIO do not work for Windows 10 KVM virtual machines. – Deltik – 2016-04-03T10:51:27.460
@Deltik I know that. The OP however didn’t succeed in adding two optical drives to his VM. Of course, that could probably also be solved. – Daniel B – 2016-04-03T11:02:13.960
@DanielB, thanks for the tip. I later worked out that the CDROM related problems that I was having was a result of me using SCSI drives. If you use an SCSI drive, the installation will start OK but Windows 10 will then prompt for a driver. The problem I had was with Windows recognising that I had changed the disc, so I couldn't load the driver. Also, if you do two SCSI drives, only one will be recognised. IDE works fine though. Apparently using SCSI for the Windows disc and and IDE for the drivers works too (and gives a faster install). – Graeme – 2016-04-03T13:22:29.667