Wie geht Linux mit einer separaten / Boot-Partition um?

Ich bin daran interessiert zu erfahren, wie Linux mit separaten Boot-Partitionen umgeht. Ich bin nicht daran interessiert, dies tatsächlich zu tun, aber ich würde gerne wissen, wie dies unter der Haube funktioniert.

Stellen Sie sich eine Festplatte vor sda, die zwei Partitionen sda1und hat sda2. Angenommen, dies sda2ist die rootPartition, /die das Linux-Betriebssystem enthält.

Mein Verständnis ist, dass der Bootloader GRUB2montiert ist /boot. Wenn sich das Verzeichnis /bootjedoch auf einer separaten Partition sda2befindet, wie kann dies passieren, bevor /es tatsächlich bereitgestellt wird?

Wie läuft die Interaktion zwischen dem BIOS, dem Master-Boot-Datensatz und GRUB (oder den Dateien /boot) in diesem Fall erfolgreich ab? Ist es so, dass die Daten in diesem Stadium /bootnicht tatsächlich im /Dateisystem bereitgestellt werden?

Hinweis: Diese Frage befasst sich mit dem Mounten der Root-Partition, behandelt jedoch keine separate Boot-Partition.

Hier ist das Problem in Ihrem Verständnis:

Mein Verständnis ist, dass der Bootloader GRUB2 an / boot gemountet ist.

GRUB wird beim Booten nicht "gemountet". GRUB ist installiert auf /bootund wird geladen von Code in den Master Boot Record. Hier ist eine vereinfachte Übersicht über den modernen Startprozess unter der Annahme einer GNU / Linux-Distribution mit einem MBR / BIOS (nicht GPT / UEFI):

1. Das BIOS wird geladen.
2. Das BIOS lädt den kleinen Code, der sich im Master Boot Record befindet.
3. GRUB passt nicht in 440 Bytes, die Größe des Master Boot Record. Daher analysiert der geladene Code nur die Partitionstabelle, findet die /bootPartition (die meines Erachtens bestimmt wird, wenn Sie GRUB im Master Boot Record installieren) und analysiert die Dateisysteminformationen. Anschließend wird Stage 2 GRUB geladen. (Hier kommt die Vereinfachung ins Spiel.)
4. Stufe 2 GRUB lädt alles, was es benötigt, einschließlich der GRUB-Konfiguration, und zeigt dann ein Menü an (oder nicht, abhängig von der Benutzerkonfiguration).
5. Eine Startsequenz wird ausgewählt. Dies kann durch eine Zeitüberschreitung, durch die Auswahl eines Menüeintrags durch den Benutzer oder durch das Booten einer Befehlsliste geschehen.
6. Die Startsequenz wird ausgeführt. Dies kann eine Reihe von Dingen bewirken - zum Beispiel das Laden eines Kernels, das Laden einer Kette auf einen anderen Bootloader - aber nehmen wir an, dass die Bootsequenz Standard-GNU / Linux ist.
7. GRUB lädt den Linux-Kernel.
8. GRUB lädt die erste Ramdisk .
9. Die anfängliche Ramdisk wird /unter gemountet /new_root(möglicherweise kryptografisch entsperrt), startet udev, startet Resume-from-Swap usw.
10. Die anfängliche Ramdisk verwendet das pivot_rootDienstprogramm, um sie /new_rootals real festzulegen /.
11. initbeginnt. Partitionen werden gemountet, Daemons gestartet und das System gestartet.

Beachten Sie, dass der Kernel erst in Schritt 7 geladen wird. Aus diesem Grund gibt es bis Schritt 7 kein Konzept für das Mounten . Aus diesem Grund /bootmuss in Schritt 9 erneut gemountet werden, obwohl GRUB es bereits verwendet hat.

Es kann auch nützlich sein, den Abschnitt GRUB 2 auf der Wikipedia-Seite über GRUB zu lesen.

Frage 1

Mein Verständnis ist, dass der Bootloader GRUB2 an / boot gemountet ist. Wenn sich das Verzeichnis / boot jedoch auf einer separaten Partition sda2 befindet, wie kann dies passieren, bevor / tatsächlich gemountet wird?

Ich glaube nicht, dass Sie hier verstehen. Von der GNU GRUB Wikipedia-Seite :

Auszug

