Wofür ist die / boot-Partition wirklich?

Ich lese einen relativ alten Text über Linux-Partitionen und Dateisysteme (die LPIC 1-Zertifizierungsbibel ). Es sagt:

Einige Versionen der Linux-Bootloader können nicht auf einen Kernel zugreifen, der sich außerhalb der ersten 1024 Zylinder auf einer Festplatte befindet. Wenn Sie die / boot-Partition an den Anfang des Laufwerks stellen, können Sie sicher sein, dass beim Booten des Kernels keine Probleme auftreten. Dieses Problem tritt am häufigsten beim Dual-Booten von Linux zusammen mit einem anderen Betriebssystem auf, das sich auf der ersten Partition befindet.

Warum hat ein Bootloader " keinen Zugriff auf den Kernel außerhalb der ersten 1024 Zylinder auf einer Festplatte "?

Was bedeutet es auch , die / boot-Partition am Anfang des Laufwerks zu platzieren ?

Dies ist eine Einschränkung, die dadurch entsteht, dass ein sehr altes BIOS und ein sehr alter Bootloader anstelle von Linux verwendet werden. Das BIOS würde nur in der Lage sein , die ersten 1024 Zylinder der Platte zuzugreifen (siehe hier , um weitere Informationen darüber , was Zylinder / Köpfe / Sektor). Diese Einschränkung würde sich auf Bootloader erstrecken, die aufgrund ihrer einfachen Art keine eigenen Festplattentreiber haben und die BIOS-Dienste für den Zugriff auf die Festplatte verwenden würden.

Dies bedeutete, dass sowohl der Bootloader als auch der Kernel (da es die Aufgabe des Bootloaders ist, ihn zu laden) sich auf Systemen mit dieser Einschränkung innerhalb der ersten 1024 Zylinder befinden müssten. Eine einfache Möglichkeit, dies zu tun, bestand darin, eine separate /bootPartition mit dem Kernel zu erstellen und an den Anfang des Laufwerks zu setzen (normalerweise nur, indem Sie die erste Partition festlegen). Dies bedeutet, dass es sich physisch in den ersten 1024 Zylindern befinden würde, vorausgesetzt natürlich, dass die Partition nicht zu groß ist.

Die Einschränkung ist kein Problem mehr, da sie nur für alte BIOS-Versionen gilt. Außerdem verfügen viele moderne Bootloader (z. B. GRUB) über eigene Festplattentreiber und müssen sich nicht auf BIOS-Dienste verlassen. Moderne Bootloader können /bootfür andere Zwecke verwendet werden, es ist jedoch nicht mehr erforderlich, dass sie sich sowohl auf einer separaten Partition als auch innerhalb der ersten 1024 Zylinder befinden (obwohl in vielen Fällen /booteine separate Partition erforderlich ist ).

Die Geschichte

