GRUB से पहले Linux / xBSD बूट कैसे हुआ?

23

विकिपीडिया के अनुसार , GRUB को 1995 में जारी किया गया था। उस समय तक लिनक्स और xBSD कई वर्षों तक मौजूद थे। मुझे पता है कि शुरुआती यूनिक्स संस्करण 70 और 80 के दशक में हार्डवेयर से जुड़े थे, लेकिन लिनक्स और एक्सबीएसडी वितरित करने और स्थापित करने के लिए स्वतंत्र थे। जो इस सवाल का जवाब देता है कि आप लिनक्स को वापस कैसे बूट करेंगे? क्या वितरण बूटलोडर्स के अपने कार्यान्वयन के साथ शिपिंग थे?

boot-loader history

— सर्गी कोलोडियाज़नी
स्रोत

32

उम्म ... आप तब नहीं थे जब लिलो केवल लिनक्स बूटलोडर था? और मैंने अपने बीएसडी सिस्टम पर कभी भी LILO और न ही ग्रब का उपयोग नहीं किया है। आप किस में रुचि रखते हैं? उदाहरण देखें biosboot(8)।

— Kusalananda

8

@ कुसलानंद दुर्भाग्य से, मैंने खिलौनों और ड्राइंग की तुलना में निंजा कछुओं को पाइप, एग्जॉस्ट और गोले की तुलना में अधिक ध्यान दिया। :) मुझे सामान्य इतिहास में दिलचस्पी है, विशिष्ट बूटलोडर की नहीं। आपके द्वारा लिंक किए गए पृष्ठ से मैं देखता हूं कि OpenBSD में biosbootदो आर्किटेक्चर, i386 और amd64 के लिए है। क्या इसका मतलब यह है कि OpenBSD को विशेष रूप से एक, एकीकृत उपकरण होने के बजाय आर्किटेक्चर को लक्षित करना था?

— सर्गी कोलोडियाज़नी

1

पहले चरण का बूटलोडर प्रत्येक आर्किटेक्चर के लिए अलग होगा (केवल i386 और amd64 में वैसे भी "बायोस" BIOS है)। यदि आप bog मानक PC से अधिक विदेशी आर्किटेक्चर में रुचि रखते हैं, तो NetBSD पर एक नज़र डालें।

— Kusalananda

3

@ कुसलानंद मुझे नहीं लगता कि LILO कभी केवल लिनक्स बूटलोडर था। जहां तक मुझे पता है कि कर्नेल छवियों में निर्मित लोडर LILO से पहले है, और जब तक लोडर में निर्मित के लिए समर्थन बंद नहीं हो जाता तब तक कम से कम अन्य बूटलोडर्स के आसपास मुट्ठी भर थे।

— कास्परड

2

2000 के दशक की शुरुआत तक LILO डिफॉल्ट बूटलोडर था, जो बहुत

— परेशान था

51

पहले लिनक्स वितरण का उपयोग मैंने 90 के दशक में किया था ( Slackware 3.0IIRC) ने LILO का उपयोग बूटलोडर के रूप में किया । और "डिफॉल्ट" बूटलोडर बनने के LILOदौरान भी सालों तक इस्तेमाल किए जाने वाले कई डिस्ट्रोस GRUB।

इसके अलावा, लिनक्स के शुरुआती वर्षों में, बूटलोडर / ड्यूल बूटिंग पर निर्भर रहने के बजाय दूसरे OS (यानी DOS या Windows) से लिनक्स को बूट करना आम बात थी। उदाहरण के लिए लोडलीन था ।

Syslinux को न भूलें , जो कि एक साधारण बूट लोडर है जिसका उपयोग अक्सर USB स्व-बूट करने योग्य इंस्टॉलेशन / रिकवरी डिस्ट्रोस के लिए किया जाता है। या आइसोलिनक्स (एक ही परियोजना से) कई "लाइव" डिस्ट्रोस द्वारा उपयोग किया जाता है।

