लिनक्स कर्नेल बूट प्रक्रिया विश्लेषण

सभी को नमस्कार!

जबकि लियोनिद हमारे लिनक्स प्रशासक पाठ्यक्रम में अपने पहले खुले पाठ की तैयारी कर रहा है, हम लिनक्स कर्नेल को लोड करने के बारे में बात करना जारी रखते हैं।

चलो चलते हैं!

यह समझना कि बिना असफलताओं के कोई सिस्टम कैसे काम करता है - अपरिहार्य टूटने को ठीक करने की तैयारी

खुले स्रोत के क्षेत्र में सबसे पुराना मजाक यह कथन है कि "कोड दस्तावेज ही।" अनुभव ने दिखाया है कि स्रोत कोड पढ़ना मौसम के पूर्वानुमान को सुनने जैसा है: बुद्धिमान लोग अभी भी बाहर जाएंगे और आकाश को देखेंगे। नीचे परिचित डिबगिंग टूल का उपयोग करके लिनक्स सिस्टम बूट की जांच और जांच के लिए सुझाव दिए गए हैं। एक प्रणाली की बूट प्रक्रिया का विश्लेषण जो अच्छी तरह से काम करता है उपयोगकर्ताओं और डेवलपर्स को अपरिहार्य दुर्घटनाओं को हल करने के लिए तैयार करता है।

एक तरफ, डाउनलोड प्रक्रिया आश्चर्यजनक रूप से सरल है। ऑपरेटिंग सिस्टम का कर्नेल (कर्नेल) एक-कोर (कोर) पर एकल-थ्रेडेड और सिंक्रोनस रूप से चलता है, जो एक दयनीय मानव मन के लिए भी समझ में आ सकता है। लेकिन ओएस का कर्नेल कैसे शुरू होता है? क्या कार्य initrd ( प्रारंभिक आरंभीकरण के लिए एक रैम डिस्क ) और बूटलोडर्स करते हैं? और प्रतीक्षा करें, ईथरनेट पोर्ट पर एलईडी हमेशा पर क्यों है?



इन और कुछ अन्य सवालों के जवाब पाने के लिए आगे पढ़ें; वर्णित डेमो और अभ्यास के लिए कोड GitHub पर भी उपलब्ध है ।

बूट की शुरुआत: स्टेटस ऑफ

जागो-ऑन-लैन

