लिनक्स एक अलग / बूट विभाजन से कैसे निपटता है?


11

मुझे यह जानने में दिलचस्पी है कि लिनक्स अलग बूट विभाजन के साथ कैसे व्यवहार करता है। मुझे वास्तव में ऐसा करने में कोई दिलचस्पी नहीं है , लेकिन मैं यह जानना चाहूंगा कि यह कैसे काम करता है।

एक हार्ड ड्राइव पर विचार करें sda, जिसमें दो विभाजन हैं sda1और sda2। मान लीजिए कि sda2वह rootविभाजन है /जिसमें लिनक्स ओएस है।

मेरी समझ यह है कि बूटलोडर GRUB2, पर चढ़ा हुआ है /boot। जब निर्देशिका /bootअलग विभाजन पर होती है sda2, हालांकि, यह कैसे होता है कि यह /वास्तव में माउंट होने से पहले हो सकता है ?

BIOS, मास्टर बूट रिकॉर्ड और GRUB (या फ़ाइलों /boot) के बीच की बातचीत इस मामले में सफलतापूर्वक कैसे होती है? क्या यह है कि इस प्रारंभिक चरण में डेटा /bootवास्तव में /फाइल सिस्टम पर आरोहित नहीं है ?

नोट: यह प्रश्न रूट विभाजन के बढ़ते से संबंधित है, लेकिन एक अलग बूट विभाजन पर चर्चा नहीं करता है।

जवाबों:


18

यहाँ आपकी समझ में समस्या है:

मेरी समझ यह है कि बूटलोडर GRUB2, / boot पर आरूढ़ है।

GRUB बूट पर "माउंटेड" नहीं है। GRUB को स्थापित किया गया है /boot, और मास्टर बूट रिकॉर्ड में कोड से लोड किया गया है। यहाँ MBR / BIOS (GPT / UEFI नहीं) के साथ GNU / Linux वितरण को मानते हुए, आधुनिक बूट प्रक्रिया का एक सरलीकृत अवलोकन है:

  1. BIOS लोड करता है।
  2. BIOS मास्टर बूट रिकॉर्ड में कोड के छोटे टुकड़े को लोड करता है।
  3. GRUB 440 बाइट्स में फिट नहीं होता है, मास्टर बूट रिकॉर्ड का आकार। इसलिए, कोड जो वास्तव में लोड किया गया है, बस विभाजन तालिका को पार्स करता है, विभाजन को पाता है /boot(जो मुझे विश्वास है कि जब आप मास्टर बूट रिकॉर्ड में GRUB स्थापित करते हैं), और फाइल सिस्टम जानकारी को पार्स करता है। यह तब स्टेज 2 GRUB को लोड करता है। (यह वह जगह है जहाँ सरलीकरण में आता है।)
  4. स्टेज 2 GRUB सब कुछ लोड करती है, जिसमें GRUB कॉन्फ़िगरेशन शामिल है, फिर एक मेनू प्रस्तुत करता है (या नहीं, उपयोगकर्ता कॉन्फ़िगरेशन पर निर्भर करता है)।
  5. एक बूट अनुक्रम चुना जाता है। यह एक मध्यांतर तक हो सकता है, उपयोगकर्ता द्वारा मेनू प्रविष्टि का चयन करके, या कमांड सूची को बूट करके।
  6. बूट अनुक्रम निष्पादित करना शुरू कर देता है। यह कई चीजें कर सकता है - उदाहरण के लिए, एक कर्नेल को लोड करना, दूसरे बूटलोडर को चेनलोड करना - लेकिन मान लेते हैं कि बूट अनुक्रम मानक GNU / लिनक्स है।
  7. GRUB लिनक्स कर्नेल को लोड करता है।
  8. GRUB प्रारंभिक रैमडिस्क को लोड करता है ।
  9. प्रारंभिक रैमडिस्क के /तहत mounts /new_root(संभवतः क्रिप्टोग्राफिक रूप से इसे अनलॉक करना), udev शुरू होता है, फिर से शुरू-स्वैप, आदि से शुरू होता है।
  10. प्रारंभिक रैमडिस्क असली के रूप में pivot_rootसेट करने के लिए उपयोगिता का उपयोग करता है ।/new_root/
  11. initशुरू होता है। विभाजन बढ़ते हैं, डेमॉन शुरू होते हैं, और सिस्टम बूट होते हैं।

