Wie hat Linux / xBSD vor GRUB gebootet?

23

Gemäß Wikipedia wurde GRUB 1995 veröffentlicht. Zu diesem Zeitpunkt existierten Linux und xBSD mehrere Jahre. Ich weiß, dass frühe Unix-Versionen in den 70er und 80er Jahren an Hardware gebunden waren, aber Linux und xBSD konnten kostenlos verteilt und installiert werden. Was wirft die Frage auf, wie Sie damals Linux booten würden? Wurden Distributionen mit eigenen Bootloader-Implementierungen ausgeliefert?

boot-loader history

— Sergiy Kolodyazhnyy
quelle

32

Ähm ... Sie waren nicht in der Nähe, als LILO der einzige Linux-Bootloader war? Und ich habe noch nie LILO oder Grub auf meinen BSD-Systemen verwendet. Für wen interessieren Sie sich? Siehe z biosboot(8).

— Kusalananda

8

@Kusalananda Leider interessierte mich Spielzeug und das Zeichnen von Ninja Turtles mehr als Pfeifen, Execs und Muscheln damals :) Ich interessiere mich für die allgemeine Geschichte, nicht für einen bestimmten Bootloader. Von der Seite, die du verlinkt hast, sehe ich, dass OpenBSD biosbootzwei Architekturen hat, i386 und amd64. Bedeutet das, dass OpenBSD speziell auf die Architekturen abzielen musste, anstatt ein einziges, vereinheitlichendes Tool zu haben?

— Sergiy Kolodyazhnyy

1

Der Bootloader der ersten Stufe ist für jede Architektur unterschiedlich (nur i386 und amd64 haben sowieso ein BIOS). Werfen Sie einen Blick auf NetBSD, wenn Sie an exotischeren Architekturen als dem Standard-PC interessiert sind.

— Kusalananda

3

@Kusalananda Ich glaube nicht, dass LILO jemals der einzige Linux-Bootloader war. Soweit ich weiß, ist der in Kernel-Images eingebaute Loader älter als LILO, und als die Unterstützung für den eingebauten Loader eingestellt wurde, gab es mindestens eine Handvoll anderer Bootloader.

— Kasperd

2

LILO war bis Anfang der 2000er Jahre der Standard-Bootloader für viele Distributionen

— phuclv

51

Die erste Linux-Distribution, die ich in den 90er Jahren verwendet habe ( Slackware 3.0IIRC), verwendete LILO als Bootloader. Und viele Distributionen, die LILOjahrelang benutzt wurden, selbst als GRUBsie zum "Standard" Bootloader wurden.

In den Anfangsjahren von Linux war es außerdem üblich, Linux von einem anderen Betriebssystem (z. B. DOS oder Windows) aus zu starten, anstatt sich auf einen Bootloader / Dual-Boot zu verlassen. Zum Beispiel gab es loadlin .

Vergessen Sie nicht Syslinux , einen einfacheren Bootloader, der häufig für selbststartende USB-Installations- / Wiederherstellungsdistributionen verwendet wird. Oder Isolinux (aus demselben Projekt), das von vielen "Live" -Distros verwendet wird.

Denken Sie daran, dass heutzutage GRUBviele Betriebssysteme geladen werden können, obwohl dies LILOeingeschränkter war und speziell auf Linux (dh LInux LOader) abzielte, mit einer gewissen Unterstützung für das Dual-Booten von Windows.
GRUBist aufgrund seiner vielen konfigurierbaren Optionen, Skriptfunktionen usw. sehr nützlich für Dual- / Multi-Boot.
Wenn Sie nur ein einziges Betriebssystem auf Ihrem Computer haben möchten, sollte dies "any" sein (dh welcher Bootloader auch immer der Standard für Ihre Linux / BSD-Distribution ist) reichen.

— Herr Shunz
quelle

5

@ MrShunz: Es gab damals keine UEFI. Das Booten von Windows war nur eine Frage des Hinzufügens eines Eintrags von zB other=/dev/hda1mit table=/dev/hdato lilo.conf, und lilo übertrug einfach die Kontrolle auf den Bootsektor bei hda1, da er wusste, dass sich die Partitionstabelle bei hda befinden würde.