ध्यान रखें कि आज GRUBका उपयोग कई ऑपरेटिंग सिस्टम को लोड करने के लिए किया जा सकता है, जबकि LILOअधिक सीमित था, और विशेष रूप से लिनक्स (यानी LInux LOader) पर लक्षित किया गया था, विंडोज के लिए दोहरी बूटिंग के लिए कुछ समर्थन के साथ।
GRUBअपने कई विन्यास विकल्पों, स्क्रिप्टिंग क्षमताओं, आदि के कारण दोहरी / बहु बूटिंग के लिए बहुत उपयोगी है ...
यदि आप बस अपने मशीन पर "किसी भी" (यानी जो भी आपके बूटलोडर को लिनक्स / बीएसडी वितरण के लिए डिफ़ॉल्ट है) पर एकल ओएस चाहिए काफी होना।

— श्री शुनज
स्रोत

5

@ श्रीशंज: उस समय कोई यूईएफआई नहीं था। बूट खिड़कियां बस जैसे की एक प्रविष्टि जोड़ने की बात थी other=/dev/hda1के साथ table=/dev/hdaकरने के लिए lilo.conf, और लिलो सिर्फ hda1 पर बूट सेक्टर को नियंत्रण हस्तांतरण होता है, विभाजन तालिका जानने HDA पर होगा।

— नंजलज

2

आप लिलो को लोड करने के लिए एनटीएलडीआर प्राप्त करने में सक्षम थे; jaeger.morpheus.net/linux/ntldr.php देखें ; मैंने स्वतंत्र रूप से उसी की खोज की, दिन में वापस।

— रोजर लिप्सकॉम्ब

2

LILO दृष्टिकोण का नकारात्मक पक्ष यह है कि यदि परिवर्तन को लोड करने के लिए फ़ाइलों की डिस्क का स्थान टूट जाता है। विशेष रूप से इसका मतलब है कि LILO को हर कर्नेल अपग्रेड के बाद बूट स्थान (या तो MBR या पार्टीशन बूट सेक्टर) पर फिर से लिखना होगा।

— प्लगवैन

1

@plugwash: GRUB की दूसरी चरण फ़ाइल के साथ एक ही समस्या है। यहाँ अंतर यह है कि 1) LILO का "दूसरा चरण" कर्नेल था , इसलिए यह कर्नेल अपडेट था, न कि LILO अपडेट जिसने चीजों को तोड़ा; और 2) GRUB अपडेट में MBR के लिए दूसरे चरण के स्थान का एक स्वत: पुनः लेखन शामिल है (दूसरे चरण के साथ लिनक्स कर्नेल को लोड करना, फाइल सिस्टम की पूरी जानकारी के साथ ताकि कर्नेल स्थान कोई फर्क नहीं पड़ता)। ;-)

— DevSolar

1

IIRC ग्रब यदि संभव हो तो एक "स्टेज 1.5" को स्टोर कर सकता है जो एमबीआर और पहले विभाजन के बीच फाइल सिस्टम को समझता है और केवल विशिष्ट फाइलसिस्टम क्षेत्रों के लिए एक संदर्भ संग्रहीत करने का सहारा लेगा यदि चरण 1.5 के लिए कोई जगह नहीं है (या यदि यह स्थापित है एमबीआर के बजाय एक विभाजन बूट सेक्टर)

— प्लगवॉश

28

LILO ग्रब से पहले पीसी पर लिनक्स को बूट करने के लिए डी-फैक्टो मानक था, एक बहुत ही प्रारंभिक चरण (एमसीसी, पहले लिनक्स वितरण में से एक था, इसका इस्तेमाल किया)। विभिन्न अन्य बूटलोडर्स का उपयोग समकालीन रूप से किया गया था। लोडलिन काफी सामान्य था; यह डॉस से लिनक्स को बूट करता है, और यहां तक कि कुछ कॉन्फ़िगरेशन umsdosमें एक डॉस फाइल सिस्टम में लिनक्स वातावरण को होस्ट करने के लिए उपयोग किया गया था ... एक अन्य सामान्य कॉन्फ़िगरेशन में एक बूटलोडर शामिल नहीं था: कर्नेल एक फ्लॉपी से बूट कर सकता है, और सबसे लिनक्स उपयोगकर्ताओं ने "बूट और रूट" फ्लॉपीज की एक जानी-मानी जोड़ी को रखा, जिसमें से एक कर्नेल, अन्य बचाव के लिए एक मूल रूट फाइल सिस्टम था।

