J'ai rencontré ce problème récemment et après plusieurs jours de débogage, j'ai découvert le problème et l'ai résolu.
Roulement de tambour s'il vous plaît:
Après avoir installé Hyper-V Server 2016, utilisez un outil hors ligne (comme, par exemple, Windows PE) pour monter la ruche SYSTEM de la nouvelle installation et modifiez le DWORD ControlSet001 \ Control \ BootDriverFlags de 0x04 à 0x1c. (Vous devriez probablement changer la version de ControlSet002 également pour faire bonne mesure, et vous pouvez intégrer les modifications dans votre install.wim pour éviter d'avoir à le faire après chaque installation.)
(Parce que, bien sûr, il faut une semaine et un débogueur de noyau pour comprendre qu'il suffit d'un changement de deux bits dans un champ de bits obscur et complètement non documenté.)
Voici pourquoi.
Le chargeur de démarrage Windows utilise des routines UEFI intégrées pour trouver l'installation de Windows et charge le noyau et les pilotes de démarrage dans la RAM avant d'appeler ExitBootServices. Une fois qu'il a fait cela et passé le contrôle au noyau, le noyau ne peut pas accéder au volume de démarrage à moins que les pilotes appropriés soient déjà présents dans la RAM.
Voici le kicker, cependant: winload.efi n'est pas assez complexe pour énumérer le matériel et déterminer quels pilotes sont réellement requis. Dans les anciennes versions, il ne chargeait que les éléments définis sur Boot Start. Cependant, le chargement de pilotes étrangers entraîne une baisse des performances, et comme Windows a commencé à prendre en charge plus de classes de périphériques de démarrage, un meilleur système était nécessaire.
Entrez la valeur BootFlags sur les pilotes individuels et la valeur BootDriverFlags à l'échelle du système. Si (BootFlags & BootDriverFlags)! = 0, le pilote sera chargé même s'il n'est pas défini sur Boot Start. Chaque bit de la valeur est censé correspondre à un type de matériel différent, de sorte que la valeur BootDriverFlags définit les types de matériel à partir desquels il est possible de démarrer.
Lorsque ce mécanisme a été introduit, le bit 3 était destiné aux périphériques de démarrage USB, mais le démarrage à partir de périphériques USB n'était pas pris en charge dans Windows standard. La version Hyper-V Server 2008 R2 a ajouté une prise en charge spécifique pour le démarrage à partir d'USB en définissant cette valeur sur 0x04, et cette valeur a été définie dans chaque version d'Hyper-V Server publiée depuis.
Les améliorations générales apportées depuis lors pour prendre en charge la fonctionnalité Windows To Go signifient que vous n'avez pas à utiliser l'astuce de démarrage sur VHD recommandée pour les versions précédentes d'Hyper-V Server installées sur des périphériques USB. Cependant, ils modifient également la signification de la valeur BootDriverFlags. Les périphériques USB 3 ont reçu un bit séparé, et les cartes SD en particulier ont reçu un autre bit.
Dans la version 2016, cela signifie qu'une valeur de 0x04 permet désormais de démarrer uniquement à partir de disques USB2 qui ne sont pas des cartes SD. Toutes les versions de Server 2016 sauf Hyper-V Server sont livrées avec la valeur par défaut de 0x1c, qui permet le démarrage de la carte USB2, USB3 et SD; cependant, la valeur de 0x04 est toujours définie dans Hyper-V Server, car elle a été ajoutée en tant que remplacement dans le processus de création d'image pour la version 2008R2. Au lieu d'ajouter une fonctionnalité, cette valeur la supprime désormais.
Cela explique pourquoi certaines solutions précédentes à ce problème recommandaient de désactiver USB3 et de démarrer à partir d'une clé USB au lieu de la carte SD: cela forcerait la catégorie du périphérique de démarrage à être encore couverte par la définition désormais plus limitée du "USB". "bit dans BootDriverFlags.