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. Seither wurde es 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.
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 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. Wenn 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.
Der Boot-Manager Code im MBR wird manchmal auch als stage zero des Boot-Prozesses bezeichnet. In der Voreinstellung verwendet FreeBSD den boot0 Boot-Manager.
Der vom FreeBSD-Installationsprogramm 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:
Diverse Betriebssysteme ü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).
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 FreeBSD-Installationsprogramm
oder bsdlabel
aus der kombinierten
/boot/boot
kopiert.
Beide Phasen befinden sich außerhalb des Dateisystems im Bootsektor des Boot-Slices, wo boot0 oder ein anderer Boot-Manager ein Programm erwarten, das den weiteren Bootvorgang durchführen kann.
Die erste Phase, boot1
, ist ein sehr
einfaches Programm, da es nur 512 Bytes groß sein darf.
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.
Die zweite Phase, boot2
, ist schon
ein wenig umfangreicher und besitzt genügend Funktionalität,
um Dateien in FreeBSDs Dateisystem zu finden. Es kann eine
einfache Schnittstelle bereitstellen, die es ermöglicht, den
zu ladenden Kernel oder Loader auszuwählen. Es lädt den
loader, der einen weitaus größeren
Funktionsumfang bietet und eine Konfigurationsdatei zur
Verfügung stellt. Wenn der Boot-Prozess während der zweiten
Phase unterbrochen wird, erscheint der folgende
Bildschrim:
Um das installierte boot1
und
boot2
zu ersetzen, benutzen Sie
bsdlabel
, wobei
diskslice
das Laufwerk und die
Slice darstellt, von dem gebootet wird, beispielsweise
ad0s1
für die erste Slice auf der ersten
IDE-Festplatte:
#
bsdlabel -B
diskslice
Wenn man nur den Festplatten-Namen benutzt,
beispielsweise ad0
, wird
bsdlabel
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
noch einmal prüfen, bevor Return gedrückt
wird.
Der loader ist der letzte von
drei Schritten im Bootstrap-Prozess. Er kann im Dateisystem
normalerweise als /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
/boot/loader.rc
, 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 oder neu zu booten.
Variable | Beschreibung |
---|---|
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
[-Optionen ]
[Kernelname ] | Bewirkt das sofortige Booten des Kernels mit
allen gegebenen Optionen, oder dem angegebenen
Kernelnamen. Das übergeben eines Kernelnamens ist nur
nach einem unload anwendbar,
andernfalls wird der zuvor verwendete Kernel
benutzt. Wenn nicht der vollständige Pfad für
Kernelname angegeben wird, dann
sucht der Loader den Kernel unter
/boot/kernel und
/boot/modules . |
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
… | Das Einlesen und Interpretieren der angegebenen Datei 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. Argumente, die auf
Dateiname folgen, werden
der Datei übergeben. Wenn nicht der vollständige
Pfad für Dateiname angegeben
wird, dann sucht der Loader die Datei unter
/boot/kernel und
/boot/modules . |
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 ausführliche Ausgabe. |
lsmod [-v] | Listet alle geladenen Module auf. Die Option
-v bewirkt eine ausführliche
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 angegebenen Umgebungsvariablen. |
unload | Entlädt sämtliche geladenen Module. |
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
/pfad/zur/kerneldatei
Verwenden Sie
/boot/GENERIC/kernel
, um auf den
allgemeinen Kernel zu verweisen, der bei jeder
Installation dabei ist.
/boot/kernel.old/kernel
hingegen
bezeichnet den Kernel, der vor dem System-Upgrade
installiert war.
Der folgende Befehl lädt die gewöhnlichen Module mit einem anderen Kernel:
unload
set kernel="
meinkernel
"boot-conf
Um ein automatisiertes Kernelkonfigurations-Skript zu laden, geben Sie ein:
load -t userconfig_script /boot/kernel.conf
Sobald 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. In Tabelle 12.2, „Interaktion mit dem Kernel während des Bootens“ sind die gebräuchlichsten Boot-Flags aufgelistet. Informationen zu den anderen Boot-Flags finden Sie in boot(8).
Option | Beschreibung |
---|---|
-a | Bewirkt, dass während der Kernel-Initialisierung gefragt wird, welches Gerät als Root-Dateisystem eingehängt werden soll. |
-C | Das Root-Dateisystem wird von CD-ROM gebootet. |
-s | Bootet in den Single-User Modus |
-v | Zeigt mehr Informationen während des Starten des Kernels an. |
Nachdem der Kernel den Bootprozess abgeschlossen hat,
übergibt er die Kontrolle an den Benutzer-Prozess
init(8). Dieses Programm befindet sich in
/sbin/init
, oder dem Pfad, der durch die
Variable init_path
im loader
spezifiziert wird.
Der automatische Reboot-Vorgang stellt sicher, dass alle
Dateisysteme des Systems konsistent sind. Falls dies nicht
der Fall ist und die Inkonsistenz des
UFS-Dateisystems nicht durch
fsck
behebbar ist, schaltet
init
das System in den Single-User-Modus,
damit der Systemadministrator sich des Problems annehmen kann.
Andernfalls startet das System in den
Mehrbenutzermodus.
Der Wechsel in den Single-User Modus kann beim Booten
durch die Option -s
, oder das Setzen der
Variable boot_single
in
loader erreicht werden. Zudem
kann er auch im Mehrbenutzermodus über den Befehl
shutdown now
erreicht werden. Der
Single-User Modus beginnt mit dieser Meldung:
Enter full path of shell or RETURN for /bin/sh:
Wenn Sie die Eingabetaste drücken, wird das System die Bourne Shell starten. Falls Sie eine andere Shell starten möchten, geben Sie den vollständigen Pfad zur Shell ein.
Der Single-User Modus wird normalerweise zur Reparatur
verwendet, beispielsweise wenn das System aufgrund eines
inkonsistenten Dateisystems oder einem Fehler in einer
Konfigurationsdatei nicht bootet. Der Modus wird auch
verwendet, um das Passwort von root
zurückzusetzen, falls
dieses nicht mehr bekannt ist. Dies alles ist möglich, da
der Single-User Modus vollen Zugriff auf das lokale System
und die Konfigurationsdateien gewährt. Einen Zugang zum
Netzwerk bietet dieser Modus allerdings nicht.
Obwohl der Single-User Modus für Reparaturen am System sehr nützlich ist, stellt es ein Sicherheitsrisiko dar, wenn sich das System an einem physisch unsicheren Standort befindet. In der Voreinstellung hat jeder Benutzer, der physischen Zugriff auf ein System erlangen kann, volle Kontrolle über das System, nachdem in den Single-User Modus gebootet wurde.
Falls die System-Konsole (console
) in
/etc/ttys
auf
insecure
(dt.: unsicher) gesetzt ist,
fordert das System zur Eingabe des root
Passworts auf, bevor es
den Single-User Modus aktiviert. Dadurch gewinnen Sie zwar
ein gewisses Maß an Sicherheit, aber Sie können dann nicht
mehr das Passwort von root
zurücksetzen, falls es
nicht bekannt ist.
/etc/ttys
# name getty type status comments # # If console is marked "insecure", then init will ask for the root password # when going to single-user mode. console none unknown off insecure
Eine Konsole sollte auf insecure
gesetzt sein, wenn die physikalische Sicherheit der Konsole
nicht gegeben ist und sichergestellt werden soll, dass nur
Personen, die das Passwort von root
kennen, den
Single-User Modus benutzen können.
Stellt init fest, dass das
Dateisystem in Ordnung ist, oder der Benutzer den
Single-User-Modus mit exit
beendet,
schaltet das System in den Mehrbenutzermodus, in dem dann
die Ressourcen Konfiguration des Systems gestartet
wird.
Das Ressourcen Konfigurationssystem (engl.
resource configuration, rc)
liest seine Standardkonfiguration von
/etc/defaults/rc.conf
und
System-spezifische Details von
/etc/rc.conf
. Dann mountet es die
Dateisysteme gemäß /etc/fstab
, startet
die Netzwerkdienste, diverse System Daemons und führt
schließlich die Start-Skripten der lokal installierten
Anwendungen aus.
Lesen Sie rc(8) und ebenso die Skripte in
/etc/rc.d
, um mehr über das Ressourcen
Konfigurationssystem zu erfahren.
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>.