ऑफ की स्थिति का मतलब है कि सिस्टम में पावर नहीं है, है ना? स्पष्ट सरलता धोखा है। उदाहरण के लिए, ईथरनेट एलईडी इस स्थिति में भी है, क्योंकि आपके सिस्टम में वेक-ऑन-लैन (WOL, वेक-अप [सिग्नल ऑन लोकल नेटवर्क) चालू है। लिखकर सुनिश्चित करें:

$# sudo ethtool <interface name> 

इसके बजाय यह कहाँ हो सकता है, उदाहरण के लिए, eth0 (इथूल एक ही नाम के साथ लिनक्स पैकेज में है)। यदि आउटपुट में "वेक-ऑन" जी दिखाता है, तो दूरस्थ होस्ट मैजिकपैकेट भेजकर सिस्टम को बूट कर सकता है। यदि आप स्वयं अपने सिस्टम को दूरस्थ रूप से चालू नहीं करना चाहते हैं और दूसरों को यह अवसर देना चाहते हैं, तो सिस्टम BIOS मेनू में WOL अक्षम करें, या:

 $# sudo ethtool -s <interface name> wol d 

मैजिकपैकेट का जवाब देने वाला प्रोसेसर बेसबोर्ड मैनेजमेंट कंट्रोलर (BMC) या नेटवर्क इंटरफेस का हिस्सा हो सकता है।

इंटेल प्रबंधन इंजन, प्लेटफ़ॉर्म कंट्रोलर हब और मिनिक्स

BMC एकमात्र माइक्रोकंट्रोलर (MCU) नहीं है जो नाममात्र की प्रणाली को "सुन" सकता है। X86_64 सिस्टम में रिमोट सिस्टम प्रबंधन के लिए इंटेल मैनेजमेंट इंजन (IME) सॉफ्टवेयर पैकेज है। उपकरणों की एक विस्तृत श्रृंखला, सर्वर से लेकर लैपटॉप तक, प्रौद्योगिकी है जिसमें केवीएम रिमोट कंट्रोल या इंटेल कैपिबिलिटी लाइसेंसिंग सेवा जैसी विशेषताएं हैं। INT l के अपने उपकरण के अनुसार, IME की अप्रभावी कमजोरियाँ हैं। बुरी खबर यह है कि IME को निष्क्रिय करना मुश्किल है। ट्रामेल हडसन ने me_cleaner प्रोजेक्ट बनाया , जो कुछ सबसे अधिक घने IME घटकों को मिटाता है , जैसे एम्बेडेड वेब सर्वर, लेकिन साथ ही साथ एक मौका है कि प्रोजेक्ट का उपयोग करके सिस्टम को चालू कर देगा जिस पर यह एक ईंट में चल रहा है।

IME फर्मवेयर और सिस्टम मैनेजमेंट मोड (SMM) प्रोग्राम जो बूट पर इसका अनुसरण करता है , मिनिक्स ऑपरेटिंग सिस्टम पर आधारित होते हैं और सिस्टम के मुख्य CPU नहीं, बल्कि एक अलग प्लेटफ़ॉर्म कंट्रोलर हब प्रोसेसर पर चलते हैं। फिर SMM ने मुख्य प्रोसेसर पर यूनिवर्सल एक्स्टेंसिबल फ़र्मवेयर इंटरफ़ेस (UEFI) प्रोग्राम लॉन्च किया, जिसमें एक से अधिक बार लिखा गया है । कोरबूट समूह ने Google में एक शानदार महत्वाकांक्षी नॉन-एक्सटेंसिबल रिड्यूस्ड फ़र्मवेयर (एनईआरएफ) परियोजना शुरू की, जिसका उद्देश्य न केवल यूईएफआई को बदलना है, बल्कि लिनक्स उपयोगकर्ता अंतरिक्ष के शुरुआती घटकों, जैसे कि सिस्टमड। इस बीच, हम परिणामों की प्रतीक्षा कर रहे हैं, लिनक्स उपयोगकर्ता प्यूरिज्म, सिस्टम76 या डेल से लैपटॉप खरीद सकते हैं, जिस पर आईएमई अक्षम है , साथ ही, हम 64-बिट एआरएम प्रोसेसर वाले लैपटॉप की उम्मीद कर सकते हैं।

लोडर

संदिग्ध स्पाइवेयर को लॉन्च करने के अलावा बूट करने योग्य फर्मवेयर क्या करता है? बूटलोडर का कार्य प्रोसेसर प्रदान करना है जो लिनक्स जैसे सामान्य-उद्देश्य ऑपरेटिंग सिस्टम को चलाने के लिए आवश्यक संसाधनों के साथ चालू होता है। पावर-अप के दौरान, न केवल वर्चुअल मेमोरी होती है, बल्कि DRAM भी होती है, जब तक कि इसके कंट्रोलर को ऊपर नहीं उठाया जाता है। बूटलोडर तब बिजली की आपूर्ति को चालू करता है और कर्नेल छवि और रूट फाइल सिस्टम को खोजने के लिए बसों और इंटरफेस को स्कैन करता है। U-बूट और GRUB जैसे लोकप्रिय बूटलोडर्स USB, PCI, और NFS दोनों के साथ-साथ अन्य विशिष्ट विशेष उपकरणों, जैसे NOR- और NAND- फ्लैश, दोनों सामान्य इंटरफेस का समर्थन करते हैं। लोडर सुरक्षा हार्डवेयर उपकरणों के साथ भी बातचीत करते हैं, जैसे कि ट्रस्टेड प्लेटफ़ॉर्म मॉड्यूल (टीपीएम) , डाउनलोड की शुरुआत से एक विश्वास श्रृंखला स्थापित करने के लिए।


बिल्ड सर्वर पर सैंडबॉक्स में यू-बूट लोडर चलाना।

लोकप्रिय ओपन सोर्स यू-बूट बूटलोडर रास्पबेरी पाई से निनटेंडो डिवाइस, कार बोर्ड और क्रोमबुक तक के सिस्टम द्वारा समर्थित है। कोई सिस्टम लॉग नहीं है, और अगर कुछ गलत हो जाता है, तो कंसोल आउटपुट भी नहीं हो सकता है। डिबगिंग की सुविधा के लिए, यू-बूट टीम बिल्ड होस्ट या यहां तक ​​कि कंटीन्यूअस इंटीग्रेशन सिस्टम में पैच के परीक्षण के लिए सैंडबॉक्स प्रदान करती है। जीआईटी और जीएनयू कंपाइलर कलेक्शन (जीसीसी) जैसे सामान्य विकास उपकरण वाले सिस्टम पर, यू-बूट सैंडबॉक्स को समझना आसान है।

 $# git clone git://git.denx.de/u-boot; cd u-boot $# make ARCH=sandbox defconfig $# make; ./u-boot => printenv => help 

यह सब है: आपने x86_64 पर यू-बूट लॉन्च किया और आप ट्रिकी फीचर्स का परीक्षण कर सकते हैं, उदाहरण के लिए, काल्पनिक स्टोरेज डिवाइसों का पुनर्मूल्यांकन, टीपीएम-आधारित गुप्त कुंजी हेरफेर और यूएसबी उपकरणों का हॉटप्लग। UDB बूट सैंडबॉक्स GDB डीबगर के भीतर एक-चरण हो सकता है। सैंडबॉक्स का उपयोग करते हुए विकास बोर्ड पर बूटलोडर को अधिलेखित करके परीक्षण से 10 गुना तेज है, इसके अलावा, "ईंट" सैंडबॉक्स को Ctrl + C दबाकर बहाल किया जा सकता है।

कर्नेल लॉन्च

बूटिंग कर्नेल आपूर्ति

अपने कार्यों के पूरा होने पर, बूटलोडर कर्नेल कोड में बदल जाएगा जो इसे मुख्य मेमोरी में लोड करता है और इसे निष्पादित करना शुरू करता है, जो उपयोगकर्ता द्वारा निर्दिष्ट सभी कमांड लाइन मापदंडों को पारित करता है। कर्नेल क्या प्रोग्राम है? फ़ाइल / बूट / vmlinuz से पता चलता है कि यह bzImage है। लिनक्स सोर्स ट्री में एक एक्स्ट्रेक्ट-वीम्लिनक्स टूल है जिसका उपयोग आप फाइल निकालने के लिए कर सकते हैं:

 $# scripts/extract-vmlinux /boot/vmlinuz-$(uname -r) > vmlinux $# file vmlinux vmlinux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped 

कर्नेल लिनक्स उपयोगकर्ता के अंतरिक्ष कार्यक्रमों की तरह एक निष्पादन योग्य और लिंकिंग प्रारूप (ईएलएफ) बाइनरी फ़ाइल है। इसका मतलब है कि हम इसे सीखने के लिए बीनटिल्स कमांड का उपयोग कर सकते हैं। तुलना करें, उदाहरण के लिए, निम्नलिखित निष्कर्ष:

 $# readelf -S /bin/date $# readelf -S vmlinux 

बाइनरी फ़ाइलों में विभाजन की सूची समान भाग के लिए है।

तो, कर्नेल को अन्य ईएलएफ लिनक्स बायनेरिज़ लॉन्च करना चाहिए ... लेकिन उपयोगकर्ता अंतरिक्ष कार्यक्रम कैसे चलते हैं? main() फ़ंक्शन में, है ना? वास्तव में नहीं।

main() फ़ंक्शन चलाने से पहले, प्रोग्राम्स को निष्पादन संदर्भ की आवश्यकता होती है, जिसमें हीप- (हीप) और स्टैक- (स्टैक) मेमोरी, प्लस फाइल डिस्क्रिप्टर फॉर stdio , stdout और stderr । उपयोगकर्ता अंतरिक्ष कार्यक्रम इन संसाधनों को मानक पुस्तकालय (अधिकांश लिनक्स सिस्टम के लिए glibc ) से प्राप्त करते हैं। निम्नलिखित पर विचार करें:

 $# file /bin/date /bin/date: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=14e8563676febeb06d701dbee35d225c5a8e565a, stripped 

ईएलएफ बायनेरिज़ में बैश और पाइथन लिपियों की तरह एक दुभाषिया होता है। लेकिन इसे #! माध्यम से निर्दिष्ट करने की आवश्यकता नहीं है #! लिपियों के रूप में, क्योंकि ईएलएफ एक देशी लिनक्स प्रारूप है। ELF दुभाषिया _start() स्रोत पैकेज में उपलब्ध एक फ़ंक्शन _start() को कॉल करके सभी आवश्यक संसाधनों के साथ बाइनरी फ़ाइल की आपूर्ति करता है, जिसे GDB के माध्यम से सीखा जा सकता है। कर्नेल, जाहिर है, एक दुभाषिया नहीं है, और इसे खुद को स्वतंत्र रूप से आपूर्ति करनी चाहिए, लेकिन कैसे?

GDB के साथ कर्नेल शुरू करने का एक अध्ययन इस प्रश्न का उत्तर प्रदान करता है। आरंभ करने के लिए, कर्नेल डिबगिंग पैकेज स्थापित करें, जिसमें vmlinux का बिना संस्करण शामिल है, उदाहरण के लिए, apt-get install linux-image-amd64-dbg । या उत्कृष्ट डिबियन कर्नेल हैंडबुक के निर्देशों का पालन करते हुए, उदाहरण के लिए, कुछ स्रोत से अपना कर्नेल संकलित और स्थापित करें। gdb vmlinux द्वारा info files बाद ELF अनुभाग init.text । init.text साथ l *(address) में प्रोग्राम के निष्पादन की शुरुआत को इंगित करें, जहां पता init.text का हेक्साडेसिमल प्रारंभ है। GDB इंगित करेगा कि x86_64 कर्नेल को arch/x86/kernel/head_64.S में लॉन्च किया गया है, जहाँ हम बिल्ड फ़ंक्शन start_cpu0() और कोड को स्पष्ट रूप से स्टैक और x86_64 start_kernel() जो x86_64 start_kernel() से पहले कॉल करते हैं। 32-बिट एआरएम कोर में एक समान arch/arm/kernel/head.S. start_kernel() arch/arm/kernel/head.S. start_kernel() आर्किटेक्चर स्वतंत्र है, इसलिए फ़ंक्शन कर्नेल init/main.c में स्थित है। हम कह सकते हैं कि start_kernel() एक वास्तविक main() लिनक्स फ़ंक्शन है।

प्रारंभ_करन () से पीआईडी ​​1 तक
कर्नेल हार्डवेयर मेनिफेस्ट: एसीपीआई टेबल और डिवाइस ट्रीज़

बूट करते समय, कर्नेल को प्रोसेसर के प्रकार के अलावा हार्डवेयर के बारे में जानकारी की आवश्यकता होती है जिसके लिए इसे संकलित किया गया था। कोड के निर्देशों को कॉन्फ़िगरेशन डेटा द्वारा पूरक किया जाता है, जिन्हें अलग से संग्रहीत किया जाता है। डेटा संग्रहीत करने के दो मुख्य तरीके हैं: डिवाइस ट्री और एसीपीआई टेबल । इन फ़ाइलों से, कर्नेल को पता चलता है कि प्रत्येक बूट पर कौन से उपकरण चलाने की आवश्यकता है।

एम्बेडेड उपकरणों के लिए, डिवाइस ट्री (DU) स्थापित उपकरणों का एक प्रकटन है। DU एक फाइल है जो कर्नेल स्रोत के समान समय पर संकलित होती है और आमतौर पर vmlinux के साथ / बूट में स्थित vmlinux । एआरएम डिवाइस पर बाइनरी डिवाइस ट्री में क्या है, यह देखने के लिए, बस फ़ाइल में /boot/*.dtb पैकेज से strings कमांड का उपयोग करें जिसका नाम /boot/*.dtb से मेल /boot/*.dtb , क्योंकि dtb मतलब डिवाइस ट्री (डिवाइस-ट्री बाइनरी) की बाइनरी फाइल है। आप JSON जैसी फ़ाइलों को संपादित करके रिमोट कंट्रोल को बदल सकते हैं और इसमें कर्नेल स्रोत के साथ प्रदान किए गए विशेष dtc कंपाइलर को फिर से शुरू करना है। DU एक स्थिर फ़ाइल है जिसका पथ आमतौर पर कमांड लाइन पर बूटलोडर्स द्वारा कर्नेल को दिया जाता है, लेकिन हाल के वर्षों में एक डिवाइस ट्री ओवरले को जोड़ा गया है जहां कर्नेल लोड होने के बाद हॉटप्लग घटनाओं के जवाब में अतिरिक्त टुकड़ों को गतिशील रूप से लोड कर सकता है।

X86 परिवार और कई ARM64 व्यवसाय-स्तरीय डिवाइस वैकल्पिक उन्नत कॉन्फ़िगरेशन और पावर इंटरफ़ेस ( ACPI) तंत्र का उपयोग करते हैं। रिमोट कंट्रोल के विपरीत, ACPI जानकारी वर्चुअल फ़ाइल सिस्टम /sys/firmware/acpi/tables में संग्रहीत की जाती है, जिसे कर्नेल द्वारा आंतरिक ROM में /sys/firmware/acpi/tables बनाया जाता है। ACPI तालिकाओं को पढ़ने के लिए, acpidump acpica-tools पैकेज से acpidump कमांड का उपयोग करें। यहाँ एक उदाहरण है:


लेनोवो लैपटॉप पर एसीपीआई टेबल विंडोज 2001 के लिए तैयार हैं।

यदि आप इसे स्थापित करना चाहते हैं, तो हाँ, आपका लिनक्स सिस्टम विंडोज 2001 के लिए तैयार है। ACPI में रिमोट कंट्रोल के विपरीत तरीके और डेटा दोनों हैं, जो कि हार्डवेयर विवरण भाषा की तरह है। बूट के बाद ACPI विधियां सक्रिय रहती हैं। उदाहरण के लिए, यदि आप acpi_listen कमांड (apcid पैकेज से) चलाते हैं, और फिर लैपटॉप के ढक्कन को बंद करें और खोलें, तो आप देखेंगे कि ACPI कार्यक्षमता इस सभी समय पर काम करती रही। ACPI तालिकाओं की अस्थायी और गतिशील पुनर्लेखन संभव है, लेकिन स्थायी बदलाव के लिए बूट पर BIOS मेनू के साथ इंटरैक्शन या ROM को चमकाने की आवश्यकता होगी। ऐसी जटिलताओं के बजाय, शायद आपको कोरबूट स्थापित करना चाहिए, खुले स्रोत फर्मवेयर के लिए एक प्रतिस्थापन।

Start_kernel () से लेकर यूजर स्पेस तक

init/main.c का कोड आश्चर्यजनक रूप से पढ़ने में आसान है और अजीब तरह से पर्याप्त है, फिर भी 1991-1992 तक लिनुस टोरवाल्ड्स का मूल कॉपीराइट पहनता है। dmesg | head में पाई जाने वाली लाइनें dmesg | head रनिंग सिस्टम dmesg | head मूल रूप से इस स्रोत फ़ाइल से उत्पन्न होता है। पहला सीपीयू सिस्टम द्वारा पंजीकृत किया गया है, वैश्विक डेटा संरचनाओं को आरंभीकृत किया जाता है, एक के बाद एक शेड्यूलर, इंटरप्ट हैंडलर (आईआरक्यू), टाइमर और कंसोल उठाए जाते हैं। timekeeping_init() चलाने से पहले सभी टाइमस्टैम्प शून्य हैं। कर्नेल इनिशियलाइज़ेशन का यह हिस्सा सिंक्रोनस है, यानी निष्पादन केवल एक थ्रेड में होता है। क्रियाओं को तब तक निष्पादित नहीं किया जाता है जब तक उनमें से अंतिम पूरा नहीं होता है और वापस नहीं लौटता है। नतीजतन, दो प्रणालियों के बीच भी dmesg आउटपुट पूरी तरह से प्रतिलिपि प्रस्तुत करने योग्य होगा, जब तक कि उनके पास एक ही रिमोट कंट्रोल या एसीपीआई टेबल न हो। लिनक्स एक वास्तविक समय के ऑपरेटिंग सिस्टम (RTOS) की तरह व्यवहार करता है जो MCU पर चल रहा है, जैसे कि QNX या VxWorks। यह स्थिति rest_init() फ़ंक्शन में संग्रहीत होती है, जिसे इसके पूर्ण होने के क्षण में start_kernel() द्वारा कॉल किया जाता है।


प्रारंभिक कर्नेल बूट प्रक्रिया का संक्षिप्त विवरण

rest_init() नाम का मामूली रूप से एक नया थ्रेड बनाता है जो kernel_init() चलाता है, जो बदले में do_initcalls() कहता है। उपयोगकर्ता कर्नेल कमांड लाइन में initcalls_debug जोड़कर initcalls_debug के संचालन की निगरानी कर सकते हैं। नतीजतन, आप हर बार जब आप initcall फ़ंक्शन चलाते हैं तो आपको dmesg निकाय मिल जाएगा। initcalls लगातार सात स्तरों से initcalls है: प्रारंभिक, कोर, पोस्टकोर, आर्च, सब्सी, एफएस, डिवाइस और लेट। उपयोगकर्ताओं के लिए initcalls का सबसे ध्यान देने योग्य हिस्सा प्रोसेसर के परिधीय उपकरणों की पहचान और स्थापना है: बस, नेटवर्क, भंडारण, डिस्प्ले, और इसी तरह, उनके कर्नेल मॉड्यूल के लोड के साथ। rest_init() बूट प्रोसेसर में एक दूसरा धागा भी बनाता है, जो cpu_idle() चलाकर शुरू होता है, जबकि शेड्यूलर अपना काम वितरित करता है।

kernel_init() सममित मल्टीप्रोसेसिंग (एसएमपी) भी सेट करता है। आधुनिक कर्नेल में, आप इस पल को dmesg आउटपुट में "सेकेंडरी सीपीयू को लाकर ..." लाइन द्वारा पा सकते हैं। एसएमपी तब सीपीयू को हॉट-प्लग बनाता है, जिसका अर्थ है कि यह ऑटो-सेंसिंग यूएसबी मेमोरी स्टिक जैसे उपकरणों में उपयोग किए जाने वाले उपकरणों के समान ही एक स्टेट मशीन का उपयोग करके अपने जीवन चक्र का प्रबंधन करता है। कर्नेल पावर मैनेजमेंट सिस्टम अक्सर अलग-अलग कोर (कोर) को बंद कर देता है और आवश्यकतानुसार उन्हें जगा देता है ताकि एक ही हॉटप्लग सीपीयू कोड को बार-बार अनचाही मशीन पर कॉल किया जाए। पावर प्रबंधन प्रणाली एक offcputime.py हॉटप्लग को बीसीसी टूल का उपयोग करके कैसे कॉल करती है, इसे offcputime.py ।

ध्यान दें कि जब smp_init() चलाया smp_init() तो init/main.c कोड समाप्त हो smp_init() । बूट प्रोसेसर ने अधिकांश एक बार के आरंभीकरण को पूरा किया, जिसे अन्य गुठली को दोहराने की आवश्यकता नहीं है। हालाँकि, प्रत्येक कोर के लिए थ्रेड्स बनाए जाने चाहिए ताकि प्रत्येक पर इंटरप्ट (IRQ), वर्कच्यू, टाइमर और पावर इवेंट्स को नियंत्रित किया जा सके। उदाहरण के लिए, प्रोसेसर थ्रेड्स को देखें जो ps -o psr. कमांड के साथ सॉफ्टरिक्स और वर्ककेस की सेवा करते हैं ps -o psr.

 $\# ps -o pid,psr,comm $(pgrep ksoftirqd) PID PSR COMMAND 7 0 ksoftirqd/0 16 1 ksoftirqd/1 22 2 ksoftirqd/2 28 3 ksoftirqd/3 $\# ps -o pid,psr,comm $(pgrep kworker) PID PSR COMMAND 4 0 kworker/0:0H 18 1 kworker/1:0H 24 2 kworker/2:0H 30 3 kworker/3:0H [ . . . ] 

जहां PSR फ़ील्ड का अर्थ है "प्रोसेसर"। प्रत्येक कोर का अपना टाइमर और सीपीयू हॉटप्लग हैंडलर होना चाहिए।

और अंत में, उपयोगकर्ता स्थान कैसे लॉन्च किया जाता है? अंत में, kernel_init() एक initrd तलाश में है जो अपनी ओर से init प्रक्रिया शुरू कर सकता है। यदि नहीं, तो कर्नेल अपने दम init निष्पादित करता है। फिर initrd आवश्यकता क्यों हो सकती है?

प्रारंभिक उपयोगकर्ता स्थान: initrd का आदेश किसने दिया?

डिवाइस ट्री के अलावा, फ़ाइल में एक और init पथ, वैकल्पिक रूप से बूट पर कर्नेल द्वारा प्रदान किया गया, initrd । initrd अक्सर x86 पर bzImage vmlinuz फ़ाइल के साथ / एआरएम के समान यूआईमैज और डिवाइस ट्री के साथ / बूट में स्थित होता है। intrd कंटेंट की एक सूची को intrd टूल का उपयोग करके देखा जा सकता है, जो कि initramfs-tools-core पैकेज का हिस्सा है। Initrd वितरण छवि में न्यूनतम निर्देशिका /bin , /sbin और /etc , साथ ही कर्नेल मॉड्यूल और फ़ाइलें /scripts । सब कुछ कम या ज्यादा परिचित दिखना चाहिए, क्योंकि initrd सरल लिनक्स रूट फाइल सिस्टम के समान अधिकांश भाग के लिए है। यह समानता थोड़ी सी भ्रामक है, क्योंकि रैमडिस्क के अंदर /bin और /sbin में लगभग सभी निष्पादनयोग्य व्यस्तमबाइनरी बाइनरी के लिए सीमलिंक हैं , जो / बिन और / sbin निर्देशिकाओं को glibc तुलना में 10 गुना छोटा बनाता है।

एक initrd बनाने की कोशिश क्यों करें अगर एकमात्र चीज जो कुछ मॉड्यूल लोड करती है और एक नियमित रूट फाइल सिस्टम पर init चलाती है? एक एन्क्रिप्टेड रूट फ़ाइल सिस्टम पर विचार करें। डिक्रिप्शन रूट फ़ाइल सिस्टम के /lib/modules में संग्रहीत कर्नेल मॉड्यूल को लोड करने पर निर्भर हो सकता है ... और, जैसा कि अपेक्षित है, initrd । क्रिप्टो मॉड्यूल को कर्नेल में संकलित किया जा सकता है, और फ़ाइल से लोड नहीं किया जा सकता है, लेकिन इसे मना करने के कई कारण हैं। उदाहरण के लिए, मॉड्यूल के साथ कर्नेल का स्थैतिक संकलन उपलब्ध भंडारण में फिट होने के लिए बहुत बड़ा हो सकता है, या स्थैतिक संकलन लाइसेंस लाइसेंस शर्तों का उल्लंघन कर सकता है। Unsurprisingly, भंडारण ड्राइवर, नेटवर्क और HID (मानव इनपुट डिवाइस) को initrd में भी दर्शाया जा सकता है - मूल रूप से कोई भी कोड जो रूट फ़ाइल सिस्टम को माउंट करने के लिए आवश्यक कर्नेल का एक आवश्यक हिस्सा नहीं है। Initrd में भी, उपयोगकर्ता तालिकाओं के लिए अपना स्वयं का ACPI कोड संग्रहीत कर सकते हैं।


बचाव शेल और कस्टम initrd के साथ मज़ा।

initrd फाइल सिस्टम और स्टोरेज डिवाइस के परीक्षण के लिए भी बढ़िया है। परीक्षण उपकरण को initrd में रखें और परीक्षण को मेमोरी से चलाएं, टेस्ट ऑब्जेक्ट से नहीं।

अंत में, जब init चल रहा है, सिस्टम चल रहा है! चूंकि माध्यमिक प्रोसेसर पहले से ही चल रहे हैं, मशीन एक अतुल्यकालिक, पृष्ठांकित, अप्रत्याशित और उच्च प्रदर्शन वाला प्राणी बन गया है जिसे हम सभी जानते हैं और प्यार करते हैं। दरअसल, ps -o pid,psr,comm -p यह दर्शाता है कि बूट स्पेस पर यूजर स्पेस init प्रक्रिया अब नहीं चल रही है।

परिणाम

लिनक्स बूट प्रक्रिया को निषिद्ध लगता है, एक साधारण एम्बेडेड डिवाइस पर भी प्रभावित सॉफ्टवेयर की मात्रा को देखते हुए। दूसरी ओर, बूट प्रक्रिया काफी सरल है, क्योंकि मल्टीटास्किंग, आरसीयू और दौड़ की स्थितियों में भीड़ के कारण कोई अत्यधिक जटिलता नहीं है। केवल कर्नेल और पीआईडी ​​1 पर ध्यान देते हुए, कर्नेल लॉन्च के लिए प्लेटफॉर्म तैयार करने के लिए बूट लोडर और सहायक प्रोसेसर द्वारा किए गए महान काम को अनदेखा कर सकते हैं। कर्नेल निश्चित रूप से अन्य लिनक्स कार्यक्रमों से अलग है, लेकिन अन्य ईएलएफ बायनेरिज़ के साथ काम करने के लिए टूल का उपयोग करने से इसकी संरचना को बेहतर ढंग से समझने में मदद मिलेगी। एक व्यावहारिक बूट प्रक्रिया का अध्ययन भविष्य के दुर्घटनाओं के लिए तैयार करेगा।

अंत

हम आपकी टिप्पणियों और प्रश्न की प्रतीक्षा कर रहे हैं, हमेशा की तरह, यहां या हमारे खुले पाठ में जहां लियोनिद को उड़ा दिया जाएगा।