Wenn ein Computer eingeschaltet ist, findet das BIOS des Computers das konfigurierte primäre bootfähige Gerät (normalerweise die Festplatte des Computers) und lädt das anfängliche Bootstrap- Programm aus dem Master Boot Record (MBR) und führt es aus . Der MBR ist der erste Sektor der Festplatte und hat die Nummer 0 (die Sektorzählung beginnt bei 0). Lange Zeit betrug die Größe eines Sektors 512 Byte. Seit 2009 sind jedoch Festplatten mit einer Sektorgröße von 4096 Byte verfügbar, sogenannte Advanced Format- Festplatten. Ab Oktober 2013 wird auf solche Festplatten mithilfe der 512e-Emulation immer noch in 512-Byte-Sektoren zugegriffen .

In GRUB Version 2 findet folgendes statt:

Auszug

Computer starten

Beim Einschalten geschieht Folgendes:

• Die Hardware wird initialisiert, setzt die CPU in den Real-Modus (kein virtueller Speicher) und springt zum festen Speicherort 0xFFFF0 (fest verdrahtet in den CPU-Schaltkreisen).
• BIOS-Code, der in einem ROM oder Flash-Speicher gespeichert ist, der diesem Speicherort zugeordnet ist, wird daher ausgeführt.
• Der BIOS-Code überprüft die BIOS-Konfigurationsdaten, um festzustellen, welches das Startgerät ist. Diese BIOS-Konfigurationsdaten können normalerweise durch Drücken einer speziellen Tastenfolge unmittelbar nach dem Einschalten bearbeitet werden, wodurch das BIOS-Konfigurationsprogramm ausgeführt wird. Hier kann in der Regel unter anderem das Boot-Gerät ausgewählt werden.
• Der BIOS-Code lädt den MBR des Startgeräts in den RAM. Denken Sie daran, dass ein MBR nur 512 Bytes umfasst! Die geladenen Daten sind natürlich das Programm und die Daten, die grub-install dynamisch erstellt und dort geschrieben hat, als das grub-install-Programm ausgeführt wurde.
• Der BIOS-Code springt zur Startadresse des geladenen MBR (dh der Grub-Code wird zum ersten Mal seit dem Einschalten ausgeführt).
• Der MBR-Code von Grub lädt einen einzelnen Sektor, dessen Adresse fest mit dem MBR-Block verbunden ist. Anschließend werden die (Adress-, Len-) Paare in diesem Sektor durchlaufen und alle Daten von der Festplatte in den Speicher geladen (dh der Inhalt der Datei /boot/grub/core.imgoder ihre "eingebettete" Kopie wird geladen ). Der MBR-Code springt dann zum geladenen Code, dh er führt das Programm in aus core.img.
• Wie im Abschnitt „Installieren von Grub“ beschrieben, ermöglicht dieser Trick zum Einbetten der Blockadressen der unformatierten Festplatte das Speichern core.imgin einem Speicherplatz, der sich nicht in einer Partition befindet und der noch nie als Dateisystem formatiert wurde („Einbetten“). In diesem Fall muss core.imgder MBR-Code nicht aktualisiert werden, wenn er geändert wird, solange die neue Version am selben Speicherort „eingebettet“ ist.
• Alternativ ist es möglich, dass sich das core.imgin einem realen Dateisystem befindet und Grub den core.imgDateiinhalt liest, ohne einen Treiber für dieses Dateisystem zu haben. In diesem Fall kann core.imgdem ersten Block der Datei jedoch eine neue Adresse auf der Festplatte zugewiesen werden, wenn er geändert wird. In diesem Fall muss der MBR aktualisiert werden, um auf diesen neuen Speicherort zu verweisen. Wie core.imgnormalerweise durch Ausführen von grub-install aktualisiert, ist dies jedoch normalerweise kein Problem.
• Beachten Sie, dass theoretisch core.imgder von Grub generierte MBR-Datensatz die core.imgDatei möglicherweise nicht korrekt laden kann , wenn er sich auf einem anderen Gerät als dem MBR befindet und neue Hardware hinzugefügt wird . Die Geräte-ID, auf der sich der erste Sektor core.imgbefindet, ist fest mit dem MBR verbunden und wird nicht gesucht. Hierfür gibt es jedoch keine Lösung. Es gibt keine Möglichkeit, das Äquivalent des Grub-Suchbefehls in den 512-Byte-MBR einzubetten. Dieses Problem ist jedoch nicht wahrscheinlich. Normalerweise core.imgist das auf demselben Gerät wie der MBR eingebettet. Sobald core.imges geladen wurde, kann es search.mod verwenden, um alle weiteren /boot/grubDateien zu finden , und ist daher immun gegen Hardware-Neuanordnungen.
• Der ausgeführte core.imgCode initialisiert nun alle darin integrierten (verknüpften core.img) Module . Eines dieser Module ist ein Dateisystemtreiber, der das Dateisystem lesen kann, in dem sich das Verzeichnis befindet /boot/grub.
• Es registriert auch eine Reihe von integrierten Befehlen: set, unset, ls, insmod.
• Wenn eine „Konfigurationsdatei“ verknüpft wurde core.img, wird diese zur Verarbeitung an einen sehr einfachen integrierten Skriptparser übergeben. Skriptbefehle in der Konfigurationsdatei können nur integrierte oder verknüpfte Befehle aufrufen. Einfache Szenarien (z. B. Booten eines typischen Desktop-Computers von einem lokalen Laufwerk) erfordern keine Konfigurationsdatei. Diese Funktion wird zum Beispiel zum Booten über pxe, Remote-NFS oder /boot/grubauf einem LVM-Gerät verwendet.
• Core.imgLädt jetzt die Datei “/boot/grub/normal.mod”dynamisch von der Festplatte und springt zu ihrer Eingabefunktion. Beachten Sie, dass für diesen Schritt der entsprechende Dateisystemtreiber eingerichtet werden muss (dh integriert).

