13.2. FreeBSDs Bootvorgang

Wenn der Computer eingeschaltet wird und das Betriebssystem gestartet werden soll, entsteht ein interessantes Dilemma, denn der Computer weiß per Definition nicht, wie er irgendetwas tut, bis das Betriebssystem gestartet wurde. Das schließt das Starten von Programmen, die sich auf der Festplatte befinden, ein. Wenn der Computer kein Programm von der Festplatte starten kann, sich das Betriebssystem aber genau dort befindet, wie wird es dann gestartet?

Dieses Problem ähnelt einer Geschichte des Barons von Münchhausen. Dort war eine Person in einen Sumpf gefallen und hat sich selbst an den Riemen seiner Stiefel (engl. bootstrap) herausgezogen. In den jungen Jahren des Computerzeitalters wurde mit dem Begriff Bootstrap dann die Technik das Betriebssystem zu laden bezeichnet und wurde hinterher mit booten abgekürzt.

Auf x86-Plattformen ist das Basic Input/Output System (BIOS) dafür verantwortlich, das Betriebssystem zu laden. Das BIOS liest den Master Boot Record (MBR) aus, der sich an einer bestimmten Stelle auf der Festplatte befinden muss. Das BIOS kann den MBR selbstständig laden und ausführen und geht davon aus, dass dieser die restlichen Dinge, die für das Laden des Betriebssystems notwendig sind, selbst oder mit Hilfe des BIOS erledigen kann.

Anmerkung:

FreeBSD ermöglicht das Booten sowohl über den alten MBR-Standard, als auch über die neuere GUID-Partitionstabelle (GPT). GPT-Partitionen finden sich häufig auf Systemen mit dem Unified Extensible Extensible Firmware Interface (UEFI). FreeBSD kann allerdings mit Hilfe von gptboot(8) auch GPT-Partitionen über das alte BIOS booten. An der Unterstützung für ein direktes Booten über UEFI wird derzeit gearbeitet.

Der Code innerhalb des MBRs wird für gewöhnlich als Boot-Manager bezeichnet, insbesondere, wenn eine Interaktion mit dem Anwender stattfindet. Der Boot-Manager verwaltet zusätzlichen Code im ersten Track der Platte oder des Dateisystems. Zu den bekanntesten Boot-Managern gehören boot0, der auch als Boot Easy bekannte Standard-Boot-Manager von FreeBSD, sowie Grub, welches in vielen Linux®-Distributionen verwendet wird.

Falls nur ein Betriebssystem installiert ist, sucht der MBR nach dem ersten bootbaren Slice (das dabei als active gekennzeichnet ist) auf dem Laufwerk und führt den dort vorhandenen Code aus, um das restliche Betriebssystem zu laden. Falls mehrere Betriebssysteme installiert sind, kann ein anderer Boot-Manager installiert werden, der eine Liste der verfügbaren Betriebssysteme anzeigt, so dass der Benutzer wählen kann, welches Betriebssystem er booten möchte.

Das restliche FreeBSD-Bootstrap-System ist in drei Phasen unterteilt. Die erste Phase besitzt gerade genug Funktionalität um den Computer in einen bestimmten Status zu verhelfen und die zweite Phase zu starten. Die zweite Phase führt ein wenig mehr Operationen durch und startet schließlich die dritte Phase, die das Laden des Betriebssystems abschließt. Der ganze Prozess wird in drei Phasen durchgeführt, weil der MBR die Größe der Programme, die in Phase eins und zwei ausgeführt werden, limitiert. Das Verketten der durchzuführenden Aufgaben ermöglicht es FreeBSD, ein sehr flexibles Ladeprogramm zu besitzen.