लिनक्स में बूट करने के लिए अन्य ऑपरेटिंग सिस्टम के बूटलोडर्स का उपयोग करने के कई तरीके थे; उदाहरण के लिए, OS / 2 का बूट मैनेजर, या Windows NT का NTLDR।

अन्य प्रणालियों के अपने बूटलोडर्स थे:

SILO स्पार्क पर (सूर्य वर्कस्टेशन और अन्य);
पीए-आरआईएससी (एचपी वर्कस्टेशन) पर पालो ;
पावरबैंक पर हांबूट और क्विक;
अल्बर्ट पर अल्फा और MILO ...

आजकल भी ग्रब एकमात्र ऐसा बूटलोडर नहीं है जिसे आप देखेंगे। फ्लॉपी से सीधे कर्नेल बूट होने के बाद अब बहुत उपयोगी नहीं है (मैंने जांच नहीं की है कि क्या यह अभी भी संभव है, यह मानते हुए कि आप फ्लॉपी पर फिट होने के लिए एक कर्नेल को छोटा बना सकते हैं), यह सीधे ईएफआई से बूट कर सकता है (जो प्रभावी रूप से इसका है) स्वयं का छोटा ऑपरेटिंग सिस्टम जिसे अन्य ऑपरेटिंग सिस्टम को लोड करने के लिए डिज़ाइन किया गया है, जैसा कि ग्रब है)। कई छोटे सिस्टम (एम्बेडेड सिस्टम, सिंगल-बोर्ड कंप्यूटर ...) पर आपको यू-बूट मिलेगा । (और यू-बूट के लिए एक EFI परत भी है ।)

— स्टीफन किट
स्रोत

पावरपीसी आर्किटेक्चर भी दिलचस्प है क्योंकि कुछ मदरबोर्ड में ट्यूरिंग-पूर्ण BIOS - ओपनफर्मवेयर (मूल रूप से कुछ पूर्वस्थापित कार्यों के साथ फोर्थ प्रोग्रामिंग भाषा) था। यह बिना बूटलोडर के BIOS से सीधे बूटिंग की अनुमति देता है यदि आप जानते हैं कि आपके BIOS को कैसे कॉन्फ़िगर किया जाए

— स्लीवेटमैन

अरे, बस जिज्ञासु, NTLDR सीधे लिनक्स कर्नेल लोड कर सकते हैं? मैंने सुना है कि NTLDR grload4dos को चेनलोड कर सकता है और फिर लिनक्स कर्नेल को लोड कर सकता है।

— 炸鱼炸鱼 at

@slebetman: अधिक सटीक रूप से, OpenFirmware को SPARC के लिए Sun द्वारा विकसित किया गया था और फिर PowerPC संदर्भ आर्किटेक्चर के लिए PowerPC गठबंधन (IBM, Apple, Motorola) और विशेष रूप से Apple द्वारा PowerPC- आधारित मैकिंट्स के लिए अपनाया गया था। शक्तिशाली पहलुओं में से एक यह था कि सरल ड्राइवरों को विस्तार कार्डों पर, या एक HDD के कुछ निर्दिष्ट बूट क्षेत्र में ROM चिप्स के अंदर संग्रहीत किया जा सकता है, और चूँकि उन्हें एक ज्ञात निर्दिष्ट ABI के खिलाफ bytecode में लिखा गया था, वे सीपीयू की परवाह किए बिना काम करेंगे। आर्किटेक्चर और OS जिसे आप बूट करने की कोशिश कर रहे थे।

— जोर्ग डब्ल्यू मित्तग 14

