परिचय
हाल ही में
एक बूट लोडर के बिना लिनक्स ओएस डाउनलोड करने के लेख को पढ़ने के बाद, मुझे दो चीजों का एहसास हुआ: कई "नवीनता" में रुचि रखते हैं जो 2011 तक वापस डेटिंग करते हैं; लेखक ने सबसे बुनियादी का वर्णन नहीं किया, जिसके बिना, वास्तव में, कुछ मामलों में कुछ भी काम नहीं करेगा। एक अन्य लेख
भी था, लेकिन या तो यह पहले से ही पुराना था, या फिर एक ही समय में बहुत सारे अनावश्यक और अप्रसन्न था।
विशेष रूप से, मुख्य बिंदु छूट गया था - कर्नेल असेंबली विकल्प
CONFIG_EFI_STUB । चूंकि U (lu / ku / edu / * etc *) के हाल के संस्करणों में यह विकल्प पहले से ही डिफ़ॉल्ट रूप से सक्षम है, इसलिए लेखक को कोई संदेह नहीं था।
जहां तक मुझे पता है, यह वर्तमान में उपरोक्त संस्करणों के वितरण में शामिल है: आर्क लिनक्स, फेडोरा 17, ओपनसुअस 12.2 और उबंटू 12.10। टिप्पणियों में, उन्होंने यह भी उल्लेख किया कि 2.6 कर्नेल के साथ डेबियन यह कर सकता है, लेकिन यह नवीनतम संस्करणों से बैकपोर्ट से ज्यादा कुछ नहीं है। इन वितरणों को फिर से बनाने की आवश्यकता नहीं है! लेकिन अन्य CONFIG_EFI_STUB पर, सबसे अधिक संभावना है, यह या तो पूरी तरह से अनुपस्थित है, क्योंकि विकल्प केवल कर्नेल संस्करण 3.3.0 और उच्चतर से उपलब्ध है, या डिफ़ॉल्ट रूप से बंद है। तदनुसार, नीचे वर्णित सब कुछ CONFIG_EFI_STUB विकल्प के साथ संकलित कर्नेल के लिए सही है।
तो वास्तव में लिनक्स कर्नेल EFI बूट स्टब क्या है?
सामान्य जानकारी
और इससे ज्यादा कुछ नहीं ... "exe-file"!
हां, "पेंच"
पीई / COFF । यूईएफआई बूटलोडर को खुश करने के लिए मामूली संशोधनों के साथ अच्छी तरह से या केवल, इसके तहत केवल ज़कोस। आप कर्नेल के पहले 2 बाइट्स को पढ़कर इसे सत्यापित कर सकते हैं:
$ od /boot/vmlinuz-linux --address-radix=x --read-bytes=2 -t x1c 0000000 4d 5a MZ 0000002
यह परिचित है, है ना? कम से कम उन लोगों के लिए जो कम से कम एक बार "मज़े के लिए" नोटपैड में एमएस-डॉस या विंडोज निष्पादन योग्य फ़ाइल खोलते हैं, एक हेक्स संपादक या कुछ शांत। ये
मार्क ज़बिकोव्स्की के शुरुआती नाम हैं, जिन्होंने वास्तव में इस फ़ाइल प्रारूप को एमएस-डॉस में विकसित किया था। इस स्टब का हस्ताक्षर अभी भी आधुनिक विंडोज निष्पादन योग्य फाइलों में उल्टी में लटका हुआ है, इसके हेडर के साथ प्रति फ़ाइल 64 बाइट्स के रूप में भक्षण होता है!
डॉस हेडर विरासत कोड पर गिरता है, जिसे कर्नेल बूट क्षेत्र के रूप में बूट करता है, और पीई फ़ाइलों को चलाते समय एमएस-डॉस के तरीके से शपथ लेता है: “प्रत्यक्ष फ्लॉपी बूट समर्थित नहीं है। इसके बजाय बूट लोडर प्रोग्राम का उपयोग करें। डिस्क निकालें और रिबूट करने के लिए किसी भी कुंजी को दबाएं ... "। इसलिए, इस हेडर की जानकारी यहाँ कचरा है, सिवाय इसके, वास्तव में, हस्ताक्षर 'एमजेड' और अगले हेडर का ऑफसेट पता।
चलिए आगे बढ़ते हैं।
PE / COFF विनिर्देश हमें बताता है कि ऑफ़सेट 0x3c पर हस्ताक्षर "PE \ 0 \ 0" के साथ दूसरे हेडर की 32-बिट ऑफ़सेट है:
$ od /boot/vmlinuz-linux --address-radix=x --read-bytes=4 --skip-bytes=0x3c -t x4 00003c 000000b8 000040
इसलिए, ऑफसेट 0xb8 है, जो x86_64 आर्किटेक्चर के वर्तमान स्थिर कर्नेल के लिए सही है, x86 पर यह 0xa8 होगा। हम पढ़ते हैं:
$ od /boot/vmlinuz-linux --address-radix=x --read-bytes=4 --skip-bytes=0xb8 -t x1c 0000b8 50 45 00 00 PE \0 \0 0000bc
और यहाँ पर दूसरे हैडर के हस्ताक्षर है! जैसा कि आप अनुमान लगा सकते हैं, यह पोर्टेबल निष्पादन योग्य वाक्यांश के लिए एक संक्षिप्त नाम है, जिसके साथ निष्पादन योग्य फ़ाइलों में पेलोड शुरू होता है।
यहां तक कि विंडोज बूट लोडर ने इस हेडर के आधे क्षेत्रों की परवाह नहीं की, और यहां तक कि यूईएफआई को उनकी बिल्कुल भी आवश्यकता नहीं थी, इसलिए उनमें से कुछ को सांख्यिकीय रूप से पंजीकृत किया गया था, जबकि महत्वपूर्ण लोगों को कर्नेल असेंबली के दौरान भरा जाता है। बहुत सारे "अनावश्यक" क्षेत्र, सभी प्रकार के टाइमस्टैम्प, नियंत्रण राशि, आदि बस शून्य हैं। मूल रूप से, आयाम, ऑफसेट, प्रवेश बिंदु, आदि भरे हुए हैं। इसलिए, आप इस पीई-फ़ाइल के नाम को पूरी तरह से मान्य कर सकते हैं। हालाँकि, क्लासिक लॉर्डपे या पेटोल उपयोगिताओं में हस्ताक्षर के साथ काफी सामग्री है और वे सब कुछ बताती हैं जो वे फाइल के बारे में जानते हैं:
विंडोज में "वास्तविक" निष्पादन योग्य फ़ाइलों से मुख्य अंतर वैकल्पिक हैडर का सबसिस्टम ध्वज है, जो IMAGE_SUBSYSTEM_EFI_APPLICATION में सेट किया गया है, और प्रतीकात्मक या IMAGE_SUBSYSTEM_WINDOWS_CUI ग्राफ के लिए IMAGE_SUBSYSTEM_INDOWS_GUI में नहीं है।
संरचना
सामान्य तौर पर, सब कुछ एक नियमित पीई फ़ाइल के रूप में होता है। वर्तमान में, आर्क लिनक्स कर्नेल का स्थिर संस्करण 3.11.4 रिपॉजिटरी से है, इसमें 3 खंड हैं: '.set', '.reloc' और '.text'।
- संगतता मोड में लोड होने की स्थिति में प्रारंभ के लिए .setup अनुभाग में मुख्य रूप से विरासत कोड होता है। यूईएफआई मोड में लोड करते समय, प्रोसेसर के सभी स्विचिंग मोड, फर्मवेयर द्वारा प्रारंभिक प्रारंभिककरण किया जाता है।
- लोडर द्वारा .reloc सेक्शन जरूरी है, इसलिए कर्नेल बनाते समय, एक खाली "वह" स्टब बनाया जाता है।
- सबसे दिलचस्प .code खंड, वास्तव में, EntryPoint और कर्नेल के बाकी हिस्सों का मुख्य कोड है। EFI- एप्लिकेशन मिलने के बाद, लोडर LoadImage बूट सेवा निष्पादित करता है, जिससे संपूर्ण छवि को मेमोरी में लोड किया जाता है। रेजिडेंसी का प्रकार सबसिस्टम फ़ील्ड पर निर्भर करता है: EFI_APPLICATION काम करने पर अनलोड हो जाएगा। EFI_DRIVER अनलोड किया जा सकता है और केवल एक महत्वपूर्ण त्रुटि के मामले में अनलोड किया जाएगा। अगला, नियंत्रण प्रविष्टि बिंदु पर स्थानांतरित किया जाता है, आमतौर पर यह सी में एफ़ि_मन () फ़ंक्शन - मुख्य का एक एनालॉग () होता है।
वास्तव में, मैं थोड़ा चालाक था, शुरुआत में कर्नेल को एक एक्स फ़ाइल कहता था। वास्तव में, यह एक सरल EFI अनुप्रयोग है जो PE32 + प्रारूप का उपयोग करता है।
बुनियादी आवश्यकताओं
सबसे पहले, आपको ईएफआई-मोड बूट मोड को सक्रिय करने की आवश्यकता है। एक आइटम को एक विक्रेता के रूप में कहा जा सकता है, आमतौर पर बूट विकल्प टैब में स्थित होता है। यदि आपने वहाँ कुछ देखा जैसे कि लेगेसी मोड या CSM (कम्पेटिबिलिटी सपोर्ट मोड), या केवल BOIS मोड, तो इसे कुछ इसी तरह बदलें: (U) EFI मोड, एन्हांस्ड मोड या एडवांस्ड मोड।
अगर मदरबोर्ड में "विंडोज 8 रेडी" लोगो है, तो सबसे अधिक संभावना है कि ईएफआई बूट मोड पहले से ही डिफ़ॉल्ट रूप से सक्रिय है।
ज्यादातर मामलों में, लिनक्स कर्नेल को EFI- मोड में बूट करने के लिए, आपको सुरक्षित बूट विकल्प को निष्क्रिय करना होगा।
डिस्क लेआउट
कई स्रोतों से संकेत मिलता है कि
जीपीटी विभाजन की आवश्यकता है,
एमबीआर नहीं, लेकिन यह मामला नहीं है। UEFI MBR के लिए काफी सक्षम है। एक और बात, उदाहरण के लिए, विंडोज जबरन एक डिस्क को ईएफआई मोड में बूट करने के लिए एक नए तरीके से तोड़ने के लिए मजबूर करता है और मास्टर बूट रिकॉर्ड की प्राचीनता की कसम खाता है। और ठीक ही तो है! डिस्क को अप-टू-डेट करने के बाद, हम कुछ भी नहीं खोएंगे, लेकिन केवल जीत।
सबसे पहले, सभी प्रकार के प्राथमिक / तार्किक विभाजन के साथ कोई समस्या नहीं होगी, "वहाँ मत जाओ - यहाँ जाओ" और अन्य अशिष्टताएं।
दूसरे, हालांकि सॉलिडस्टेट डिस्क्स बड़ी मात्रा में आगे बढ़ रहे हैं, जिनके वॉल्यूम बहुत आश्चर्यजनक नहीं हैं, कुछ टेराबाइट्स के एक साधारण "टर्नटेबल" का आकार अब किसी को आश्चर्यचकित नहीं करेगा। लेकिन एमबीआर के तहत आप अधिकतम 2TB के साथ एक विभाजन को चिह्नित कर सकते हैं। दूसरी ओर, GPT,
बहुत कुछ देखता
है , आप एक नंबर भी नहीं लिख सकते हैं - ऐसे आकारों के डिस्क जल्द ही प्रदर्शित नहीं होंगे।
खैर, प्लस सभी प्रकार के बोनस, जैसे कि डिस्क की शुरुआत और अंत में GPT रिकॉर्ड को डुप्लिकेट करना, अखंडता चेकसमेट्स, आदि, GPT के लिए एक डिस्क नामित करने के लिए बिना किसी हिचकिचाहट के इच्छा जोड़ें।
जीएनयू / लिनक्स में विभिन्न उपयोगिताओं का उपयोग करके डिस्क को कैसे विभाजित किया जाए, इस पर बहुत सारे लेख हैं।
अलग खंड
अनुभाग प्रकार
मानकों के विकास के nn-tat वर्षों के बाद, इंजीनियरों ने अभी भी तय किया कि हार्डकोड अच्छा नहीं है। अब यह महत्वपूर्ण नहीं है कि हमारा बूट विभाजन कहाँ स्थित है, UEFI बूटलोडर इसे बहुत सरलता से करता है: यह सभी विभाजनों से गुजरता है और एक पंक्ति में डिस्क और एक विशेष के लिए दिखता है। इसकी ख़ासियत इस तथ्य में निहित है कि एमबीआर मार्कअप के मामले में, इसका कोड 0xEF के साथ एक प्रकार है (जैसा कि आप अनुमान लगा सकते हैं, ईएफआई से)। GPT मार्कअप के मामले में,
GUID वाला एक खंड
C12A7328-F81F-11D2-BA4B-00A0C93EC93B के बराबर है ।
यहाँ कुछ साक्षी है। उदाहरण के लिए, सभी मार्कअप उपयोगिताओं में, "बूट" ध्वज को सेट और प्रदर्शित करने की क्षमता है, जो विभाजन पर लागू होती है। तो, एमबीआर के मामले में, ऐसी संभावना वास्तव में मौजूद है, अर्थात, एक वास्तविक बाइट है जो BIOS को इंगित करता है कि विभाजन "बूट करने योग्य" है। यह ध्वज किसी भी विभाजन पर लगाया जा सकता है जिसका एमबीआर, हम डाउनलोड के लिए BIOS को खिलाना चाहते हैं। लेकिन जब हम GPT के साथ काम कर रहे हैं, तो वास्तव में कोई झंडा नहीं है! इस ध्वज के द्वारा, जुदा का मतलब उपरोक्त के बराबर केवल GUID है। वह वास्तव में GPT बूट फ्लैग = GPT EFI विभाजन है!
gdisk इससे ग्रस्त नहीं है:
निष्कर्ष: यदि हमारा EFI विभाजन MBR पर है, तो विभाजन प्रकार को EFI विभाजन
और बूट ध्वज पर सेट करें। यदि GPT एक EFI विभाजन प्रकार
या बूट ध्वज है, क्योंकि वे एक ही चीज हैं।
सभी प्रकार की चीजें हैं, जैसे कि GPT विरासत बूट ध्वज, जो कि प्रोटेक्टिव एमबीआर में स्थापित है, और इसी तरह, लेकिन ये सभी बैसाखी हैं जो केवल संगतता मोड में उपयोग किए जाते हैं। GPT मोड में, UEFI बूट को अनदेखा किया जाना चाहिए।
फाइल सिस्टम
अलग-अलग स्रोत अलग-अलग लिखते हैं। कोई कहता है कि FAT16 का उपयोग किया जा सकता है, कोई भी FAT12 की सिफारिश करता है। लेकिन क्या आधिकारिक विनिर्देश की सलाह का पालन करना बेहतर नहीं है? और वह कहती है कि सिस्टम विभाजन FAT32 में होना चाहिए। हटाने योग्य-मीडिया (USB HDD, USB फ्लैश) के लिए - FAT32 के अलावा FAT12 / FAT16 भी।
विभाजन के आकार के बारे में कुछ नहीं कहा गया है। हालांकि, बूट लोडर और फर्मवेयर के प्रारंभिक बैसाखी और छोटी गाड़ी के कार्यान्वयन के कारण, प्रयोगात्मक रूप से, लोगों ने पाया कि विभिन्न "आश्चर्य" से बचने के लिए
, कम से कम 520MiB (546MB) के आकार की
सिफारिश की जाती है । यहां, भाग्य के साथ, 32-एमबी विभाजन के साथ समस्या नहीं हो सकती है।
निर्देशिका संरचना
लोडर ने अपने "लेबल" विभाजन को ढूंढने के बाद और यह सुनिश्चित किया कि यह फ़ाइल सिस्टम का समर्थन करता है, यह विभाजन के रूट के सापेक्ष पथ के साथ सभी क्रियाओं को करना शुरू करता है। इसके अलावा, इस खंड की सभी फाइलें
\ EFI \ निर्देशिका में होनी चाहिए, जो बदले में, अनुभाग की जड़ में एकमात्र है। अधिवेशन द्वारा, प्रत्येक विक्रेता को एक अद्वितीय नाम के साथ एक फ़ोल्डर का चयन करने और उसे
\ _ "EFI \" में रखने की सलाह दी जाती है , उदाहरण के लिए:
\ EFI \ redhat \ ,
\ EFI \ microsoft \ ,
\ EFI \ archlinux \ । विक्रेता की निर्देशिका में सीधे निष्पादन योग्य एफ़आईआई अनुप्रयोग होते हैं। प्रति आर्किटेक्चर की एक फ़ाइल की सिफारिश की जाती है। फाइलों में एक्सटेंशन
.efi होना चाहिए।
हटाने योग्य उपकरणों के लिए,
\ EFI \ BOOT \ निर्देशिका का उद्देश्य है। यह भी प्रत्येक वास्तुकला के लिए एक से अधिक फ़ाइल की सिफारिश नहीं करता है। इसके अतिरिक्त, फ़ाइल को
बूट {आर्क} .efi कहा जाना चाहिए। उदाहरण के लिए,
\ EFI \ BOOT \ bootx64.efi । उपलब्ध आर्किटेक्चर:
ia32, x64, ia64, arm, aa64 ।
एनवीआरएएम एक्सेस
डिफ़ॉल्ट रूप से, यदि गैर-वाष्पशील UEFI मेमोरी में कुछ भी नहीं लिखा है, तो
\ EFI \ BOOT \ bootx64.efi लोड हो जाएगा।
NVRAM में आवश्यक एप्लिकेशन के लिए पथ लिखने के लिए, आप efibootmgr उपयोगिता का उपयोग कर सकते हैं। आइए वर्तमान प्रविष्टियों को प्रदर्शित करने का प्रयास करें:
कुछ वितरणों में काम करने के लिए इस उपयोगिता के लिए शामिल कर्नेल विकल्प CONFIG_EFI_VARS की आवश्यकता होती है।
नीचे उतर रहा है
इसलिए, हमने
550 MiB FAT32 EFI सिस्टम विभाजन (ESP) को चिह्नित किया है। या, हमारे पास दूसरी प्रणाली के साथ विंडोज है और पहले से ही इसे स्वयं बनाया है। सच है, वह आमतौर पर लगभग 100 एमबी के आकार के साथ इसे बनाता है, लेकिन व्यक्तिगत रूप से, मुझे कभी भी समस्या नहीं हुई।
EFI बूट STUB के लिए समर्थन के साथ पहले से ही एक कर्नेल / बूट है।
सत्यापित करेंयह जाँचने के लिए कि कर्नेल बनाते समय विकल्प सक्षम था, निष्पादित करें:
$ zgrep CONFIG_EFI_STUB /proc/config.gz
या
$ zgrep CONFIG_EFI_STUB /boot/config-`uname -r`
CONFIG_EFI_STUB = y का अर्थ है कि विकल्प सक्रिय है।
अगला, हमारे पास परिदृश्यों का एक समूह है:
- आप सामग्री को पहले कॉपी करके माउंट -bind के माध्यम से ESP \ {वेंडर} \ / को माउंट कर सकते हैं।
अपवादयह आइटम केवल उन वितरणों के लिए उपयुक्त है जिनमें / बूट निर्देशिका में प्रतीकात्मक लिंक शामिल नहीं हैं। उदाहरण के लिए, आप खुले तौर पर माउंट करने में सक्षम नहीं होंगे, क्योंकि इसमें कर्नेल सहित कई लिंक हैं।
- वैकल्पिक रूप से, कर्नेल को अद्यतन करते समय, इसे कॉपी करें और प्रत्येक बार ESP \ {विक्रेता} \ के लिए राम-डिस्क
- आप सीधे / बूट फ़ाइल सिस्टम को पढ़ने के लिए EFI ड्राइवर को रख सकते हैं, बस कर्नेल (या बेहतर हार्डलिंक) में एक्सटेंशन '.efi' जोड़ सकते हैं।
अब आपको किसी तरह बूट प्वाइंट को एनवीआरएएम यूईएफआई से जोड़ने की जरूरत है। यहाँ फिर से, कई विकल्प हैं:
यदि हम बूट लोडर GRUB2, rEFInd इत्यादि का उपयोग करके पहले से ही EFI मोड में लोड होते हैं (efibootmgr -v शपथ नहीं लेता है), तो सब कुछ ठीक है:
- हम efibootmgr का उपयोग करते हैं, जो कर्नेल मापदंडों को प्रसारित कर सकता है।
- यदि efibootmgr किक करता है, तो आप यूईएफआई शेल का उपयोग कर सकते हैं, जो हमारे कोर की तरह एक ईएफआई अनुप्रयोग है। उसके bcfg कमांड के माध्यम से, बूट पॉइंट्स को संपादित करना संभव है।
- ऐसा कोई विकल्प हो सकता है: efibootmgr पैरामीटर जोड़ने की कसम खाता है, जिसका अर्थ है कि फर्मवेयर उन्हें लिखने का समर्थन नहीं करता है (या सिर्फ एक वक्र, जो अधिक संभावना है)। पिछले लेख में, टिप्पणियों में efi_no_storage_paranoia कर्नेल पैरामीटर का उल्लेख किया गया था, जो मदद कर सकता है। लेकिन आप इसका उपयोग केवल तभी कर सकते हैं जब आप सुनिश्चित हों कि आपके फर्मवेयर को विनिर्देश के अनुसार पूरी तरह से लागू किया गया है! डेवलपर्स ने चेतावनी दी है कि यदि विक्रेता ने कार्यान्वयन के दौरान बैसाखी और अंतराल जोड़े, तो मदरबोर्ड के स्थान पर एक ईंट को मटेरिअल करने की संभावना नहीं है।
- आप यूईएफआई शेल के माध्यम से भी बूट कर सकते हैं। एक स्टार्टअप .nsh स्क्रिप्ट इसके लिए बनाई गई है, जो कर्नेल बूट कमांड को वांछित कमांड लाइन के साथ इंगित करती है। और शेल, बदले में, एक डाउनलोड बिंदु के रूप में जोड़ा जाता है।
- एक और समस्या है: एक आइटम को जोड़ना केवल एक कर्नेल पथ के लिए संभव है, जबकि राम-डिस्क दिखाई नहीं देता है। अधिकांश लेख में निर्मित इनबिल्ट के साथ कर्नेल के पुनर्निर्माण की सलाह देते हैं। अगर यह एक कर्नेल समस्या है, या बूटलोडर है, तो मुझे यकीन नहीं है। लेकिन फिलहाल, 90% मामलों में, सब कुछ समर्थित है और कर्नेल के पुनर्निर्माण की कोई आवश्यकता नहीं है।
त्रुटि का संभावित कारणबड़े पैमाने पर गलत तरीके से इसे निर्दिष्ट करने के कारण कर्नेल में एक राम डिस्क को एम्बेड करने की सिफारिशें चली गईं। EFI बूट स्टब के शुरुआती कार्यान्वयन में, कर्नेल ने रैम-डिस्क के गलत रास्ते के बारे में कोई त्रुटि नहीं छोड़ी, लेकिन चुपचाप बूट करने से इनकार कर दिया। जाहिरा तौर पर, इसलिए, सभी ने इसे कर्नेल में बड़े पैमाने पर पेश करना शुरू किया, यह तय किया कि यह समर्थित नहीं है। हालाँकि initrd पैरामीटर के लिए समर्थन मौजूद है क्योंकि बूट स्टब फ़ीचर कर्नेल में दिखाई देता है।
महत्वपूर्ण: राम-डिस्क का रास्ता बैकस्लैश "\" के माध्यम से निरपेक्ष रूप से स्थानांतरित किया जाता है, लेकिन प्रत्यक्ष नहीं! उदाहरण के लिए, initrd = \ EFI \ archlinux \ initramfs-linux.img।
अराजकतावादियों के लिए अपवादवास्तव में, गुठली, 3.8.0-rc5 से अधिक के संस्करणों में आगे और पीछे के बीच का अंतर नहीं दिखता है - कोई भी काम करेगा। लेकिन संस्करण 3.2.0-rc5 में बूट स्टब फ़ीचर की उपस्थिति के बाद से, कर्नेल ने आगे की स्लैश के माध्यम से रिकॉर्ड किए गए पथ को नहीं देखा और चुपचाप त्रुटियों के बिना बूट करने से इनकार कर दिया। इसके बारे में त्रुटियों की शपथ लेते हुए, यह 3.4.0 संस्करण में सीखा।
यदि हमें EFI बूट मोड के बारे में अभी पता चला है और बूट बिंदुओं को जोड़ने के लिए इसे स्विच करना चाहते हैं, तो आपको
पहले से ही इस मोड में होना चाहिए, और फिर हम अभी भी संगतता मोड में हैं ... दो मुख्य समाधान हैं:
- EFI बूट समर्थन के साथ पहला लाइव-सीडी डाउनलोड करें। और इससे पहले से ही efibootmgr कमांड का उपयोग करें।
- UEFI शैल डाउनलोड करें। इससे, आप कर्नेल और रैम डिस्क को निर्दिष्ट करके और बूट बिंदुओं को संपादित करके EFI मोड में दोनों बूट कर सकते हैं।
बूटलोडर के बिना ड्यूलबूट
यदि आपके पास एक ही समय में 2 सिस्टम स्थापित हैं, और फिर भी एक तृतीय-पक्ष बूटलोडर स्थापित नहीं करना चाहते हैं, तो आप दोनों यूईएफआई बूट बिंदुओं को जोड़ सकते हैं और अपने पसंदीदा बूट क्रम को समायोजित कर सकते हैं। Windows बूट लोडर आमतौर पर
\ EFI \ Microsoft \ BOOT \ bootmgfw.efi में स्थित होता है ।
कुल मिलाकर
यदि सब कुछ सही ढंग से किया जाता है, तो हम बूट मेनू को रिबूट करते हैं, हमारे द्वारा जोड़े गए आइटम का चयन करें और लगभग तुरंत बूट देखें। एसएसडी के मामले में, फास्टबूट, रीडहेड और आर्क लिनक्स - लगभग 3-4 सेकंड। अब एक साल के लिए, होम सर्वर ईएफआई बूट स्टब का उपयोग करके किसी भी तीसरे पक्ष के बूटलोडर्स के बिना लोड हो रहा है।
बेशक, यहां गति में लाभ कम से कम है, लेकिन, जैसा कि
रॉड्रिक स्मिथ जैसे जानकार लिखते हैं, कभी-कभी ईएफआई बूट मोड में संगतता मोड की तुलना में उपकरण का "अधिक पर्याप्त" इनिशियलाइज़ेशन होता है।
निष्कर्ष
यूईएफआई फर्मवेयर के सापेक्ष नमी और पूरी तरह से अलग कार्यान्वयन के कारण, मैंने कोड उदाहरण नहीं दिए। प्रत्येक मामले में, एक समस्या हो सकती है। मुझे आशा है कि मैंने जो वर्णन किया है वह सामान्य सिद्धांत को समझने और मेरे मामले पर लागू होने में मदद करेगा।
मैं मदरबोर्ड निर्माता की वेबसाइट से यूईएफआई के नवीनतम संस्करण को चमकाने की भी सलाह देता हूं।
साहित्य
यूईएफआई आधिकारिक विनिर्देशरोडरिक डब्ल्यू। स्मिथ का वेब पेज ईएफआई, बूटलोडर्स और डिस्क विभाजन से संबंधित कई उपयोगिताओं के लेखक का काम है।
आर्चीविकी: यूईएफआई बूटलोडर्स - अपरिवर्तित और वितरण में से एक का सबसे अच्छा और सबसे पूर्ण जीएनयू / लिनक्स विकी।
आधिकारिक पीई / COFF विशिष्टता