Als nächstes wird der Kernel gestartet, der zunächst nach Geräten sucht und sie für den Gebrauch initialisiert. Nach dem Booten des Kernels übergibt dieser die Kontrolle an den Benutzer Prozess init(8), der erst sicherstellt, dass alle Laufwerke benutzbar sind und die Ressourcen Konfiguration auf Benutzer Ebene startet. Diese wiederum mountet Dateisysteme, macht die Netzwerkkarten für die Kommunikation mit dem Netzwerk bereit und startet alle Prozesse, die konfiguriert wurden, um beim Hochfahren gestartet zu werden.

Dieser Abschnitt beschreibt die einzelnen Phasen und wie sie mit dem FreeBSD-Bootvorgang interagieren.

13.2.1. Der Boot-Manager

Der Code im MBR oder im Boot-Manager wird manchmal auch als stage zero des Boot-Prozesses bezeichnet. Dieser Abschnitt beschreibt zwei Boot-Manager: boot0 und LILO.

Der boot0 Boot-Manager: Der vom FreeBSD-Installationsprogramm oder boot0cfg(8) in der Voreinstelung installierte MBR basiert auf /boot/boot0. Die Größe und Leistungsfähigkeit von boot0 ist auf 446 Bytes beschränkt, weil der restliche Platz für die Partitionstabelle sowie den 0x55AA-Identifier am Ende des MBRs benötigt wird. Wenn boot0 und mehrere Betriebssysteme installiert sind, wird beim Starten des Computers eine Anzeige ähnlich der folgenden zu sehen sein:

Beispiel 13.1. boot0-Screenshot
F1 Win
F2 FreeBSD

Default: F2

Diverse Betriebssysteme, insbesondere Windows®, überschreiben den existierenden MBR, wenn sie nach FreeBSD installiert werden. Falls dies passiert, kann mit folgendem Kommando der momentane MBR durch den FreeBSD-MBR ersetzt werden:

# fdisk -B -b /boot/boot0 Gerät

Bei Gerät handelt es sich um das Gerät, von dem gebootet wird, also beispielsweise ad0 für die erste IDE-Festplatte, ad2 für die erste IDE-Festplatte am zweiten IDE-Controller, da0 für die erste SCSI-Festplatte. Um eine angepasste Konfiguration des MBR zu erstellen, lesen Sie boot0cfg(8).

Der LILO-Boot-Manager: Damit dieser Boot-Manager auch FreeBSD booten kann, starten Sie zuerst Linux und fügen danach folgende Zeilen in die Konfigurationsdatei /etc/lilo.conf ein:

other=/dev/hdXY
table=/dev/hdX
loader=/boot/chain.b
label=FreeBSD

Dabei muss die primäre Partition von FreeBSD sowie dessen Platte im Linux-Format angeben werden. Dazu wird X durch die Linux-Bezeichnung der Platte und Y durch die von Linux verwendete Partitionsnummer ersetzt. Für ein SCSI-Laufwerk wird /dev/sd anstelle von /dev/hd verwendet. Die Zeile loader=/boot/chain.b kann weggelassen werden, wenn beide Betriebssysteme auf der gleichen Platte installiert sind. Geben Sie danach /sbin/lilo -v ein, um die Änderungen zu übernehmen. Achten Sie dabei besonders auf etwaige Fehlermeldungen.

13.2.2. Phase Eins und Phase Zwei

Im Prinzip sind die erste und die zweite Phase Teile desselben Programms, im selben Bereich auf der Festplatte. Aufgrund von Speicherplatz-Beschränkungen wurden sie in zwei Teile aufgeteilt, welche jedoch immer zusammen installiert werden. Beide werden entweder vom Installer oder von bsdlabel(8) aus der kombinierten /boot/boot kopiert.

Beide Phasen befinden sich außerhalb des Dateisystems im Bootsektor des Boot-Slices, wo boot0 (Abschnitt 13.2.1, „Der Boot-Manager“) oder ein anderer Boot-Manager ein Programm erwarten, das den weiteren Bootvorgang durchführen kann. Die Anzahl der dabei verwendeten Sektoren wird durch die Größe von /boot/boot bestimmt.

