मुझे हाल ही में इस समस्या का सामना करना पड़ा, और कई दिनों की डिबगिंग के बाद, मैंने इस मुद्दे की खोज की और इसे ठीक किया।
ड्रम रोल बजाएं:
हाइपर- V सर्वर 2016 को स्थापित करने के बाद, नए इंस्टॉलेशन के सिस्टम हाइव को माउंट करने के लिए एक ऑफ़लाइन टूल (जैसे, विंडोज पीई) का उपयोग करें, और 0x04 से 0x1c से DWORD ControlSet001 \ Control \ BootDriverFlags को बदलें। (आपको शायद अच्छे माप के लिए ControlSet002 संस्करण को बदलना चाहिए, और आप प्रत्येक इंस्टॉल के बाद ऐसा करने से बचने के लिए अपने इंस्टॉल में परिवर्तन सेंक सकते हैं।)
( बेशक, इसमें एक सप्ताह और कर्नेल डिबगर को यह पता लगाने में मदद मिलती है कि इसे अस्पष्ट और पूरी तरह से अवांछित बिटफील्ड में दो-बिट परिवर्तन की आवश्यकता है।)
यहाँ पर क्यों।
Windows बूट लोडर Windows स्थापित करने के लिए अंतर्निहित UEFI दिनचर्या का उपयोग करता है, और ExitBootServices को कॉल करने से पहले कर्नेल और बूट ड्राइवरों को RAM में लोड करता है। एक बार जब यह कर लिया है और कर्नेल को नियंत्रित कर दिया है, तो कर्नेल बूट वॉल्यूम तक नहीं पहुंच सकता है जब तक कि उपयुक्त ड्राइवर पहले से ही रैम में मौजूद न हों।
यहां किकर है, हालांकि: winload.efi हार्डवेयर की गणना करने और यह निर्धारित करने के लिए पर्याप्त जटिल नहीं है कि ड्राइवरों को वास्तव में क्या आवश्यक है। पुराने संस्करणों में यह केवल बूट स्टार्ट पर सेट की गई चीजों को लोड करेगा। हालाँकि, बाहरी ड्राइवरों को लोड करने से एक परफॉरमेंस पेनल्टी लगती है, और जैसा कि विंडोज ने बूट डिवाइसेस के अधिक वर्गों का समर्थन करना शुरू किया, एक बेहतर सिस्टम की जरूरत थी।
अलग-अलग ड्राइवरों पर बूटफ्लैग मान और सिस्टम वाइड बूटड्राइवरफ्लैग मान दर्ज करें। यदि (BootFlags & BootDriverFlags)! = 0, तो ड्राइवर को स्टार्ट लोड होने पर भी लोड नहीं होगा। मान में प्रत्येक बिट को एक अलग प्रकार के हार्डवेयर के अनुरूप माना जाता है, इसलिए BootDriverFlags मान सेट करता है कि किस प्रकार के हार्डवेयर से बूट किया जा सकता है।
जब यह तंत्र पेश किया गया था, तो बिट 3 को USB बूट उपकरणों के लिए नामित किया गया था, लेकिन USB उपकरणों से बूट करना मानक विंडोज में असमर्थित था। हाइपर- V सर्वर 2008 R2 संस्करण ने इस मान को 0x04 पर सेट करके USB से बूटिंग के लिए विशिष्ट समर्थन जोड़ा, और यह मान तब से जारी हाइपर- V सर्वर के हर संस्करण में सेट किया गया है।
तब से विंडोज टू गो फीचर को सपोर्ट करने के लिए किए गए सामान्य सुधारों का मतलब है कि आपको USB डिवाइसेस पर स्थापित हाइपर-वी सर्वर के पिछले संस्करणों के लिए अनुशंसित बूट-टू-वीएचडी ट्रिक का उपयोग नहीं करना है। हालाँकि, वे BootDriverFlags मान का अर्थ भी बदलते हैं। USB 3 उपकरणों को एक अलग सा दिया गया है, और SD कार्ड विशेष रूप से एक और बिट दिया गया है।
2016 के संस्करण में, इसका मतलब है कि 0x04 का मान अब केवल USB2 डिस्क से बूट करने में सक्षम बनाता है जो एसडी कार्ड नहीं हैं। हाइपर- V सर्वर जहाज को छोड़कर सर्वर 2016 के सभी संस्करण 0x1c के डिफ़ॉल्ट मान के साथ, जो USB2, USB3; और SD बूट बूट को सक्षम करता है; हालाँकि, 0x04 का मान अभी भी हाइपर- V सर्वर में सेट है, क्योंकि यह 2008R2 संस्करण के लिए छवि निर्माण प्रक्रिया में एक ओवरराइड के रूप में जोड़ा गया था। एक सुविधा जोड़ने के बजाय, हालांकि, यह मान अब इसे हटा देता है।
यह बताता है कि क्यों इस समस्या के कुछ पिछले समाधानों ने USB3 को अक्षम करने और SD कार्ड के बजाय USB स्टिक से बूट करने की सिफारिश की: यह बूट डिवाइस की श्रेणी को "USB" की अब-अधिक-सीमित परिभाषा के द्वारा अभी भी कुछ कवर करने के लिए मजबूर करेगा। "बिट इन बूटड्राइवरफ्लैग्स।