/bootEnthält Dateien, die nicht vom Betriebssystem, sondern vom Bootloader verwendet werden . Sie finden sowohl Dateien des Bootloaders selbst (wie /boot/grub/*bei Grub) als auch des Linux-Kernels ( /boot/vmlinuz*) und häufig eine zugehörige initrd oder initramfs .

Auf einem PC mit Legacy-BIOS (im Gegensatz zu der neueren UEFI, die auf den neuesten Computern zu finden ist) lädt die Software im ROM die ersten 512 Bytes der Bootdiskette in den Speicher (den Bootsektor ). Mit nur 512 Bytes (von denen nicht alle Code enthalten: Ein Teil enthält Daten wie die Partitionstabelle) kann der Code nicht viel bewirken - es gibt keinen echten Festplattentreiber. Alles, was auf so begrenztem Raum getan werden kann, ist die Verwendung einer BIOS-Schnittstelle, um mehr Code zu laden. Diese Schnittstelle bietet einen Befehl zum Laden des N-ten Sektors auf der Festplatte - und die Größe von N ist begrenzt, sodass nur der Anfang der Festplatte auf diese Weise erreicht werden kann.

Die BIOS - Oberfläche hat sich in den letzten drei Jahrzehnten ein wenig weiterentwickelt , aber die Größenbeschränkungen haben Probleme damit, mit den Festplattengrößen Schritt zu halten, was dazu führte, dass ältere BIOS - und Bootloader mit 32 MB, 512 MB, 2 GB, 8 GB (und möglicherweise 8 GB) ausfielen andere Schwellen, an die ich mich nicht erinnere). Der Bootloader muss in der Lage sein, über die BIOS-Oberfläche alle Teile zu laden, die für den direkten Zugriff auf das Festplattenlaufwerk erforderlich sind. Bootloader enthalten in der Regel keine Treiber für alle Festplattencontroller in der Umgebung. Bis zum Laden des Linux-Kernels (und des initrd / initramfs) muss die BIOS-Schnittstelle verwendet werden und daher am Anfang der Festplatte passen.

Beachten Sie, dass dies eine Einschränkung des BIOS oder des Bootloaders ist, nicht von Linux selbst oder einer Distribution.

/bootHeute trennen

Auf einem System mit einem neueren BIOS und einem neueren Bootloader oder mit UEFI sind Größenbeschränkungen nicht mehr relevant: Die Festplattengrößen haben jetzt eine lange Zeit zum Aufholen. Es gibt jedoch auch andere Anwendungsfälle, die eine separate /bootPartition nützlich machen. Das Hauptsystem kann sich auf einem RAID-Gerät befinden , das der Bootloader nicht unterstützt, oder auf einem Dateisystemtyp, den der Bootloader nicht unterstützt. Damit kann sich das Hauptsystem auf einem verschlüsselten Gerät befinden, das von Linux entschlüsselt werden kann, jedoch nicht vom Bootloader.

Wenn keine dieser Einschränkungen und Anwendungsfälle auf Sie zutrifft, /bootist es nicht sinnvoll , eine separate Partition zu erstellen. Aber sie betreffen genug Menschen, die von der meisten Distribution unterstützt werden.

Ein weiterer Grund neben dem erwähnten BIOS-Problem ist, dass eine separate /bootPartition die Verwendung eines Dateisystems für das /Volume ermöglicht, das der Bootloader nicht versteht (ohne auf das Laden von Blocklisten wie bei beschränkt zu sein lilo).

Booten ist hart

Booten ... na ja ... es ist wirklich der schwierigste Teil. Jedes Mal, wenn ein Computer hochfährt, trifft er sich im Grunde genommen neu. Es macht sich mit seinen verschiedenen Teilen vertraut, und für jedes, dem es begegnet, gewinnt es an Fähigkeit. Aber es muss sich jedes Mal sozusagen von selbst an den Bootstraps hochziehen.

Beim Entwerfen eines Startvorgangs besteht der Trick darin, die Maschine schrittweise hochzufahren. Ihr Boot muss schnell und zuverlässig sein, und es muss jedes Mal beides in einer völlig unbekannten Umgebung sein . Ich werde mich nicht einmal in ein Gespräch im Real / Protected-Modus wagen (was nicht einmal heißen soll, dass ich es könnte) , aber beim Booten ist eine Menge los. Wenn der Computer die verschiedenen Komponenten jedes Mal in abgestuften Schritten aufnimmt. Das wahrscheinlich wichtigste ist der Übergang von der Ausführung von On-Board-Code zur Ausführung von On-Disk-Code, oder mit anderen Worten: der Kernel-Exec. Dies ist der Zeitpunkt, an dem sich die Firmware (angeblich) dem Betriebssystem unterwirft.

Vor vielen Jahren war dies nicht so sehr der Fall. Früher war das BIOS wirklich das Basic In / Out - normale Programme riefen die Firmware auf, um beispielsweise den Bildschirm zu zeichnen und auf die Festplatte zuzugreifen. Diese wurden als Interrupts bezeichnet - alte Hüte erinnern sich vielleicht am besten an sie, weil sie sich über die Zuweisung von IRQs für ihre neue Punktmatrix oder USR freuten.

INT13H

Dies ist die 13H- Funktionsserie des Interrupts ( oder INTin der Assemblysprache ) , die das BIOS als Dienste für den Datenträgerzugriff anbietet. Diese werden auch heute noch für BIOS-Systeme im Bootprozess verwendet, um den Sprung von der Firmware auf die Festplatte zu schaffen.

Ein BIOS-System überprüft die ersten Bytes jeder gefundenen Festplatte und sucht nach einem Muster, das es als Master Boot Record ( oderMBR ) erkennt . Dies ist ein jahrzehntealter De-facto-Standard, der ein Stück rohe, ausführbare Binärdatei enthält, die auf den Kopf der Festplatte geschrieben wird. Der MBR kennzeichnet eine BIOS-Diskette als bootfähig. Es hört auf zu prüfen, wenn es eines findet, und so ist praktisch eines alles, was Sie ohne clevere Tricks bekommen. Wenn es eines findet, ordnet es es dem Speicher zu und führt es aus (im Real-Modus, aber ich gehe immer noch nicht dorthin) .

Der ausgeführte MBR ist mit ziemlicher Sicherheit nicht Ihr Systemkern - 512 Bytes (Geben oder Nehmen) wären in dieser Abteilung ziemlich nutzlos. Dies ist wahrscheinlich ein Bootloader - ein Programm, das speziell entwickelt wurde, um eine der vielen Adressierungsbeschränkungen des BIOS zu überwinden - insbesondere, dass es überhaupt kein Dateisystem versteht.

Wenn der Bootloader im eigentlichen Kernel liest und führt sie im Speicher (wie wir alle beten , es jedes Mal so will) , wird es wahrscheinlich tun, indem Sie das BIOS über eine fragen INT13HInterruptaufrufen. Und wenn dies nicht der Fall ist - viele anspruchsvollere Bootloader werden Dateisysteme im herkömmlichen Sinne mounten und den Code auf eine andere Weise ausführen -, ist es sehr unwahrscheinlich, dass der Bootloader ohne ein INT13Hoder zwei so ausgefallen ist . Oft müssen Bootloader sich selbst oder in verschiedenen Phasen hintereinander laden, da die zuerst zugewiesenen 512 Byte nicht einmal ihren Anforderungen entsprechen.

HUHN UND EI

All dies ist meines Wissens ein Umweg über die Diskette, aber zu diesem Zeitpunkt sollte klar sein, dass das Hauptproblem - man könnte es als Henne-Ei- Typ bezeichnen - darin besteht, auf die Diskette zuzugreifen, die die Programmanweisungen enthält etwa , wie man Zugang Scheiben . Der Schlüssel zu diesem Problem liegt in der Firmware - und dies ist auch auf EFI-Systemen nach wie vor sehr unterschiedlich - und die Firmware ist das wichtigste Glied in der Boot-Kette.

Sobald der Kernel ausgeführt wird und all seine unzähligen Routinen für den Zugriff auf und die Steuerung der Hardware ausgelöst werden, verschwinden diese Probleme (oder ändern sich zumindest etwas) , da moderne Betriebssysteme die vollständige Kontrolle über ein System übernehmen. Bis dahin reichen die Systemgrenzen jedoch nur so weit, wie es die Firmware zulässt. Dies sagt viel aus - das BIOS hat sich seit dem INT13H8086 nicht wesentlich verändert. Der Aufruf ist ein 8086-Original. Ja, es gab (unzählige) Erweiterungen und Hacks, aber Neuerungen ...?

BESSER UND BESSER

Die meisten Änderungen am BIOS waren bestenfalls Verbände. Früher musste eine Festplatte physisch zugeordnet werden. Verschiedene und spezifische Aspekte ihrer Geometrie wurden beim Speichern oder Abrufen von Daten berücksichtigt. Schließlich wuchs die konventionelle Festplatte auf eine Größe, die dies verbot. Selbst die abstrakte Karte enthielt zu viele Informationen, als dass ein BIOS sie verarbeiten könnte. Da es nur im Real-Modus betrieben werden kann, ist das BIOS auf 1 MB pro Speicherregister beschränkt. Schwellen Sie die Zylinderkarte an oder machen Sie eine der Eigenschaften größer, als in so vielen Bits adressiert werden kann, und das BIOS geht buchstäblich verloren.

Diese Barriere wurde viele Male erreicht und durchbrochen . Jedes Mal, wenn die Karte in einer neueren, cleveren und weniger genauen Weise abstrahiert und kodiert wurde. Und so ist es heutzutage für ein BIOS buchstäblich unmöglich, ein Laufwerk genau zuzuordnen. Die logische Blockadressierung ist derzeit der De-facto-Standard, obwohl noch einige Übersetzungen für Zylinder / Kopf / Sektor (oder CHS) erforderlich sind. Was die Mainboard-Firmware an Genauigkeit / Verantwortung verloren hat, wurden solche Erweiterungen abstrahiert und zu den Verantwortlichkeiten für die Festplatten-Firmware hinzugefügt, um die Lücken zu füllen.

Auf dieses Katz-und-Maus-Spiel wird in Ihrer Frage verwiesen. Wenn das BIOS eine Festplatte aufgrund ihrer Größe über einen bestimmten Punkt hinaus nicht versteht, sollten alle Daten, die Sie möglicherweise beim Booten abrufen möchten, wie z. B. ein Bootloader oder ein Kernel, nicht über diesen Punkt hinaus gefunden werden. Dies ist, woher /bootkam.

Vielleicht sogar besser

Heutzutage sind solche Dinge glücklicherweise durch den Untergang des BIOS irrelevant geworden. Es dauerte 30 Jahre, wurde aber in den letzten Jahren weitgehend durch den UEFI- Standard (oder EFI 2.0- Standard) ersetzt. UEFI bietet einen Ladevorgang von der ersten Minute an, wird im geschützten Modus initialisiert, enthält einen eigenen Bootloader, bietet einen für den Neustart beständigen Speicher für Flash-Speichervariablen, ist für die Verarbeitung von mehreren Zetabyte oder was auch immer pro Festplatte vorgesehen ... und vieles mehr sonst. Es ist alles andere als perfekt, aber es ist eine enorme Verbesserung gegenüber dem Vorgänger.

Selbst Argumente für spezialisierte Bootloader mit Festplattenverschlüsselung oder geschichteten Dateisystemen fallen ins Stocken, wenn Sie bedenken, dass all diese vom Betriebssystemkern verarbeitet werden müssen, und wenn Sie beim Booten einen Mount erhalten , haben Sie immer ein klares Verständnis. Ein Schuss für die Ausführung (vor allem, wenn man bedenkt, dass der Linux-Kernel in seiner Standardkonfiguration eine eigenständige EFI-ausführbare Datei ist) .

Eine separate /bootPartition sollte Sie also wahrscheinlich nicht übermäßig beschäftigen, und wenn Sie sich auf einem EFI-System befinden, haben Sie wahrscheinlich ohnehin bereits eine analoge Partition in der EFI-System-Partition, da dies eine Voraussetzung für den Start des EFI-Modus ist.

Dass es ein /bootVerzeichnis gibt, ist historisch festgelegt und von dort im Filesystem Hierarchy Standard "fixiert" . Mit einem solchen Standard können Programme (und Systemadministratoren) bestimmte Dateien an bestimmten Speicherorten erwarten. In diesem Fall die Dateien, die dem Startvorgang zugeordnet sind.

Eine /bootPartition am Anfang einer Disc zu haben, machte Sinn für ältere BIOS, die nicht in der Lage waren, Blöcke / Sektoren im gesamten Bereich der verfügbaren Laufwerke zu indizieren. Aus diesem Grund sollten sich die zu ladenden Informationen auf einem Sektor befinden, der indiziert werden kann, und daher eine separate Partition (mit niedrigen Sektornummern), /bootvon der das BIOS zusätzliche Daten / Programme laden kann (die wiederum in der Lage sind, den gesamten Inhalt zu adressieren) Disc-Bereich ohne Verwendung des BIOS).

Es kann auch sehr ordentlich sein, eine separate / boot-Partition zu haben. Auf meinem Computer habe ich viele Distributionen und Backups, jede in einer eigenen Partition, aber alle haben dieselbe / boot-Partition, auf der sich alle Kernel für alle Betriebssysteme befinden. Außerdem verweisen alle Distributionen auf meine einzige Kopie von lilo.conf, die sich ebenfalls in / boot befindet, sodass ich nie raten muss, was zum Teufel los ist, wenn ich Kernel oder Distributionen hinzufüge. Hier ist ein Ausschnitt aus meiner lilo.conf:

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y5--5-Debian1"
label  = y5:D1:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y8--5-Debian2"
label  = y8:D2:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y11-5-Debian3"
label  = y11:D3:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=w5--5-Debian1"
label  = w5:D1:16.0-4

... das sind nur meine Debian-Backups auf zwei Festplatten. Sehen Sie, wie einfach es ist, den Überblick über die Kernel zu behalten? (Im Moment verwenden alle Backups denselben Kernel).

Obwohl auf modernen Systemen auf die Sektoren einer Datei überall auf einer Festplatte zugegriffen werden kann, ist es immer noch sinnvoll, Startmaterialien auf ihre eigene Startpartition zu beschränken, und zwar einfach nach dem Prinzip "nicht alle Eier in einen Korb legen".

Angenommen, das Hauptdateisystem ist derart beschädigt, dass ein Bootloader der unteren Stufe die nächste Stufe nicht richtig lesen kann. Befinden sich die Bootloader-Materialien stattdessen in einer eigenen Partition, kann der Kernel die beschädigte Root-Partition über fsck ordnungsgemäß verarbeiten. Das kann sich in einer eigenen Partition befinden.

Die Boot-Partition kann Ihnen Optionen für "Rettung" geben, wie das Mounten einer alternativen Root-Partition. Was ist auch, wenn Sie verschiedene Betriebssysteme in verschiedenen Partitionen mehrfach booten? Dann gehören die Boot-Materialien zu keinem dieser Systeme. Es ist vernünftig, eine eigene Partition zu haben. Möglicherweise ersetzen Sie eine der Betriebssystempartitionen durch ein anderes Betriebssystem, können jedoch die verbleibenden Betriebssysteme booten.

Was ist auch, wenn Sie ein Dateisystem für Ihre Hauptpartition verwenden möchten, das der Bootloader überhaupt nicht versteht? Oder sagen wir mal, für welche die bootloaderseitige Unterstützung nur experimentell ist? In solchen Situationen kann eine Boot-Time-Datei weiterhin verwendet werden, wenn eine Sektorkarte vorhanden ist (und der Bootloader unterstützt so etwas: Der gute alte Linux-Bootloader LILO verwendete Sektorkarten und musste das Dateisystem nicht verstehen Struktur überhaupt). Aber Sektorkarten sind von Natur aus schuppig. Wenn das Dateisystem neu organisiert wird, werden die Sektoren verschoben, sodass die Sektorkarten falsch werden und neu generiert werden müssen. Andernfalls kann das System nicht neu gestartet werden.

Schließlich gibt es das Organisationsprinzip, dass, selbst wenn Sie keine tatsächliche Partition haben, es immer noch eine gute Idee ist, dass sich das gesamte Boot-Zeug zumindest darunter /bootbefindet und nirgendwo anders verstreut ist.

Dies war keine Einschränkung der Linux-Distribution, sondern eine Einschränkung älterer BIOS. Um zu gewährleisten, dass Linux booten konnte, wurden damals alle bootbezogenen Dateien in einer eigenen Partition abgelegt, die zur ersten Partition auf der Festplatte gemacht wurde, um sicherzustellen, dass der Bootloader in die ersten 1024 Zylinder fiel. Erstellen Sie eine Partition, die kleiner ist als die Größe von 1024 Zylindern (von Festplatte zu Festplatte unterschiedlich). Wenn Sie jedoch eine erste Partition erstellen, die größer als diese Grenze ist, besteht die Möglichkeit, dass sich die Bootloader-Dateien außerhalb von 1024 Zylindern befinden und das BIOS sie nicht laden kann.

Sie können den gleichen Effekt auch erzielen, indem Sie zwei kleine Partitionen erstellen, die beide in den ersten 1024 Zylindern liegen, und alle Bootloader-Dateien auf die zweite setzen.

Ein weiterer Grund für die Bootpartition in diesen Tagen sind:

• Booten von NFS oder NBD
• verschlüsselte Root-Partition
• / boot geteilt zwischen verschiedenen Distributionen