विंडोज में एक सुरक्षात्मक एमबीआर कैसे लिखें?


3

मेरे पास एक डिस्क पर CentOS के साथ एक UEFI मशीन है और दूसरे पर विंडोज 2016 है। विंडोज इंस्टॉलर GPT सुरक्षात्मक MBR लिखता है, लेकिन यह UEFI मानक का बिल्कुल पालन नहीं करता है, जैसा कि यहां वर्णित है । यह मानक के अनुसार एकल विभाजन के साथ एमबीआर लिखता है, लेकिन फिर यह डिस्क के वास्तविक आकार के बजाय अंतिम सेक्टर 2 ^ 32-1 बनाता है।

यह एक समस्या नहीं है जब तक कि मैं विभाजन तालिका को बचाने और बाद में इसे पुनर्स्थापित करने के लिए sgdisk का उपयोग करने का प्रयास करता हूं । आकार के लिए खराब आंकड़ा चीजों को भ्रमित करता है और यह एक भ्रष्ट एमबीआर के साथ समाप्त होता है। CentOS में, मैं एक नए सुरक्षात्मक MBR लिखने के लिए gdisk का उपयोग करके इसे रोक सकता हूं । हालांकि, यह सुविधाजनक होगा अगर मैं विंडोज से ऐसा कर सकता हूं। क्या उधर रास्ता है?


1
क्या आपकी डिस्क 2.2 टीबी से बड़ी है?
harrymc

नहीं, यह छोटा है। मुझे संदेह है कि समस्या का कारण क्या है, हालांकि मैं इसे साबित नहीं कर सकता।
पीटर वेस्टलेक

यह समस्या पैदा नहीं कर सकता। क्या डिस्क है?
harrymc

एक तोशिबा DT01ACA050, आकार 1953525168 सेक्टर, 931.5 GB। यदि मैं एक नया सुरक्षात्मक MBR लिखने के लिए gedit का उपयोग करता हूं, तो यह अंतिम क्षेत्र के लिए 1953525167 का उपयोग करता है, और फिर sgdisk सेव और काम को पुनर्स्थापित करता है।
पीटर वेस्टलेक

यह आपके विचार से भी बदतर है: DT01ACA050 इसका नाम है क्योंकि इसमें 500 जीबी है। यदि इसमें 1 टीबी होता, तो इसे DT01ACA100 ( लिंक ) कहा जाता । उस डिस्क के साथ कुछ बहुत गड़बड़ है - यह अपनी क्षमता के बारे में भ्रामक ऑपरेटिंग सिस्टम में सफल होता है। क्या यह अभी भी वारंटी के तहत है?
harrymc

जवाबों:


2

जैसा कि पोस्टर की डिस्क सिर्फ 1 टीबी है, नीचे मेरा जवाब लागू नहीं होता है।

जीपीटी प्रोटेक्टिव एमबीआर और पार्टीशन टेबल के लेख में मुझे एक बहुत ही आश्चर्यजनक तथ्य पता चला :

विंडोज 7 हमेशा इस क्षेत्र को 0xFFFFFFFF से भरता है, भले ही यूईएफआई विनिर्देश बताता है कि इसे "डिस्क माइनस वन के आकार में" 2.2 टीबी के तहत ड्राइव के लिए सेट किया जाना चाहिए।

और यह वही है जो एक फुटनोट में नोट किया गया है:

संदर्भ और पूर्ण उद्धरण: एकीकृत एक्स्टेंसिबल फ़र्मवेयर इंटरफ़ेस विनिर्देश, संस्करण 2.3.1, इरेटा सी, 27 जून, 2012 , जो अध्याय 5, GUID विभाजन तालिका (GPT) डिस्क लेआउट, खंड 5.2.3, सुरक्षात्मक MBR, तालिका 15 में वर्णित है, 'SizeInLBA', पृष्ठ 100 पर: "डिस्क माइनस एक के आकार पर सेट करें। 0xFFFFFFFF पर सेट करें यदि डिस्क का आकार इस क्षेत्र में प्रतिनिधित्व करने के लिए बहुत बड़ा है।" चूंकि Microsoft 2.2 टीबी से छोटे ड्राइव के लिए समान प्रविष्टि का उपयोग करता है जैसा कि 2.2 टीबी से अधिक के लोगों के लिए होता है, वे SizeInLBA के लिए यूईएफआई विनिर्देश का पालन नहीं कर रहे हैं

इसलिए यह मानक को अनदेखा करने का निर्णय लेने का Microsoft का मामला है, और ऐसा कुछ भी नहीं है जो आप इसके बारे में कर सकते हैं। एक समाधान संभवतः लिनक्स के तहत विभाजन आवंटन करने के लिए हो सकता है।

यदि आप विंडोज के तहत एक गैर-Microsoft उपयोगिता की तलाश कर रहे हैं, तो लेख को सर्वश्रेष्ठ मुफ्त विभाजन प्रबंधन सॉफ़्टवेयर देखें , जिसमें मुफ्त तृतीय-पक्ष उपयोगिताओं को सूचीबद्ध किया गया है जो मानक की अनदेखी नहीं कर सकते हैं।


(पुराना उत्तर)

मुझे लगता है कि आपकी डिस्क 2.2 टीबी से बड़ी होनी चाहिए, जो कि एमबीआर के लिए अधिकतम आकार है।

सुरक्षात्मक एमबीआर (या कोई एमबीआर) उस आकार तक सीमित है। यह एक बड़ी संख्या नहीं दे सकता है, क्योंकि एमबीआर में विभाजन के आकार वाले क्षेत्र में केवल 32 बिट्स हैं।

यह सीमा उन कारणों में से एक थी जो बाजार में आने वाले 2.2 टीबी से बड़े डिस्क के लिए जीपीटी आवश्यक हो गए थे।


1
Downvote। क्यूं कर ?
harrymc

हाँ यह कष्टप्रद है यह नहीं है ?! पहली बार मैं "वास्तविक" सुपर उपयोगकर्ताओं में से एक को इसके बारे में शिकायत करता हूं। काश नीचे होने के लिए एक अनिवार्य (अनाम) कारण हो सकता है ... आह शायद मुझे सुझाव देना चाहिए कि मेटा में ?! पुनश्च। मैं नीच नहीं था ...
Albin

@ एलीबिन: मेटा पर इस तरह के उपायों पर चर्चा की गई थी, लेकिन किसी ने कभी भी किसी पर सहमति नहीं जताई।
harrymc

@ एलबिन - मैंने सुझाव दिया कि कुछ साल पहले, लेकिन इसे मना कर दिया गया था। मुझे यकीन है कि मैं ऐसा करने वाला अकेला नहीं हूं।
AFH

@AFH धन्यवाद मैं कुछ शोध करूँगा। क्या आप लोग इस पर चर्चा करने के लिए एक चैट रूम खोलने में दिलचस्पी लेंगे या आपने इस पर ध्यान नहीं दिया?
एल्बिन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.