Як Linux / xBSD завантажувався перед GRUB?


23

Згідно з Вікіпедією , GRUB був випущений в 1995 році. До цього моменту Linux і xBSD існували кілька років. Я знаю, що перші версії Unix були прив’язані до обладнання в 70-х і 80-х роках, але Linux і xBSD вільно розповсюджували та встановлювали. Хто задає питання, як би ви тоді ще завантажували Linux? Чи доставляли дистрибуції власні реалізації завантажувачів?


32
Гм ... Вас не було, коли LILO був єдиним завантажувачем Linux? І я ніколи не використовував LILO та Grub у своїх системах BSD. Який із вас цікавий? Див. Напр biosboot(8).
Кусалаланда

8
@Kusalananda На жаль, я більше дбав про іграшки та малювання черепах ніндзя, ніж про труби, екзеки та снаряди тоді :) Мене цікавить загальна історія, а не конкретний завантажувач. Зі сторінки, яку ви пов’язали, я бачу, що OpenBSD має biosbootдві архітектури, i386 та amd64. Чи означає це, що OpenBSD спеціально повинен був націлюватись на архітектури, а не мати один, об’єднуючий інструмент?
Сергій Колодяжний

1
Завантажувач на першому етапі був би різним для кожної архітектури (у будь-якому випадку i386 та amd64 мають "BIOS" BIOS). Погляньте на NetBSD, якщо вас цікавлять екзотичніші архітектури, ніж стандартний ПК.
Kusalananda

3
@Kusalananda Я не думаю, що LILO ніколи не був єдиним завантажувачем Linux. Наскільки мені відомо, завантажувач, вбудований у зображення ядра, передував LILO, і до того часу, коли підтримка вбудованого навантажувача була припинена, навколо було як мінімум кілька інших завантажувачів.
kasperd

2
LILO був завантажувачем за замовчуванням для багатьох дистрибутивів до початку 2000-х
phuclv

Відповіді:


51

Перший дистрибутив Linux, який я використовував ще в 90-х ( Slackware 3.0IIRC), використовував LILO як завантажувач. І багато дистрибутивів використовувалися LILOроками навіть тоді, коли GRUBставав завантажувачем за замовчуванням.

Більше того, в перші роки Linux було звичайним завантажувати Linux з іншої ОС (тобто DOS або Windows), а не покладатися на завантажувач / подвійне завантаження. Наприклад, був вантаж .

Не забувайте про Syslinux , який є більш простим завантажувачем, який часто використовується для самозавантажуваного дистрибутива USB для встановлення / відновлення. Або Isolinux (з того ж проекту), який використовується багатьма дистрибутивами "Live".

Майте на увазі, що сьогодні GRUBможна використовувати для завантаження багатьох операційних систем, хоча він LILOбув більш обмеженим і спеціально орієнтований на Linux (тобто LInux LOader), маючи певну підтримку подвійного завантаження в Windows.
GRUBє дуже корисним для подвійного / багатозавантажувального інструменту через безліч параметрів, які можна настроювати, можливості сценаріїв тощо.
Якщо ви просто хочете, щоб на вашій машині була одна операційна ОС (будь-яка завантажувач за замовчуванням для вашого дистрибутива Linux / BSD) буде достатньо


5
@MrShunz: тоді ще не було УЄФІ. Завантаження вікон було лише питанням додавання запису, наприклад, other=/dev/hda1до table=/dev/hdaдо lilo.conf, а lilo просто передаватиме керування завантажувальному сектору на hda1, знаючи, що таблиця розділів буде в hda.
ніндзя

2
Ви раніше могли отримувати NTLDR для завантаження LILO; див. jaeger.morpheus.net/linux/ntldr.php ; Я відкрив те саме самостійно, ще в той день.
Роджер Ліпскомб

2
Мінусом підходу LILO є те, що він змінюється, якщо змінюється розташування диска файлів для завантаження. Зокрема, це означає, що після кожного оновлення ядра LILO потрібно було перезаписати у місце завантаження (або MBR, або сектор завантаження розділу).
підключіть

1
@plugwash: GRUB має те саме питання, що і файл другого етапу. Різниця тут полягає в тому, що 1) "другий етап" LILO був ядром, тому оновлення ядра, а не оновлення LILO руйнували речі; і 2) Оновлення GRUB включають автоматичне перезапис місця другого ступеня в MBR (з другого етапу потім завантаження ядра Linux, з повним знанням файлової системи, тому розташування ядра не має значення). ;-)
DevSolar