— Ninjalj

2

Früher konnten Sie NTLDR dazu bringen, LILO zu laden. siehe jaeger.morpheus.net/linux/ntldr.php ; Ich habe das selbe selbständig entdeckt, damals.

— Roger Lipscombe

2

Der Nachteil des LILO-Ansatzes besteht darin, dass er kaputt geht, wenn sich der Speicherort der zu ladenden Dateien ändert. Dies bedeutet insbesondere, dass LILO nach jedem Kernel-Upgrade neu in den Boot-Speicherort (entweder MBR oder Partitions-Boot-Sektor) geschrieben werden musste.

— Plugwash

1

@plugwash: GRUB hat das gleiche Problem mit seiner Zweitstufendatei. Der Unterschied hier ist , dass 1) die „zweite Stufe“ von LILO war der Kern, so dass es Kernel - Updates war, nicht LILO Updates , die Dinge brachen; und 2) GRUB-Aktualisierungen beinhalten ein automatisches Neuschreiben des Speicherorts der zweiten Stufe in den MBR (wobei die zweite Stufe dann den Linux-Kernel lädt, wobei das Dateisystem vollständig bekannt ist, sodass der Speicherort des Kernels keine Rolle spielt). ;-)

— DevSolar

1

IIRC - Grub speichert nach Möglichkeit eine "Stufe 1.5", die das Dateisystem zwischen dem MBR und der ersten Partition versteht, und greift nur dann auf das Speichern eines Verweises auf bestimmte Dateisystemsektoren zurück, wenn für Stufe 1.5 kein Platz vorhanden ist (oder auf der es installiert wird) eine Partition Boot-Sektor anstelle des MBR)

— Plugwash

28

LILO war der De-facto-Standard für das Booten von Linux auf PCs, bevor Grub es schon sehr früh verwendete (MCC, eine der ersten Linux-Distributionen, verwendete es). Verschiedene andere Bootloader wurden gleichzeitig verwendet. Loadlin war ziemlich verbreitet; Es bootete Linux von DOS und wurde sogar in einigen Konfigurationen verwendet umsdos, um eine Linux-Umgebung in einem DOS-Dateisystem zu hosten. Eine andere übliche Konfiguration beinhaltete überhaupt keinen Bootloader: Der Kernel konnte sich selbst von einer Diskette booten, und die meisten Linux-Benutzer haben ein bekanntermaßen gutes Paar von Boot- und Root-Disketten aufbewahrt, von denen eine den Kernel und die andere ein grundlegendes Root-Dateisystem für Rettungszwecke enthält.

Es gab eine Reihe von Möglichkeiten, die Bootloader anderer Betriebssysteme auch zum Booten von Linux zu verwenden. Zum Beispiel der Boot-Manager von OS / 2 oder NTLDR von Windows NT.

Andere Systeme hatten ihre eigenen Bootloader:

SILO on SPARC (Sun Workstations und andere);
PALO auf PA-RISC (HP Workstations);
YaBoot und Quik auf PowerPC;
aBoot und MILO auf Alpha ...

Auch heutzutage ist Grub nicht der einzige Bootloader, den Sie sehen werden. Obwohl es nicht mehr sehr nützlich ist, den Kernel direkt von einer Diskette zu booten (ich habe nicht geprüft, ob dies noch möglich ist, vorausgesetzt, Sie können einen Kernel erstellen, der klein genug ist, um auf eine Diskette zu passen), kann er direkt von EFI booten (was effektiv der Fall ist) eigenes kleines Betriebssystem zum Laden anderer Betriebssysteme (wie Grub). Auf vielen kleineren Systemen (Embedded-Systemen, Single-Board-Computern ...) finden Sie U-Boot . (Und es gibt auch eine EFI-Ebene für U-Boot .)

— Stephen Kitt
quelle

Die PowerPC-Architektur ist auch deshalb interessant, weil einige Motherboards ein Turing-vollständiges BIOS - Openfirmware - hatten (im Grunde die Programmiersprache Forth mit einigen vorinstallierten Funktionen). Dies ermöglichte das Booten direkt vom BIOS ohne Bootloader, wenn Sie wissen, wie Sie Ihr BIOS konfigurieren