ध्यान दें कि कर्नेल केवल चरण 7 पर कैसे लोड किया जाता है। इसके कारण, चरण 7 तक बढ़ते की कोई अवधारणा नहीं है । यही कारण है कि /bootचरण 9 में फिर से माउंट किया जाना है, भले ही GRUB ने पहले ही इसका उपयोग किया हो।

यह GRUB पर विकिपीडिया पृष्ठ के GRUB 2 अनुभाग को देखने के लिए भी उपयोग किया जा सकता है ।


आपने मेरे भ्रम को बिल्कुल ठीक कर दिया। यह ठीक वही है जिसकी तलाश मुझे थी। तो शुरू /bootमें रूट विभाजन पर मुहिम शुरू की गई निर्देशिका का जिक्र नहीं है?
jII

@jesterII का कमाल! उस स्थिति में, क्या आप वोट तीर के ठीक नीचे चेकमार्क पर क्लिक करके इस उत्तर को स्वीकार करना चाहेंगे?
स्ट्रगल करें

7
MBR कोड एक फ़ाइल सिस्टम को पार्स नहीं कर सकता है। यह पहले विभाजन से पहले एमबीआर के बाद अप्रयुक्त क्षेत्रों से ग्रब कोर की छवि को लोड करता है, और यह कोड समझता है कि ग्रब कॉन्फिग फाइलों, अतिरिक्त मॉड्यूल और अपने कर्नेल को खोजने के लिए / बूट विभाजन को कैसे ढूंढें और माउंट करें। इसके अलावा pivot_root को एक गंदे हैक माना जाता था और इसे उस जगह से run-initहटा दिया गया है जो इनट्राम्राम्स की सभी फ़ाइलों को हटा देता है, और फिर रूट फाइल सिस्टम में चेरोट्स करता है।
Psusi

आधुनिक बूट प्रक्रिया अब होना चाहिए विरासत बूट प्रक्रिया के रूप में UEFIअधिक से अधिक से अधिक popurlar हो रही ;-) @strugee
Kiwy

1
@strugee, यूज़-लिनेक्स मेलिंग लिस्ट पर चर्चा के बाद ऐसा लगता है कि मेरा स्मरण थोड़ा बंद हो गया था: उन्होंने असली रूटफुट पर pivot_root की अनुमति देना बंद कर दिया था, इसीलिए बूट के दौरान कोई भी इसका उपयोग नहीं करता है। सिस्टमड इसे शटडाउन पर उपयोग करता है, हालांकि मूल initrd पर लौटने के लिए नहीं (जो वास्तविक रूट पर स्विच करते समय खुद को हटा देता है), लेकिन एक ताज़ा लोड किए गए स्विच पर स्विच करने के लिए। Marc.info/?l=util-linux-ng&m=139100788306216&w=2
psusi

6

प्रश्न 1

मेरी समझ यह है कि बूटलोडर GRUB2, / boot पर आरूढ़ है। जब निर्देशिका / बूट अलग विभाजन sda2 पर होता है, हालांकि, यह कैसे होता है कि ऐसा पहले हो सकता है / वास्तव में माउंट किया गया है?

मुझे नहीं लगता कि आप समझ रहे हैं कि यह काफी सही है। से जीएनयू GRUB विकिपीडिया पृष्ठ :

अंश

जब कोई कंप्यूटर चालू होता है, तो कंप्यूटर का BIOS कॉन्फ़िगर किया गया प्राथमिक बूट करने योग्य डिवाइस (आमतौर पर कंप्यूटर की हार्ड डिस्क) पाता है और मास्टर बूट रिकॉर्ड (एमबीआर) से प्रारंभिक बूटस्ट्रैप प्रोग्राम को लोड और निष्पादित करता है । एमबीआर हार्ड डिस्क का पहला सेक्टर है, और इसकी संख्या 0 है (सेक्टरों की गिनती 0 से शुरू होती है)। लंबे समय से, एक सेक्टर का आकार 512 बाइट्स रहा है, लेकिन 2009 के बाद से 4096 बाइट्स वाले सेक्टर साइज के साथ हार्ड डिस्क उपलब्ध हैं, जिन्हें एडवांस्ड फॉर्मेट डिस्क कहा जाता है । अक्टूबर 2013 तक, 512e एमुलेशन का उपयोग करके, इस तरह के हार्ड डिस्क को अभी भी 512-बाइट सेक्टर में एक्सेस किया जाता है ।