1
Груб IIRC, якщо можливо, зберігатиме "етап 1.5", який розуміє файлову систему між MBR та першим розділом і вдасться зберегти посилання на конкретні сектори файлової системи, якщо для етапу 1.5 немає місця (або якщо він встановлюється на сектор завантаження розділів, а не MBR)
підключіть програму

28

LILO був фактичним стандартом для завантаження Linux на ПК до Grub, з дуже ранньої стадії (MCC, один з перших дистрибутивів Linux, використовував його). Одночасно використовувались різні завантажувачі. Лоадлін був досить поширеним; він завантажив Linux з DOS і навіть використовувався в деяких конфігураціях, umsdosщоб розмістити середовище Linux у файловій системі DOS ... Інша поширена конфігурація взагалі не передбачала завантажувача: ядро ​​могло завантажуватися з дискети, і більшість Користувачі Linux зберігали відому гарну пару дискети "завантажувальний і корінний", одна з яких містить ядро, а інша - основна коренева файлова система для порятунку.

Існував ряд способів використання завантажувачів інших операційних систем для завантаження Linux; наприклад, менеджер завантаження ОС / 2 або NTLDR Windows NT.

Інші системи мали власні завантажувачі:

  • СІЛО на SPARC (робочі станції Sun та інші);
  • PALO на PA-RISC (робочі станції HP);
  • YaBoot та Quik на PowerPC;
  • aBoot та MILO на Альфа ...

Навіть сьогодні Grub - не єдиний завантажувач, який ви побачите. Хоча завантаження ядра безпосередньо з дискети вже не дуже корисно (я ще не перевіряв, чи все ще можливо, припускаючи, що ви можете створити ядро, достатньо мале для розміщення на дискеті), воно може завантажуватися безпосередньо з EFI (що фактично є його власна невелика операційна система, призначена для завантаження інших операційних систем, як і Grub). У багатьох менших системах (вбудовані системи, однопланові комп'ютери ...) ви знайдете U-Boot . (А також є шар EFI для U-Boot .)


Архітектура PowerPC також цікава тим, що на деяких материнських платах був BIOS - Openfirmware (повністю - Turing) (в основному мова програмування Forth з деякими попередньо встановленими функціями). Це дозволило завантажуватися безпосередньо з BIOS без завантажувача, якщо ви знаєте, як налаштувати свій BIOS
slebetman

Гей, просто цікаво, NTLDR може завантажувати Linux ядро ​​безпосередньо? Я чув, що NTLDR може завантажувати grub4dos, а потім завантажувати ядро ​​Linux.
炸鱼 薯条 德里克

@slebetman: Точніше, OpenFirmware був розроблений Sun для SPARC, а потім прийнятий альянсом PowerPC (IBM, Apple, Motorola) для довідкової архітектури PowerPC і конкретно Apple для Macintoshs на базі PowerPC. Одним із найважливіших аспектів було те, що прості драйвери можуть зберігатися всередині мікросхем ROM на картах розширення або в певній визначеній області завантаження жорсткого диска, і оскільки вони були записані в байт-коді проти відомого зазначеного ABI, вони працюватимуть незалежно від того, який процесор архітектури та ОС, яку ви намагалися завантажити.
Йорг W Міттаг

Наприклад, у вас може бути адаптер RAID, у якого є драйвер OpenFirmware всередині чіпа ROM, тоді середовище OpenFirmware може використовувати цей драйвер для доступу до RAID, всередині RAID, може бути ще один драйвер для формату таблиці розділів, який би дозволяв середовищу OFW щоб знайти розділи, на початку кожного розділу був би драйвер OFW для файлової системи, який би дозволив системі OFW знайти ядро, а ядро ​​матиме невеликий завантажувач, записаний у байт-коді OFW на початку.
Йорг W Міттаг

GRUB може працювати аналогічно, але різниця полягає в тому, що всі ці драйвери повинні бути написані спеціально для GRUB, тоді як краса OFW полягала в тому, що пристрій приносив би своїх драйверів, а це означає, що навіть пристрої, які ще не працювали Існують, коли середовище OFW було написано, просто "магічно" спрацювало. UEFI також може працювати аналогічним чином, але його "портативний формат байт-кодів" є по суті підмножиною DOS, що є основною причиною, чому Itaniums все ще потребує емулятора x86.
Йорг W Міттаг

12

Наскрізь через середину 2.6 ядер, x86 ядро ​​було безпосередньо завантаженим, якщо його скопіювали на дискету (як би це було зображення диска).

Насправді це був оригінальний спосіб завантаження Linux.

Якщо ви сьогодні подивитеся на заголовок ядра x86, ви побачите повідомлення про помилку, в якому сказано, що завантаження з дискети подібне більше не працює.


2
З іншого боку, ядро ​​x86 зараз безпосередньо завантажується, якщо його надають програмне забезпечення UEFI. Отже, перед ядром ще завантажений завантажувач заглушки, просто іншого типу ...
grawity

@grawity: Ви впевнені, що не маєте на увазі x64?
Джошуа

1
@ Джошуа: Я не впевнений, що ти маєш на увазі під цим. EFI фактично не виконує цю частину як код.
grawity

2
@Joshua що? Це "DEC BP", "POP DX" в 16-бітному режимі (EBP / EDX в 32-бітному режимі). Але це все одно не повинно бути виконано; Бінарні файли EFI - це файли PE (що, звичайно, не має значення, чи записується він у завантажувальний сектор ...).
Стівен Кітт

1
@Joshua Гаразд, але це не визначена поведінка x86 у моїй свідомості ;-). (Я думаю, що "невизначена поведінка x86" як опкоди, поведінка яких не визначена, не визначена поведінка платформи.)
Стівен Кітт

