Ostatnio napotkałem ten problem i po kilku dniach debugowania odkryłem problem i go naprawiłem.
Proszę o werble:
Po zainstalowaniu serwera Hyper-V Server 2016 użyj narzędzia offline (np. Windows PE), aby zamontować gałąź SYSTEM nowej instalacji i zmień DWORD ControlSet001 \ Control \ BootDriverFlags z 0x04 na 0x1c. (Prawdopodobnie powinieneś również zmienić wersję ControlSet002 dla zachowania dobrej ostrożności i możesz upiec zmiany w swoim install.wim, aby uniknąć konieczności robienia tego po każdej instalacji).
(Ponieważ oczywiście zajmuje to tydzień i debugger jądra, aby dowiedzieć się, że wymaga tylko dwóch bitów zmiany w niejasnym i całkowicie nieudokumentowanym polu bitowym.)
Dlatego.
Moduł ładujący Windows używa wbudowanych procedur UEFI do znalezienia instalacji Windows i ładuje jądro i sterowniki rozruchowe do pamięci RAM przed wywołaniem ExitBootServices. Po wykonaniu tej czynności i przekazaniu kontroli do jądra, jądro nie może uzyskać dostępu do woluminu rozruchowego, chyba że odpowiednie sterowniki są już obecne w pamięci RAM.
Oto kicker: winload.efi nie jest wystarczająco skomplikowany, aby wyliczyć sprzęt i ustalić, jakie sterowniki są rzeczywiście wymagane. W starszych wersjach ładowałoby tylko rzeczy ustawione na Boot Start. Jednak ładowanie obcych sterowników powoduje obniżenie wydajności, a ponieważ system Windows zaczął obsługiwać więcej klas urządzeń rozruchowych, potrzebny był lepszy system.
Wprowadź wartość BootFlags na poszczególnych sterownikach i ogólnosystemową wartość BootDriverFlags. Jeśli (BootFlags & BootDriverFlags)! = 0, sterownik zostanie załadowany, nawet jeśli nie jest ustawiony na Boot Start. Każdy bit wartości powinien odpowiadać innemu typowi sprzętu, więc wartość BootDriverFlags określa, z jakiego rodzaju sprzętu można uruchomić komputer.
Kiedy ten mechanizm został wprowadzony, Bit 3 został wyznaczony dla urządzeń rozruchowych USB, ale uruchamianie z urządzeń USB nie było obsługiwane w standardowym systemie Windows. Wersja Hyper-V Server 2008 R2 dodała konkretną obsługę rozruchu z USB, ustawiając tę wartość na 0x04, a wartość ta została ustawiona w każdej wydanej wersji serwera Hyper-V.
Ogólne ulepszenia wprowadzone od tego czasu w celu obsługi funkcji Windows To Go oznaczają, że nie musisz używać sztuczki rozruchu do VHD zalecanej dla poprzednich wersji serwera Hyper-V zainstalowanego na urządzeniach USB. Zmieniają jednak także znaczenie wartości BootDriverFlags. Urządzenia USB 3 otrzymały osobny bit, a karty SD otrzymały jeszcze jeden bit.
W wersji 2016 oznacza to, że wartość 0x04 umożliwia teraz uruchamianie tylko z dysków USB2, które nie są kartami SD. Wszystkie wersje serwera 2016 oprócz serwera Hyper-V są dostarczane z domyślną wartością 0x1c, która umożliwia rozruch z USB2, USB3 i karty SD; jednak wartość 0x04 jest nadal ustawiona na serwerze Hyper-V, ponieważ została dodana jako przesłonięcie w procesie kompilacji obrazu dla wersji 2008R2. Jednak zamiast dodawać funkcję, ta wartość teraz ją usuwa.
To wyjaśnia, dlaczego niektóre poprzednie rozwiązania tego problemu zalecały wyłączenie USB3 i uruchamianie z pamięci USB zamiast karty SD: to wymusiłoby kategorię urządzenia rozruchowego jako coś, co jest nadal objęte bardziej ograniczoną definicją „USB” "bit w BootDriverFlags.