ANMERKUNG: Wenn Sie das typische GRUB2-Menü sehen, in dem Sie auswählen, welches Betriebssystem / welcher Kernel gestartet werden soll, verweisen Sie /boot/gruban dieser Stelle auf das Systemverzeichnis .

Verweise

• Starten von Linux unter x86 mit Grub2
• GNU GRUB - Wikipedia
• 6 Stufen des Linux-Bootprozesses (Startsequenz)
• Innerhalb des Linux-Startvorgangs
• Linux-Startvorgang
• GRUB 2 Bootloader - Vollständiges Tutorial - Dedoimedo

Linux (der Kernel) ist es egal, wie viele Boot-Partitionen Sie haben. Den Kernel von der Festplatte zu laden ist die Aufgabe des Bootloader (zB grub, grub2, lilo) und diese Tools auch über die Anzahl der Stellen ist es egal , ein Kernel befinden könnte. Sie kümmern sich nur um den spezifischen Ort.

Als Beispiel ist meine Boot-Partition /dev/md1ein MDADM-RAID-Spiegel, der von den physischen Partitionen /dev/sde1und unterstützt wird /dev/sdf1. Ich kann diese einzeln mounten, wenn ich wollte, und als solche zählt dies technisch als zwei Boot-Partitionen, obwohl sie die gleichen Daten enthalten sollten.

Zwei Partitionen für / boot für mich zu haben, ist ein Verfügbarkeitsproblem, aber es können auch unterschiedliche / boot-Partitionen sein. Der nächste Schritt ist, woher weiß der Bootloader? Hier ist, wie:

menuentry 'Linux 3.10.17 (sde) kernel-3.10.17-g' {
        root=hd0,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3
        initrd /boot/initrd-3.10.17-g
}

menuentry 'Linux 3.10.17 (sdf) kernel-3.10.17-g' {
        root=hd1,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3 
        initrd /boot/initrd-3.10.17-g
}

Dies ist ein Auszug aus einer grub2Konfiguration , und Sie werden bemerken , dass die einzigen Unterschiede sind root=hd0,1und aus root=hd1,1denen sich die Boot - Partition , dass Eintrag Referenzen.

Nun, um Sie durch einen Stiefel zu führen, damit Sie verstehen können, was hier vor sich geht.

• Das BIOS liest den MBR vom Boot-Volume und springt zum Bootloader
• Der Bootloader (z. B. grub2) ist so konfiguriert, dass er weiß, welches Gerät und welche Partition Ihren Kernel enthält. Grub2 greift direkt auf diese Partition zu und lädt Ihren Kernel in den Speicher.
• Ihr Bootloader springt dann in den Kernel und der Kernel bootet Ihren Computer.

Dem Bootloader ist es egal, wie viele Boot-Partitionen Sie haben, es ist nur wichtig, wo sie sich befinden, und Sie müssen ihm diese Informationen mitteilen.

Dem Kernel ist es egal, wie viele Boot-Partitionen Sie haben, da er sie nie sehen muss (Sie müssen sie nur zur Verfügung haben, um beispielsweise neue Kernel hinzuzufügen).