Di recente ho riscontrato questo problema e dopo diversi giorni di debug ho scoperto il problema e risolto il problema.
Rullo di tamburi prego:
Dopo aver installato Hyper-V Server 2016, utilizzare uno strumento offline (come, ad esempio, Windows PE) per montare l'hive di SISTEMA della nuova installazione e modificare DWORD ControlSet001 \ Control \ BootDriverFlags da 0x04 a 0x1c. (Probabilmente dovresti cambiare anche la versione di ControlSet002 per buona misura, e puoi effettuare le modifiche nel tuo install.wim per evitare di doverlo fare dopo ogni installazione.)
(Perché ovviamente ci vuole una settimana e un debugger del kernel per capire che richiede solo una modifica di due bit in un campo oscuro oscuro e completamente privo di documenti.)
Ecco perché.
Il boot loader di Windows utilizza routine UEFI integrate per trovare l'installazione di Windows e carica il kernel e i driver di avvio nella RAM prima di chiamare ExitBootServices. Una volta fatto questo e passato il controllo al kernel, il kernel non può accedere al volume di avvio a meno che i driver appropriati non siano già presenti nella RAM.
Ecco il kicker, però: winload.efi non è abbastanza complesso per enumerare l'hardware e determinare quali driver sono effettivamente richiesti. Nelle versioni precedenti carica solo le cose impostate su Boot Start. Tuttavia, il caricamento di driver estranei comporta una riduzione delle prestazioni e poiché Windows ha iniziato a supportare più classi di dispositivi di avvio, era necessario un sistema migliore.
Immettere il valore BootFlags sui singoli driver e il valore BootDriverFlags a livello di sistema. Se (BootFlags & BootDriverFlags)! = 0, il driver verrà caricato anche se non è impostato su Boot Start. Ogni bit nel valore dovrebbe corrispondere a un diverso tipo di hardware, quindi il valore BootDriverFlags imposta da quali tipi di hardware può essere avviato.
Quando fu introdotto questo meccanismo, Bit 3 fu designato per i dispositivi di avvio USB, ma l'avvio da dispositivi USB non era supportato in Windows standard. La versione di Hyper-V Server 2008 R2 ha aggiunto il supporto specifico per l'avvio da USB impostando questo valore su 0x04 e questo valore è stato impostato in ogni versione di Hyper-V Server rilasciata da allora.
I miglioramenti generali apportati da allora per supportare la funzionalità Windows To Go significano che non è necessario utilizzare il trucco da avvio a VHD consigliato per le versioni precedenti di Hyper-V Server installato su dispositivi USB. Tuttavia, cambiano anche il significato del valore BootDriverFlags. Ai dispositivi USB 3 è stato assegnato un bit separato e alle schede SD è stato assegnato un ulteriore bit.
Nella versione 2016, ciò significa che un valore di 0x04 ora consente l'avvio solo da dischi USB2 che non sono schede SD. Tutte le versioni di Server 2016 tranne Hyper-V Server vengono fornite con il valore predefinito 0x1c, che consente l'avvio della scheda USB2, USB3 e SD; tuttavia, il valore di 0x04 è ancora impostato nel server Hyper-V, poiché è stato aggiunto come sostituzione nel processo di generazione dell'immagine per la versione 2008R2. Invece di aggiungere una funzione, questo valore ora la rimuove.
Questo spiega perché alcune soluzioni precedenti a questo problema consigliavano di disabilitare USB3 e l'avvio da una chiavetta USB anziché dalla scheda SD: ciò costringerebbe la categoria del dispositivo di avvio a essere ancora coperta dalla definizione ora più limitata di "USB "bit in BootDriverFlags.