Ich bin kürzlich auf dieses Problem gestoßen, und nach mehreren Tagen des Debuggens habe ich das Problem entdeckt und behoben.
Trommelwirbel bitte:
Verwenden Sie nach der Installation von Hyper-V Server 2016 ein Offline-Tool (z. B. Windows PE), um die SYSTEM-Struktur der neuen Installation bereitzustellen, und ändern Sie die DWORD ControlSet001 \ Control \ BootDriverFlags von 0x04 in 0x1c. (Sie sollten wahrscheinlich auch die ControlSet002-Version ändern, und Sie können die Änderungen in Ihre install.wim einbinden, um zu vermeiden, dass Sie dies nach jeder Installation tun müssen.)
( Natürlich dauert es eine Woche und ein Kernel-Debugger, um herauszufinden, dass nur eine Zwei-Bit-Änderung in einem obskuren und vollständig undokumentierten Bitfeld erforderlich ist.)
Hier ist der Grund.
Der Windows-Bootloader verwendet integrierte UEFI-Routinen, um die Windows-Installation zu finden, und lädt den Kernel und die Boot-Treiber in den RAM, bevor ExitBootServices aufgerufen wird. Sobald dies geschehen ist und die Steuerung an den Kernel übergeben wurde, kann der Kernel nicht auf das Startvolume zugreifen, es sei denn, die entsprechenden Treiber sind bereits im RAM vorhanden.
Hier ist jedoch der Kicker: winload.efi ist nicht komplex genug, um die Hardware aufzulisten und festzustellen, welche Treiber tatsächlich benötigt werden. In älteren Versionen werden nur Dinge geladen, die auf Boot Start eingestellt sind. Das Laden von externen Treibern führt jedoch zu Leistungseinbußen. Als Windows mehr Klassen von Startgeräten unterstützte, wurde ein besseres System benötigt.
Geben Sie den BootFlags-Wert für einzelne Treiber und den systemweiten BootDriverFlags-Wert ein. Wenn (BootFlags & BootDriverFlags)! = 0, wird der Treiber geladen, auch wenn er nicht auf Boot Start eingestellt ist. Jedes Bit im Wert soll einem anderen Hardwaretyp entsprechen, daher legt der BootDriverFlags-Wert fest, von welchen Hardwaretypen gestartet werden kann.
Als dieser Mechanismus eingeführt wurde, war Bit 3 für USB-Startgeräte vorgesehen, aber das Booten von USB-Geräten wurde in Standard-Windows nicht unterstützt. In der Version Hyper-V Server 2008 R2 wurde eine spezielle Unterstützung für das Booten von USB hinzugefügt, indem dieser Wert auf 0x04 festgelegt wurde. Dieser Wert wurde in jeder Version von Hyper-V Server festgelegt, die seitdem veröffentlicht wurde.
Die allgemeinen Verbesserungen, die seitdem zur Unterstützung der Windows To Go-Funktion vorgenommen wurden, bedeuten, dass Sie nicht den Boot-to-VHD-Trick verwenden müssen, der für frühere Versionen von Hyper-V Server empfohlen wurde, die auf USB-Geräten installiert sind. Sie ändern jedoch auch die Bedeutung des BootDriverFlags-Werts. USB 3-Geräte haben ein separates Bit erhalten, und SD-Karten haben speziell ein weiteres Bit erhalten.
In der Version 2016 bedeutet dies, dass der Wert 0x04 jetzt das Booten nur von USB2-Festplatten ermöglicht, die keine SD-Karten sind. Alle Versionen von Server 2016 mit Ausnahme von Hyper-V Server werden mit dem Standardwert 0x1c ausgeliefert, der das Booten von USB2-, USB3- und SD-Karten ermöglicht. Der Wert 0x04 wird jedoch weiterhin in Hyper-V Server festgelegt, da er beim Erstellen des Image für die Version 2008R2 als Überschreibung hinzugefügt wurde. Anstatt ein Feature hinzuzufügen, wird es durch diesen Wert jetzt entfernt.
Dies erklärt, warum einige frühere Lösungen für dieses Problem empfohlen haben, USB3 zu deaktivieren und von einem USB-Stick anstelle der SD-Karte zu booten: Dies würde dazu führen, dass die Kategorie des Startgeräts immer noch von der jetzt eingeschränkteren Definition des Begriffs "USB" abgedeckt wird "Bit in BootDriverFlags.