— slebetman

Hey, nur neugierig, NTLDR kann Linux-Kernel direkt laden? Ich habe gehört, dass NTLDR den Chainloader grub4dos und dann den Linux-Kernel laden kann.

— 8. Januar

@slebetman: Genauer gesagt, OpenFirmware wurde von Sun für SPARC entwickelt und dann von der PowerPC-Allianz (IBM, Apple, Motorola) für die PowerPC-Referenzarchitektur und speziell von Apple für PowerPC-basierte Macintoshs übernommen. Einer der mächtigen Aspekte war, dass einfache Treiber in ROM-Chips auf den Erweiterungskarten oder in einem bestimmten Boot-Bereich einer Festplatte gespeichert werden konnten und, da sie in Bytecode gegen eine bekannte festgelegte ABI geschrieben waren, unabhängig von der CPU funktionierten Architektur und Betriebssystem, die Sie starten wollten.

— Jörg W Mittag

Beispiel: Sie könnten einen RAID-Adapter haben, dessen OpenFirmware-Treiber sich in einem ROM-Chip befindet. Dann könnte die OpenFirmware-Umgebung diesen Treiber für den Zugriff auf das RAID verwenden. Innerhalb des RAID könnte es einen anderen Treiber für das Partitionstabellenformat geben, der die OFW-Umgebung zulässt Um die Partitionen zu finden, würde am Anfang jeder Partition ein OFW-Treiber für das Dateisystem stehen, der es dem OFW-System ermöglichen würde, den Kernel zu finden, und der Kernel würde am Anfang einen kleinen Bootloader in OFW-Bytecode schreiben.

— Jörg W Mittag

GRUB kann auf ähnliche Weise funktionieren, aber der Unterschied besteht darin, dass alle diese Treiber speziell für GRUB geschrieben werden müssen, wohingegen das Schöne an OFW war, dass das Gerät seine Treiber mitbrachte, was bedeutet, dass selbst Geräte, die dies noch nicht taten existierte, als die OFW-Umgebung geschrieben wurde, würde einfach "magisch" funktionieren. UEFI kann auch auf ähnliche Weise arbeiten, aber sein "portables Bytecode-Format" ist im Wesentlichen eine Teilmenge von DOS, was der Hauptgrund ist, warum Itaniums immer noch einen x86-Emulator benötigen.

— Jörg W Mittag

12

Bis zum mittleren 2.6-Kernel war der x86-Kernel direkt bootfähig, wenn er auf eine Diskette kopiert wurde (als wäre es ein Disketten-Image).

Dies war in der Tat die ursprüngliche Art, Linux zu booten.

Wenn Sie sich heute den Header eines x86-Kernels ansehen, sehen Sie eine Fehlermeldung, die besagt, dass das Booten von solchen Disketten nicht mehr funktioniert.

— Joshua
quelle

2

Andererseits kann der x86-Kernel jetzt direkt gebootet werden, wenn er einer UEFI-Firmware zugewiesen wird. Es gibt also immer noch einen Stub-Bootloader vor dem Kernel, nur einen anderen Typ ...

— Grawity

@grawity: Bist du sicher, dass du nicht x64 meinst?

— Joshua

1

@Joshua: Ich bin mir nicht sicher, was du damit meinst. EFI führt diesen Teil nicht als Code aus.

— Grawity

2

@ Joshua was? Es ist "DEC BP", "POP DX" im 16-Bit-Modus (EBP / EDX im 32-Bit-Modus). Aber es sollte sowieso nicht ausgeführt werden; EFI-Binärdateien sind PE-Dateien (was natürlich keine Rolle spielt, wenn sie in einen Bootsektor geschrieben werden ...).

— Stephen Kitt

1

@Joshua OK, aber das ist in meinen Augen kein undefiniertes x86-Verhalten ;-). (Ich stelle mir undefiniertes x86-Verhalten als Opcodes vor, deren Verhalten nicht definiert ist, nicht undefiniertes Plattformverhalten.)

— Stephen Kitt

5