उदाहरण के लिए, आपके पास RAID एडेप्टर हो सकता है, जिसमें ROM चिप के अंदर उसका OpenFirmware ड्राइवर होता है, फिर OpenFirmware पर्यावरण उस ड्राइवर का उपयोग कर सकता है RAID का उपयोग करने के लिए, RAID के अंदर, विभाजन तालिका प्रारूप के लिए एक और ड्राइवर हो सकता है, जो OFW पर्यावरण की अनुमति देगा विभाजनों को खोजने के लिए, प्रत्येक विभाजन की शुरुआत में फाइलसिस्टम के लिए एक OFW ड्राइवर होगा, जो OFW सिस्टम को कर्नेल को खोजने की अनुमति देगा, और कर्नेल के पास शुरुआत में OFW बाइटकोड में लिखा एक छोटा बूटलोडर होगा।

— जोर्ग डब्ल्यू मित्तग

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

— जोर्ग डब्ल्यू मित्तग

12

2.6 2.6 कर्नेल के माध्यम से, x86 कर्नेल सीधे बूट करने योग्य था यदि फ्लॉपी डिस्क पर कॉपी किया गया था (जैसे कि यह एक डिस्क छवि थी)।

यह वास्तव में, लिनक्स को बूट करने का मूल तरीका था।

यदि आप आज एक x86 कर्नेल के हेडर को देखते हैं, तो आपको एक त्रुटि संदेश दिखाई देता है जो कहता है कि फ्लॉपी से बूट करना जैसे कि अब काम नहीं करता है।

— यहोशू
स्रोत

2

दूसरी ओर, U86I फर्मवेयर को दिए जाने पर x86 कर्नेल अब सीधे बूट करने योग्य है। तो वहाँ अभी भी एक ठूंठ बूटलोडर गिरी, बस एक अलग प्रकार के सामने हमला बोला है ...

— grawity

@ शुद्धता: क्या आप सुनिश्चित हैं कि आपका मतलब x64 नहीं है?

— जोशुआ

1

@ जोशुआ: मुझे यकीन नहीं है कि आपका क्या मतलब है। EFI वास्तव में इस भाग को कोड के रूप में निष्पादित नहीं करता है।

— ग्रिटिटी

2

@ जोशुआ क्या? यह 16-बिट मोड (32 बिट मोड में EBP / EDX) में "DEC BP", "POP DX" है। लेकिन इसे वैसे भी निष्पादित नहीं किया जाना चाहिए; EFI बायनेरिज़ पीई फाइलें हैं (यदि यह किसी बूट सेक्टर को लिखा गया है तो निश्चित रूप से कोई फर्क नहीं पड़ता ...)।

— स्टीफन किट

1

@ जोशुआ ठीक है, लेकिन यह मेरे दिमाग में अपरिभाषित x86 व्यवहार नहीं है;; (मुझे लगता है कि "अपरिभाषित x86 व्यवहार" opcodes के रूप में जिसका व्यवहार परिभाषित नहीं है, अपरिभाषित मंच व्यवहार नहीं है।)

— स्टीफन किट

5

मैंने 90 के दशक के अंत में लिनक्स के साथ शुरुआत की थी और जैसा कि बताया liloगया था डिफ़ॉल्ट था। यदि आप DOS सिस्टम के साथ दोहरी बूट करना चाहते हैं, तो आप HIMEM में सामान लोड किए बिना या CD ड्राइवरों को लोड किए बिना नंगे बूट कर सकते हैं, आदि और उपयोग loadlin। Win95 दोहरी बूटिंग के लिए, आप ड्राइव को पहले DOS के साथ बूट करने योग्य बना सकते हैं, फिर '95 स्थापित करें, और '95 का बूट लोडर आपको DOS कर्नेल को बूट करने देगा, और फिर आप उपयोग कर सकते हैंloadlin ।