में GRUB संस्करण 2 निम्नलिखित जगह लेता है:

अंश

कंप्यूटर को बूट करना

जब बिजली चालू होती है, तो निम्न होता है:

  • हार्डवेयर इनिशियलाइज़ करता है, सीपीयू को रियल मोड (कोई वर्चुअल मेमोरी) में सेट करता है और निश्चित स्थान 0xFFFF0 (सीपीयू सर्किट में हार्डवेर) पर कूदता है
  • एक ROM या फ़्लैश-मेमोरी में संग्रहीत BIOS कोड को उस स्थान पर मैप किया जाता है।
  • BIOS कोड BIOS कॉन्फिग डेटा को देखने के लिए देखता है कि बूट डिवाइस कौन सा है। इस BIOS कॉन्फिग डेटा को आमतौर पर पावर को चालू करने के बाद कुछ विशेष की-सीक्वेंस को दबाकर एडिट किया जा सकता है, जिससे BIOS कॉन्फ़िगरेशन प्रोग्राम चल सकता है। अन्य चीजों के अलावा, बूट डिवाइस को आमतौर पर यहां चुना जा सकता है।
  • BIOS कोड बूट डिवाइस के एमबीआर को रैम में लोड करता है। याद रखें कि एक एमबीआर सिर्फ 512 बाइट्स है! लोड किया गया डेटा निश्चित रूप से प्रोग्राम और डेटा है जो गतिशील रूप से बनाया गया और ग्रब-इंस्टॉल प्रोग्राम निष्पादित होने पर वहां लिखा गया था।
  • BIOS कोड लोड एमबीआर (यानी ग्रब कोड पावर-ऑन के बाद पहली बार निष्पादित होता है) के प्रारंभ पते पर कूदता है।
  • ग्रब का एमबीआर कोड एक एकल क्षेत्र को लोड करता है जिसका पता एमबीआर ब्लॉक में हार्ड-वायर्ड है। यह तब उस क्षेत्र में पते (पते, लेन) जोड़े पर लूप करता है जो डिस्क से सभी डेटा को मेमोरी में लोड करता है (यानी फ़ाइल की सामग्री /boot/grub/core.img, या इसकी "एम्बेडेड" कॉपी लोड करता है)। MBR कोड तब लोड किए गए कोड पर कूद जाता है, अर्थात प्रोग्राम को "निष्पादित" करता है core.img
  • जैसा कि "इंस्टॉलिंग ग्रब" अनुभाग में वर्णित है, कच्ची डिस्क ब्लॉक पते को एम्बेड करने की यह चाल core.imgअंतरिक्ष में संग्रहीत करना संभव बनाती है जो कि विभाजन में नहीं है, और इसे कभी भी फाइलसिस्टम के रूप में स्वरूपित नहीं किया गया है ("एम्बेडिंग")। और इस मामले में, यदि core.imgसंशोधित किया गया है, जब तक कि एक ही स्थान पर नया संस्करण "एम्बेडेड" है, एमबीआर कोड को अपडेट करने की आवश्यकता नहीं है।
  • वैकल्पिक रूप से, यह core.imgएक वास्तविक फाइलसिस्टम के अंदर होना संभव है , और ग्रब के core.imgलिए इस फाइलसिस्टम के लिए ड्राइवर के बिना फाइल कंटेंट को पढ़ना संभव है । हालाँकि, इस मामले में, अगर core.imgसंशोधित किया गया है , तो फ़ाइल के पहले ब्लॉक को डिस्क पर एक नया पता दिया जा सकता है; यदि ऐसा होता है, तो एमबीआर को इस नए स्थान पर इंगित करने के लिए अद्यतन किया जाना चाहिए। फिर भी, जैसा core.imgकि आमतौर पर ग्रब-इंस्टॉल चलाने से अपडेट होता है, यह आमतौर पर एक समस्या नहीं है।
  • ध्यान दें कि सैद्धांतिक रूप से, यदि core.imgएमबीआर की तुलना में एक अलग डिवाइस पर है, और नया हार्डवेयर जोड़ा गया है, तो ग्रब-जनित एमबीआर रिकॉर्ड core.imgफ़ाइल को सही ढंग से लोड करने में सक्षम नहीं हो सकता है ; जिस डिवाइस-आईडी पर पहला सेक्टर core.imgमिलना है, उसे एमबीआर में हार्ड-वायर्ड किया गया है, जिसे खोजा नहीं गया है। हालाँकि इसका कोई हल नहीं है; 512-बाइट एमबीआर में ग्रब "खोज" कमांड के बराबर एम्बेड करने का कोई तरीका नहीं है। इस समस्या की संभावना नहीं है; आम तौर core.imgपर एमबीआर के समान डिवाइस पर एम्बेडेड होता है। और एक बार core.imgलोड हो जाने के बाद यह search.mod को आगे की सभी /boot/grubफाइलों को खोजने के लिए उपयोग कर सकता है , और इसलिए हार्डवेयर पुनर्व्यवस्था के लिए प्रतिरक्षा है।
  • निष्पादित core.imgकोड अब उन सभी मॉड्यूल को इनिशियलाइज़ करता है जो इसमें बनाए गए हैं (लिंक किए गए हैं core.img); इनमें से एक मॉड्यूल एक फाइलसिस्टम ड्राइवर होगा जो फाइलसिस्टम को पढ़ने में सक्षम है, जिस पर निर्देशिका /boot/grubरहती है।
  • यह बिल्ट-इन कमांड्स के एक सेट को भी पंजीकृत करता है: सेट, अनसेट, ls, इन्समॉड।
  • यदि "कॉन्फ़िगर फ़ाइल" को लिंक किया गया है core.img, तो इसे प्रसंस्करण के लिए एक बहुत ही सरल बिल्ड-इन स्क्रिप्ट पार्सर में पास किया जाता है। कॉन्फ़िगरेशन फ़ाइल में कमांडिंग स्क्रिप्ट केवल अंतर्निहित या लिंक्ड-इन कमांड को ही लागू कर सकती है। सरल परिदृश्य (जैसे एक स्थानीय ड्राइव से एक विशिष्ट डेस्कटॉप कंप्यूटर को बूट करना) को किसी कॉन्फ़िगर फ़ाइल की आवश्यकता नहीं है; यह सुविधा pxe, रिमोट nfs के माध्यम से बूट करने या /boot/grubLVM डिवाइस पर होने जैसी चीजों के लिए उपयोग की जाती है।
  • Core.imgअब “/boot/grub/normal.mod”डिस्क से फ़ाइल को गतिशील रूप से लोड करता है , और इसके प्रवेश समारोह में कूदता है। ध्यान दें कि इस चरण के लिए उपयुक्त फाइलसिस्टम ड्राइवर की आवश्यकता है (यानी बिल्ट-इन)।

     बूट प्रक्रिया के एस.एस.