Ich habe in den späten 90ern mit Linux angefangen und wie erwähnt lilowar das die Standardeinstellung. Wenn Sie mit einem DOS-System dual booten möchten, können Sie einen Bare-Boot durchführen, ohne etwas in HIMEM zu laden oder CD-Treiber usw. zu laden und zu verwenden loadlin. Für das doppelte Starten von Win95 können Sie das Laufwerk zuerst mit DOS bootfähig machen und dann '95 installieren. Mit dem Bootloader von '95 können Sie den DOS-Kernel immer noch booten und dann verwenden loadlin.

Für das Dual-Booten mit NT4 bestand der Trick darin, LILO auf die /Partition zu schreiben , dann die ersten 512 Bytes mit dd( dd if=/dev/sda2 of=/path/to/file bs=512 count=1) zu ntldrentfernen und die resultierende Datei dort abzulegen, wo sie angezeigt werden konnte, und sie vom WinNT-Bootloader zu verwenden. Das Problem dabei ist, dass Sie beim Upgrade Ihres Kernels alle Schritte wiederholen mussten, bevor Sie neu starten, da Sie sonst Probleme haben würden, wieder in das Linux-System zu gelangen. Gleicher Prozess arbeitete mit Win2k.

Mit LILO mussten Sie bei jeder Aktualisierung des Kernels daran denken, LILO zu aktualisieren.

Bei loadlinjeder Aktualisierung des Kernels mussten Sie daran denken, den Kernel auf die DOS-Partition zu kopieren.

Eine andere Option, auf die in anderen Antworten hingewiesen wird, war das direkte Schreiben des Kernels auf eine Diskette, dd if=/path/to/vmlinuz of=/dev/fd0ABER das Root-Gerät musste entweder zur Kompilierungszeit oder mithilfe des rdevDienstprogramms ordnungsgemäß im Kernel eingerichtet werden .

Als es dazu GRUBkam, gab es viel Freude, weil Sie nicht mehr daran denken mussten, LILO zu aktualisieren oder LILO zu aktualisieren und die Boot-Informationen usw. neu zu entfernen. Sie müssen nicht mehr von Ihrem Linux-System ausgeschlossen werden, weil Sie vergessen haben, den Bootloader zu aktualisieren Info...

— ivanivan
quelle

Hört sich so an, als ob es eine Menge Arbeit und eine große Chance gewesen wäre, mit einer nicht bootenden Maschine zurückgelassen zu werden, aber definitiv eine lehrreiche Erfahrung

— Sergiy Kolodyazhnyy

@SergiyKolodyazhnyy ja, und es gab nicht so viele Informationen im Internet, oder die großen Suchmaschinen, um es zu finden, wenn es da war. Es gab mehrere Rettungsdistributionen für einzelne Disketten, die gerade genug Linux hatten, um LILO usw. zu booten und zu reparieren. Wir haben einen langen Weg zurückgelegt!

— Ivanivan

Laufen make installwürde laufen /sbin/lilo, so dass Sie nicht wirklich etwas von Hand aktualisieren müssen (und das kann immer noch der Fall sein, wenn Sie liloinstalliert haben). Das mag Ansichtssache sein, aber ich erinnere mich nicht, dass ich mich grubim Gegenteil sehr darüber gefreut habe . Und lilo(zumindest seine 1999er Version) konnte Dual-Boot-Fenster ganz gut, nicht nötig loadlin.

— Mosvy

0

Vor LILO und GRUB mussten Sie es über die Befehlszeile mit einem benutzerdefinierten Bootloader-Dienstprogramm starten.

Als Beispiel hatte der Amiga Linux zur Verfügung. Sie mussten ein Befehlszeilenprogramm namens amiboot verwenden, um die Kernel-ELF in den Speicher zu laden und dorthin zu springen.

Hier ist ein Video von jemandem, der amiboot von der Kommandozeile aus verwendet, um Linux auf einem Amiga 600 zu starten . Sein StartInstall-Skript ruft die ausführbare Datei amiboot auf. Sie können beobachten, wie amiboot den Speicher konfiguriert, die gewünschte Ladeadresse ermittelt und die Parameter gegen 0:55 Uhr an den Kernel übergeben.

— BoredBsee
quelle