boot1 ist ein sehr einfaches Programm, da es nur 512 Bytes groß sein darf, und es besitzt gerade genug Funktionalität, um FreeBSDs bsdlabel, das Informationen über den Slice enthält, auszulesen, und um boot2 zu finden und auszuführen.

boot2 ist schon ein wenig umfangreicher und besitzt genügend Funktionalität, um Dateien in FreeBSDs Dateisystem zu finden. Außerdem hat es eine einfache Schnittstelle, die es ermöglicht, den zu ladenden Kernel oder Loader auszuwählen.

Da der loader(8) einen weitaus größeren Funktionsumfang hat und eine einfach zu bedienende Boot-Konfigurations-Schnittstelle zur Verfügung stellt, wird er gewöhnlich von boot2 gestartet.

Beispiel 13.2. boot2-Screenshot
>> FreeBSD/i386 BOOT
Default: 0:ad(0,a)/boot/loader
boot:

bsdlabel(8) kann dazu verwendet werden, dass installierte boot1 und boot2 zu ersetzen:

# bsdlabel -B diskslice

Wobei diskslice das Laufwerk und die Slice darstellt, von dem gebootet wird, beispielsweise ad0s1 für die erste Slice auf der ersten IDE-Festplatte.

Dangerously Dedicated Mode:

Wenn man nur den Festplatten-Namen, also z.B. ad0 benutzt, wird bsdlabel(8) eine "dangerously dedicated disk" erstellen, ohne Slices. Das ist ein Zustand, den man meistens nicht hervorrufen möchte. Aus diesem Grund sollte man das diskslice von bsdlabel(8) noch einmal prüfen, bevor Return gedrückt wird.

13.2.3. Phase Drei

Der boot-loader ist der letzte von drei Schritten im Bootstrap-Prozess und kann im Dateisystem normalerweise unter /boot/loader gefunden werden.

Der Loader soll eine interaktive Konfigurations-Schnittstelle mit eingebauten Befehlssatz sein, ergänzt durch einen umfangreichen Interpreter mit einem komplexeren Befehlssatz.

Der Loader sucht während seiner Initialisierung nach Konsolen und Laufwerken, findet heraus, von welchem Laufwerk er gerade bootet, und setzt dementsprechend bestimmte Variablen. Dann wird ein Interpreter gestartet, der Befehle interaktiv oder von einem Skript empfangen kann.

Danach liest der Loader die Datei /boot/loader.rc aus, welche ihn standardmäßig anweist /boot/defaults/loader.conf zu lesen, wo sinnvolle Standardeinstellungen für diverse Variablen festgelegt werden und wiederum /boot/loader.conf für lokale Änderungen an diesen Variablen ausgelesen wird. Anschließend arbeitet dann loader.rc entsprechend dieser Variablen und lädt die ausgewählten Module und den gewünschten Kernel.

In der Voreinstellung wartet der Loader 10 Sekunden lang auf eine Tastatureingabe und bootet den Kernel, falls keine Taste betätigt wurde. Falls doch eine Taste betätigt wurde wird dem Benutzer eine Eingabeaufforderung angezeigt. Sie nimmt einen Befehlssatz entgegen, der es dem Benutzer erlaubt, Änderungen an Variablen vorzunehmen, Module zu laden, alle Module zu entladen oder schließlich zu booten bzw. neu zu booten.

13.2.3.1. Die eingebauten Befehle des Loaders

Dies sind nur die gebräuchlichsten Befehle. Eine vollständige Beschreibung aller verfügbaren Befehle finden Sie in loader(8).

autoboot Sekunden

Es wird mit dem Booten des Kernels fortgefahren, falls keine Taste in der gegebenen Zeitspanne betätigt wurde. In der gegebenen Zeitspanne, Vorgabe sind 10 Sekunden, wird ein Countdown angezeigt.

boot [-options] [Kernelname]