NT4 के साथ दोहरी बूटिंग के लिए, /विभाजन के लिए LILO लिखने के लिए चाल थी , फिर पहले 512 बाइट्स का उपयोग करके पट्टी dd(dd if=/dev/sda2 of=/path/to/file bs=512 count=1 ) और परिणामी फ़ाइल को डाल दें जहां ntldrयह देख सके और आप इसे WinNT के बूट लोडर से उपयोग कर सकते हैं। ऐसा करने के साथ समस्या यह है कि जब आप अपने कर्नेल को अपग्रेड करते हैं, तो आपको रिबूट करने से पहले सभी चरणों को दोहराना याद था, अन्यथा आपके पास लिनक्स सिस्टम में वापस आने के मुद्दे होंगे। वही प्रक्रिया Win2k के साथ काम करती है।

LILO के साथ, किसी भी समय कर्नेल को अपडेट किया गया था, आपको LILO को अपडेट करना याद रखना था।

साथ में loadlin किसी भी समय गिरी अद्यतन, आप डॉस विभाजन के लिए कर्नेल बाहर कॉपी करने के लिए याद करने के लिए किया था।

अन्य उत्तरों में संकेत दिया गया एक अन्य विकल्प कर्नेल को एक फ्लॉपी पर सीधे लिखना था, dd if=/path/to/vmlinuz of=/dev/fd0लेकिन BUT का उपयोग करके रूट डिवाइस को कर्नेल में ठीक से सेट किया गया था या rdevउपयोगिता का उपयोग करके ।

जब GRUBआसपास आया था, तो बहुत आनन्दित था क्योंकि अब आपको LILO को अपडेट करने, या LILO को अपडेट करने और बूट जानकारी को फिर से पट्टी करने के लिए याद नहीं करना था, आदि अब आपके लिनक्स सिस्टम से बाहर रहना नहीं है क्योंकि आप बूट लोडर को अपडेट करना भूल गए हैं जानकारी ...

— ivanivan
स्रोत

लगता है कि यह पूरी तरह से बहुत काम और उच्च मौका था कि गैर-बूटिंग मशीन के साथ वापस छोड़ दिया जाए, लेकिन निश्चित रूप से एक शैक्षिक अनुभव

— सर्गी कोलोडाज़नी

@SergiyKolodyazhnyy हाँ, और इंटरनेट पर जानकारी का इतना धन नहीं था, या महान खोज इंजन इसे खोजने के लिए अगर यह वहां था। कई एकल फ्लॉपी डिस्क रेस्क्यू डिस्ट्रोस थे, जिनमें लिलो को ठीक करने और ठीक करने के लिए पर्याप्त लिनक्स था, आदि हमने एक लंबा सफर तय किया है!

— ivanivan

रनिंग make installचलेगी /sbin/lilo, इसलिए आपको वास्तव में हाथ से कुछ भी अपडेट नहीं करना था (और यदि आप अभी भी liloस्थापित हो सकते हैं, तो यह मामला हो सकता है)। यह एक राय का विषय हो सकता है, लेकिन मुझे grubइसके विपरीत, बहुत खुशी की याद नहीं है । और lilo(कम से कम इसका 1999 संस्करण) दोहरी बूट विंडोज़ को ठीक कर सकता है, जिसकी कोई आवश्यकता नहीं है loadlin।

— 19

0

और LILO और GRUB से पहले, आपको इसे कमांड लाइन से कस्टम बूटलोडर उपयोगिता के कुछ प्रकार के साथ लॉन्च करना था।

एक उदाहरण के रूप में, अमीगा में लिनक्स उपलब्ध था। आपको कर्नेल ELF को मेमोरी में लोड करने और उस पर कूदने के लिए अमीबूट नामक कमांड लाइन उपयोगिता का उपयोग करना था।

यहाँ अमीगा 600 पर लिनक्स लॉन्च करने के लिए कमांड लाइन से अमीबूट का उपयोग करने वाले किसी व्यक्ति का वीडियो है । उनकी StartInstall स्क्रिप्ट अमीबूट को निष्पादन योग्य कह रही है। आप स्मृति को कॉन्फ़िगर करने, वांछित लोड पते का पता लगाने और कर्नेल को लगभग 0:55 पर मापदंडों को देखने के लिए देख सकते हैं।

— BoredBsee
स्रोत