5

Я почав працювати з Linux в кінці 90-х, і, як згадувалося, liloза замовчуванням. Якщо ви хочете подвоїти завантаження за допомогою системи DOS, ви можете зробити голий завантажувач, не завантажуючи речі в HIMEM або завантажуючи драйвери компакт-дисків, тощо 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. Проблема з цим полягає в тому, що під час оновлення ядра вам довелося пам’ятати повторити всі кроки перед перезавантаженням, інакше у вас виникнуть проблеми з поверненням в систему Linux. Цей же процес працював і з Win2k.

З LILO, щоразу, коли ядро ​​оновлювалося, вам потрібно було пам'ятати, щоб оновити LILO.

Щоразу, loadlinколи ядро ​​оновлювалося, вам довелося пам’ятати скопіювати ядро ​​на розділ DOS.

Ще один варіант, на який натякають інші відповіді, - це записати ядро ​​безпосередньо на дискету за допомогою dd if=/path/to/vmlinuz of=/dev/fd0АЛЕ кореневий пристрій потрібно було правильно встановити в ядрі, або під час компіляції, або за допомогою rdevутиліти.

Коли GRUBприїхали, було дуже радісно, ​​тому що вам більше не доводилося пам’ятати про оновлення LILO або оновлення LILO та повторне зняття інформації про завантаження тощо. Більше не залишаючись із системи Linux, оскільки ви забули оновити завантажувач. інформація ...


Здається, що це було багато роботи та великий шанс залишитися з машиною без завантаження тоді, але, безумовно, навчальним досвідом
Сергій Колодяжний

@SergiyKolodyazhnyy Так, і в Інтернеті не було такого багатства інформації або великих пошукових систем, щоб знайти її, якщо вона там була. Було кілька рятувальних дискотек для одиночної дискети, у яких було достатньо Linux для завантаження та виправлення LILO тощо. Ми пройшли довгий шлях!
іваніван

Біг make installзапускається /sbin/lilo, тому вам не потрібно було нічого оновлювати вручну (і це все ще може бути, якщо ви liloвстановили). Це може бути питанням думки, але я не пам’ятаю, щоб дуже радіти grub, навпаки. І lilo(принаймні, його версія 1999 року) може подвоїти вікна завантаження просто чудово, не потрібно loadlin.
mosvy

0

А перед LILO та GRUB вам довелося запустити його з командного рядка з якоюсь спеціальною утилітою завантажувача.

Як приклад, в Амізі був доступний Linux. Вам потрібно було використовувати утиліту командного рядка під назвою amiboot, щоб завантажити ELF ядра в пам'ять і перейти до нього.

Ось відео, хто використовує amiboot з командного рядка для запуску Linux на Amiga 600 . Його сценарій StartInstall викликає виконуваний файл amiboot. Ви можете дивитися налаштування пам’яті amiboot, визначати потрібну адресу завантаження та передавати параметри ядра приблизно в 0:55.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.