Bewirkt das sofortige Booten des Kernels mit allen gegebenen Optionen, oder dem angegebenen Kernelnamen. Das übergeben eines Kernelnamens ist nur nach einem unload-Befehl anwendbar, andernfalls wird der zuvor verwendete Kernel benutzt.

boot-conf

Bewirkt die automatische Konfiguration der Module, abhängig von den entsprechenden Variablen (üblicherweise kernel). Dies nur dann sinnvoll, wenn zuvor unload benutzt wurde.

help [Thema]

Zeigt die Hilfe an, die zuvor aus der Datei /boot/loader.help gelesen wird. Falls index als Thema angegeben wird, wird die Liste der zur Verfügung stehenden Hilfe-Themen angezeigt.

include Dateiname

Verarbeitet die angegebene Datei. Das Einlesen und Interpretieren geschieht Zeile für Zeile und wird im Falle eines Fehlers umgehend unterbrochen.

load [-t Typ] Dateiname

Lädt den Kernel, das Kernel-Modul, oder die Datei des angegebenen Typs. Optionen, die auf Dateinamen folgen, werden der Datei übergeben.

ls [-l] [Pfad]

Listet die Dateien im angegebenen Pfad auf, oder das root-Verzeichnis(/), falls kein Pfad angegeben wurde. Die Option -l bewirkt, dass die Dateigrößen ebenfalls angezeigt werden.

lsdev [-v]

Listet alle Geräte auf, für die Module geladen werden können. Die Option -v bewirkt eine detailreichere Ausgabe.

lsmod [-v]

Listet alle geladenen Module auf. Die Option -v bewirkt eine detailreichere Ausgabe.

more Dateiname

Zeigt den Dateinhalt der angegebenen Datei an, wobei eine Pause alle LINES Zeilen gemacht wird.

reboot

Bewirkt einen umgehenden Neustart des Systems.

set Variable, set Variable=Wert

Setzt die Umgebungsvariablen des Loaders.

unload

Entlädt sämtliche geladenen Module.

13.2.3.2. Beispiele für die Loader Bedienung

Hier ein paar praktische Beispiele für die Bedienung des Loaders.

  • Um den gewöhnlichen Kernel im Single-User Modus zu starten:

    boot -s
  • Um alle gewöhnlichen Kernelmodule zu entladen und dann den alten, oder einen anderen Kernel zu laden:

    unload
    load kernel.old

    Verwenden Sie kernel.GENERIC, um den allgemeinen Kernel zu bezeichnen, der vorinstalliert wird. kernel.old bezeichnet den Kernel, der vor dem System-Upgrade installiert war.

    Anmerkung:

    Der folgende Befehl lädt die gewöhnlichen Module mit einem anderen Kernel:

    unload
    set kernel="kernel.old"
    boot-conf
  • Folgendes lädt ein Kernelkonfigurations-Skript (ein automatisiertes Skript, dass dasselbe tut, was der Benutzer normalerweise von Hand an der Eingabeaufforderung durchführen würde):

    load -t userconfig_script /boot/kernel.conf

13.2.4. Interaktion mit dem Kernel während des Bootens

Wenn der Kernel einmal geladen ist, entweder durch den Loader oder durch boot2, welches den Loader umgeht, dann überprüft er vorhandene Boot-Flags und passt sein Verhalten nach Bedarf an.

Es folgt eine Auflistung der gebräuchlichsten Boot-Flags:

-a

Bewirkt, dass während der Kernel-Initialisierung gefragt wird, welches Gerät als Root-Dateisystem eingehängt werden soll.

-C

Es wird von CD-ROM gebootet.

-c

Startet UserConfig, das Boot-Zeit Konfigurationsprogramm.

-s

Bewirkt den Start des Single-User Modus.

-v

Zeigt mehr Informationen während des Starten des Kernels an.

Anmerkung:

Informationen zu den anderen Boot-Flags finden Sie in boot(8).

Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an <de-bsd-questions@de.FreeBSD.org>.

Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.