नोट: जब आप विशिष्ट GRUB2 मेनू देखते हैं, जहाँ आप बूट करने के लिए कौन सा OS / कर्नेल चुनते हैं, तो आप /boot/grubइस बिंदु पर सिस्टम की निर्देशिका को संदर्भित कर रहे हैं ।

                                         ग्रब तुई के एस.एस.

संदर्भ


किसी को उस विकिपीडिया प्रविष्टि को सही करना चाहिए क्योंकि यह गलत है। स्टेज 1 / 1.5 / 2 केवल विरासत ग्रब पर लागू होते हैं। वे पूरी तरह से ग्रब 2 के पुनर्लेखन के साथ समाप्त हो गए थे और आपको आधिकारिक ग्रब 2 प्रलेखन में उन शर्तों का कोई संदर्भ नहीं मिलेगा।
Psusi

@psusi - स्पष्ट करने के लिए धन्यवाद। मैं थोड़ा उलझन में था जब मैंने उन्हें वहां उल्लेख किया था, क्योंकि मैंने वही सुना था, कि 1 / 1.5 / 2 चले गए थे। मुझे नहीं पता कि विकिपीडिया लेखों को संपादित करने के लिए किसे कहा जाए, मैं इस तरह के पोस्ट को संपादित करने के लिए योग्य महसूस नहीं करूंगा। शायद GRUB2 टीम को चेतावनी देना अगली सबसे अच्छी बात होगी?
slm

@psusi - यहाँ रेफरी है। चरणों में समाप्त किया जा रहा है। GRUB2 के लिए डॉक्स: gnu.org/software/grub/manual/grub.html ... "छवि फ़ाइलें (चित्र देखें) जो GRUB बनाते हैं, उनका पुनर्गठन किया गया है; स्टेज 1, स्टेज 1.5, और स्टेज 2 अब और नहीं हैं।"
slm

6

लिनक्स (कर्नेल) को इस बात की परवाह नहीं है कि आपके पास कितने बूट विभाजन हैं। डिस्क से कर्नेल लोड बूटलोडर (जैसे का काम है grub, grub2, lilo) और इन उपकरणों स्थानों के लिए भी एक कर्नेल स्थित हो सकती की संख्या के बारे में परवाह नहीं है। वे केवल विशिष्ट स्थान की परवाह करते हैं।

एक उदाहरण के रूप में, मेरा बूट विभाजन है /dev/md1, जो एक mdadm RAID दर्पण है जो भौतिक विभाजन द्वारा समर्थित है /dev/sde1और /dev/sdf1। मैं इन्हें व्यक्तिगत रूप से माउंट कर सकता हूं अगर मैं चाहता था और इस तरह तकनीकी रूप से दो बूट विभाजन के रूप में गिना जाता है, हालांकि उन्हें समान डेटा होना चाहिए।

मेरे लिए / बूट के लिए दो विभाजन होना एक उपलब्धता समस्या है, लेकिन वे समान रूप से भिन्न / बूट विभाजन हो सकते हैं। अगला कदम बूटलोडर को कैसे पता चलता है? यहां कैसे:

menuentry 'Linux 3.10.17 (sde) kernel-3.10.17-g' {
        root=hd0,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3
        initrd /boot/initrd-3.10.17-g
}

menuentry 'Linux 3.10.17 (sdf) kernel-3.10.17-g' {
        root=hd1,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3 
        initrd /boot/initrd-3.10.17-g
}

यह एक grub2कॉन्फ़िगरेशन का एक अंश है और आप ध्यान देंगे कि केवल अंतर हैं root=hd0,1और root=hd1,1जो कि एंट्री रेफ़रेंस को बूट पार्टिशन को स्थापित करते हैं।


अब आपको चलने के लिए हालांकि एक बूट ताकि आप समझ सकें कि यहां क्या चल रहा है।

  • BIOS बूट वॉल्यूम से MBR को पढ़ता है और बूट लोडर को जम्प करता है
  • बूटलोडर (जैसे grub2) यह जानने के लिए कॉन्फ़िगर किया गया है कि किस डिवाइस और विभाजन में आपका कर्नेल है। Grub2 इस विभाजन को सीधे एक्सेस करता है और आपकी कर्नेल को मेमोरी में लोड करता है।
  • आपका बूटलोडर तब कर्नेल में कूदता है और कर्नेल आपकी मशीन को बूट करता है।

बूटलोडर को परवाह नहीं है कि आपके पास कितने बूट विभाजन हैं, यह केवल परवाह करता है कि वे कहां हैं और आपको यह जानकारी बतानी होगी।

कर्नेल को इस बात की परवाह नहीं है कि आपके पास कितने बूट विभाजन हैं, क्योंकि इसे कभी भी उन्हें देखने की आवश्यकता नहीं है (उदाहरण के लिए नए कर्नेल को जोड़ने के लिए आपको केवल इसे उपलब्ध करने की आवश्यकता है)।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.