20.9. Vinum für das Root-Dateisystem benutzen

Auf einem System, das mit Hilfe von Vinum vollgespiegelte Dateisysteme hat, ist es wünschenswert, auch das Root-Dateisystem zu spiegeln. Solch eine Konfiguration ist allerdings weniger trivial als das Spiegeln eines gewöhnlichen Dateisystems, weil:

Im folgenden Abschnitt wird der Begriff “Root-Volume” benutzt, um das Vinum-Volume zu beschreiben, welches das Root-Dateisystem enthält. Es ist eine gute Idee, für dieses Volume den Namen "root" zu benutzen, aber es ist in keiner Weise technisch nötig (Das folgende Beispiel geht allerdings davon aus, dass dies der Fall ist.).

20.9.1. Vinum für das Root-Dateisystem rechtzeitig starten

Damit dies gelingt, müssen Sie folgende Aufgaben erledigen:

20.9.2. Ein Vinum-basiertes Root-Volume dem Bootstrap verfügbar machen

Da der aktuelle FreeBSD-Bootstrap nur 7,5 KB Code enthält und schon ohne Vinum die Aufgabe hat, bestimmte Dateien (wie /boot/loader) von einem UFS-Dateisystem zu lesen, ist es schier unmöglich, ihm auch noch die Interna von Vinum beizubringen, damit er die Vinum-Konfigurationsdaten auslesen und die Elemente eines Boot-Volumes selbst herausfinden könnte. Daher sind ein paar Tricks nötig, um dem Bootstrap-Code die Illusion einer Standard-"a"-Partition mit einem Root-Dateisystem vorzugaukeln.

Damit dies überhaupt möglich wird, müssen die folgenden Bedingungen für das Root-Dateisystem erfüllt sein:

Beachten Sie, dass es möglich und wünschenswert ist, mehrere Plexus zu haben, von denen jeder eine Kopie des Root-Dateisystems enthält. Der Bootstrap-Prozess wird hingegen nur einen dieser Plexus benutzen, um den Bootstrap und alle Dateien zu finden, bis der Kernel letztendlich das Root-Dateisystem selbst laden wird. Jede einzelne Subdisk innerhalb dieser Plexus wird dann ihre eigene Illusion der Partition "a" brauchen, damit das entsprechende Gerät bootbar wird. Es ist nicht unbedingt notwendig, dass sich jede dieser gefälschten "a"-Partitionen auf seinem Gerät an einem Ort befindet, der um den selben Wert verschoben ist wie auf den anderen Geräten, die Plexus des Root-Dateisystems enthalten. Um Unklarheiten zu verhindern, ist es jedoch eine gute Idee, die Vinum-Volumes so zu erstellen, dass die gespiegelten Geräte symmetrisch sind.

Damit diese "a"-Partitionen eingerichtet werden können, muss für alle Geräte, die Teil des Root-Dateisystems sind, folgendes getan werden:

  1. Der Ort (Verschiebung vom Beginn des Gerätes) und die Größe der Subdisk, die Teil des Root-Volumes ist, muss untersucht werden:

    # gvinum l -rv root
    

    Beachten Sie, dass Vinum-Verschiebungen und -Größen in Bytes gemessen werden. Sie müssen deshalb durch 512 geteilt werden, um die Blockanzahl zu erhalten, wie sie das bsdlabel-Kommando verwendet.

  2. Führen Sie den Befehl

    # bsdlabel -e devname
    

    für jedes Gerät, dass am Root-Volume beteiligt ist, aus. devname muss entweder der Name der Platte (wie da0), im Falle einer Platte ohne Slice-Tabelle oder der Name des Slices (wie ad0s1) sein.

    Wenn es schon eine "a"-Partition auf dem Gerät (in der Regel wahrscheinlich ein Prä-Vinum-Root-Dateisystem) gibt, sollte diese umbenannt werden, damit sie weiterhin verfügbar bleibt (nur für den Fall). Sie wird aber nicht länger benutzt, um das System zu starten. Beachten Sie aber, dass aktive Partitionen (wie ein gemountetes Root-Dateisystem) nicht umbenannt werden können, sodass Sie entweder von einem “Fixit”-Medium booten müssen, oder aber mittels eines zweistufigen Prozesses (sofern Sie in einer gespiegelten Umgebung arbeiten) zuerst die Platte ändern, von der gerade nicht gebootet wurde.

    Nun muss die Verschiebung der Vinum-Partition (sofern vorhanden) auf diesem Gerät mit der Veschiebung der entsprechenden Root-Volume-Subdisk addiert werden. Das Resultat wird der "offset"-Wert für die neue "a"-Partition. Der "size"-Wert für diese Partition kann entsprechend der Berechnung ermittelt werden. "fstype" sollte 4.2BSD sein. Die "fsize"-, "bsize"-, und "cpg"- Werte sollten entsprechend dem eigentlichen Dateisystem gewählt werden, obwohl sie in diesem Kontext ziemlich unwichtig sind.

    Auf diese Art und Weise wird eine neue Partition "a" etabliert, die die Vinum-Partition auf diesem Gerät überschneidet. Beachte Sie, dass das bsdlabel-Kommando diese Überschneidung nur erlaubt, wenn die Partition richtig mit dem "vinum"-fstype markiert ist.

  3. Das ist alles. Auf jedem Gerät befindet sich nun eine gefälschte "a"-Partition, die eine Kopie des Root-Volumes enthält. Es wird dringend empfohlen, das Resultat dieser Konfiguration zu überprüfen:

    # fsck -n /dev/devnamea
    

Denken Sie stets daran, dass alle Dateien, die Kontrollinformationen enthalten, nun relativ zum Root-Dateisystem innerhalb des Vinum-Volumes sein müssen. Denn ein neu eingerichtetes Vinum-Root-Dateisystem ist möglicherweise inkompatibel zum gerade aktiven Root-Dateisystem. Deshalb müssen insbesondere die Dateien /etc/fstab und /boot/loader.conf überprüft werden.

Beim nächsten Systemstart sollte der Bootstrap die adäquaten Kontrollinformationen des neuen Vinum-basierten Root-Dateisystems automatisch herausfinden und entsprechend handeln. Am Ende des Kernel-Initialisierungsprozesses (nachdem alle Geräte angezeigt wurden) erhalten Sie bei einer erfolgreichen Konfiguration eine Nachricht ähnlich der folgenden:

Mounting root from ufs:/dev/gvinum/root

20.9.3. Beispiel eines Vinum-basierten Root-Setups

Nachdem das Vinum-Root-Volume eingerichtet wurde, könnte die Ausgabe von gvinum l -rv root bespielsweise so aussehen:

...
Subdisk root.p0.s0:
        Size:        125829120 bytes (120 MB)
        State: up
        Plex root.p0 at offset 0 (0  B)
        Drive disk0 (/dev/da0h) at offset 135680 (132 kB)

Subdisk root.p1.s0:
        Size:        125829120 bytes (120 MB)
        State: up
        Plex root.p1 at offset 0 (0  B)
        Drive disk1 (/dev/da1h) at offset 135680 (132 kB)
   

Wichtig ist hier insbesondere ist der Wert 135680 für die Verschiebung (relativ zur Partition /dev/da0h). Das entspricht beim Einsatz von bsdlabel 265 512-Byte-Plattenblöcken. Dieses Root-Volume ist ebenso 245760 512-Byte-Blöcke groß. /dev/da1h enthält die zweite Kopie dieses Root-Volumes und ist symmetrisch aufgebaut.

Das Bsdlabel für diese Geräte könnte so aussehen:

...
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:   245760      281    4.2BSD     2048 16384     0   # (Cyl.    0*- 15*)
  c: 71771688        0    unused        0     0         # (Cyl.    0 - 4467*)
  h: 71771672       16     vinum                        # (Cyl.    0*- 4467*)
   

Wie man leicht feststellen kann, entspricht der Parameter "size" der gefälschten "a"-Partition dem ausgewiesenen Wert von oben, während der Parameter "offset" gleich der Summe der Verschiebung innerhalb der Vinum-Partition "h" und der Verschiebung innerhalb des Geräts (oder Slice) ist. Dies ist ein typischer Aufbau, der nötig ist, um die in Abschnitt 20.9.4.3 beschriebenen Probleme zu vermeiden. Die gesamte Partition "a" befindet sich in "h", die alle Vinum-Daten für dieses Gerät enthält.

Beachten Sie, dass in dem oben beschriebenen Beispiel das gesamte Gerät Vinum gewidmet ist und keine Prä-Vinum-Partition zurückgelassen wurde, da es sich im Beispiel um eine neu eingerichtete Platte handelt, die nur für die Vinum-Konfiguration bestimmt war.

20.9.4. Fehlerbehebung

Der folgende Abschnitt beschreibt einige bekannte Probleme und Fallstricke bei der Vinum-Konfiguration sowie deren Behebung.

20.9.4.1. Der System-Bootstrap lädt zwar, das System startet aber nicht.

Wenn aus irgendeinem Grund das System nicht mit dem Booten fortfährt, kann man den Bootstrap während der 10-Sekunden-Warnung durch Drücken der Leertaste unterbrechen. Die loader-Variablen (wie vinum.autostart) können mittels des show-Kommandos untersucht, und mit set oder unset geändert werden.

Wenn das einzige Problem das Fehlen des Vinum-Kernelmoduls in der Liste der automatisch zu ladenden Module ist, hilft ein einfaches load geom_vinum.

Danach können Sie den Bootvorgang mit boot -as fortsetzen. Die Optionen -as fordern den Kernel auf, nach dem zu mountenden Root-Dateisystem zu fragen (-a), und den Bootvorgang im Single-User-Modus (-s) zu beenden, in dem das Root-Dateisystem schon schreibgeschützt gemountet ist. Auf diese Weise wird keine Dateninkonsistenz zwischen den Plexus riskiert, auch wenn nur ein Plexus eines Multi-Plexus-Volumes gemountet wurde.

Beim Prompt, das nach einem Root-Dateisystem fragt, kann jedes Gerät angegeben werden, dass ein gültiges Root-Dateisystem hat. Wenn /etc/fstab richtig konfiguriert wurde, sollte die Vorgabe etwas wie ufs:/dev/gvinum/root sein. Eine typische Alternative würde etwas wie ufs:da0d sein, welches eine hypothetische Partition sein könnte, die ein Pre-Vinum-Root-Dateisystem enthält. Vorsicht sollte walten, wenn eine der alias "a"-Partitionen hier eingegeben wird, die eigentlich Referenzen auf die Subdisks des Vinum-Root-Dateisystems sind, da so nur ein Stück eines gespiegelten Root-Gerätes gemountet werden würde. Wenn das Dateisystem später zum Lesen und Schreiben gemountet werden soll, ist es nötig, die anderen Plexus des Vinum-Root-Volumes zu entfernen, weil diese Plexus andernfalls inkonsistente Daten enthalten würden.

20.9.4.2. Nur der primäre Bootstrap lädt

Wenn das Laden von /boot/loader fehlschlägt, aber der primäre Bootstrap dennoch lädt (sichtbar an dem einzelnen Strich in der linken Spalte des Bildschirms gleich nachdem der Bootprozess startet), kann man versuchen, den primären Bootstrap an diesem Punkt durch Benutzen der Leertaste zu unterbrechen. Dies wird den Bootstrap in der zweiten Phase stoppen (siehe dazu auch Abschnitt 12.3.2). Hier kann nun der Versuch unternommen werden, von einer anderen Partition zu booten, wie beispielsweise dem vorhergehenden Root-Dateisystem, das von "a" verschoben wurde.

20.9.4.3. Nichts bootet, der Bootstrap hängt sich auf

Diese Situation wird vorkommen, wenn der Bootstrap durch die Vinum-Installation zerstört worden ist. Unglücklicherweise lässt Vinum am Anfang seiner Partition nur 4 KB frei und schreibt dahinter seine Kopfinformationen. Allerdings benötigen Stufe-Eins- und -Zwei-Bootstraps plus dem dazwischen eingebetteten bsdlabel momentan 8 KB. Demzufolge wird die Vinum-Installation, wenn die Vinum-Partition mit der Verschiebung 0 (innerhalb eines Slice oder einer Platte, die zum Start bestimmt waren) eingerichtet wurde, den Bootstrap zerstören.

Analog wird eine anschließende Reinstallation eines Bootstrap (zum Beispiel durch Booten eines “Fixit”-Mediums) mit bsdlabel -B, wie in Abschnitt 12.3.2 beschrieben, den Vinum-Kopf zerstören und Vinum wird seine Platte(n) nicht mehr finden können. Obwohl keine eigentlichen Vinum-Konfigurationsdaten oder Daten in den Vinum-Volumes zerstört werden und es möglich wäre, alle Daten wiederherzustellen, indem die exakt gleichen Vinum-Konfigurationsdaten noch einmal eingegeben werden, bleibt die Situation schwer zu bereinigen, da es nötig ist, die gesamte Vinum-Partition um mindestens 4 KB nach hinten zu verschieben, damit Bootstrap und Vinum-Kopf nicht mehr kollidieren.

20.9.5. Vinum und FreeBSD 4.X

Unter FreeBSD 4.X fehlen einige interne Funktionen, daher ist Vinum hier nicht in der Lage, automatisch alle Platten zu scannen. Außerdem ist der Code zur Bestimmung der internen ID des Root-Geräts nicht intelligent genug, um von sich aus mit einem Namen wie /dev/vinum/root umzugehen. Dieser Abschnitt beschreibt, wie Sie diese Einschränkungen umgehen können.

Sie müssen Vinum explizit mitteilen, welche Laufwerke gescannt werden sollen. Dazu nehmen Sie eine Zeile ähnlich der folgenden in /boot/loader.conf auf:

vinum.drives="/dev/da0 /dev/da1"

Es ist wichtig, dass Sie alle Laufwerke angeben, die Vinum-Daten enthalten könnten. Zwar schadet es nicht, weitere Laufwerke anzugeben, dies ist aber nicht nötig, da jedes Slice und/oder jede Partition von Vinum automatisch auf gültige Vinum-Header hin überprüft wird.

Da die Routinen, die zum Parsen des Root-Dateisystems-Namens und zum Herleiten der Geräte-ID (major/minor number) verwendet werden, nur “klassische” Gerätenamen verstehen, ist es nicht möglich, für das Root-Volume einen Namen wie /dev/vinum/root zu verwenden. Daher muss Vinum den internen Kernelparameter, der die ID des Root-Gerätes bekommt, während seiner eigenen Initialsierung selbst festlegen und den Namen des Root-Volumes der Loader-Variable vinum.root übergeben. Dazu wird folgende Zeile in /boot/loader.conf aufgenommen:

vinum.root="root"

Sobald jetzt die Kernelinitialisierung versucht, den Namen des zu mountenden Root-Gerätes herauszufinden, sieht sie, dass ein Kernelmodul den Kernelparameter schon vorinitialisiert hat. Wenn dies der Fall ist und das Gerät, dass sich als Root-Gerät ausgibt, tatsächlich die Hauptnummer des Treibers hat, wie sie mit Hilfe des übergebenen Root-Geräte-Namens (in unserem Fall ist das "vinum") ermittelt wurde, wird die Kernelinitialisierung die vorbelegte Geräte-ID verwenden, anstatt selbst eine herauszufinden. Auf diese Art kann es, während des gewöhnlichen automatischen Hochfahrens, mit dem Einhängen des Vinum-Root-Volumes als Root-Dateisystem fortfahren.

Obwohl boot -a zur manuellen Eingabe des Root-Gerätes auffordert, muss dennoch beachtet werden, dass die Routine noch nicht in der Lage ist, einen Vinum-Namen zu parsen. Wenn ein Gerätename eingegeben wird, der nicht auf ein Vinum-Gerät verweist, wird der Unterschied zwischen den Hauptnummern des vorbelegten Root-Parameters und des Treibers die Routine dazu veranlassen, den normalen Parser zu benutzen. Demnach wird eine Zeichenkette wie ufs:da0d erwartungsgemäß funktionieren. Beachten Sie aber, dass es im Falle eines Fehlschlags nicht mehr möglich ist, eine Zeichenkette wie ufs:vinum/root noch einmal einzugeben, da diese nicht geparsed werden kann. Der einzige Ausweg ist dann ein Neustart des Systems. (Am “askroot”-Prompt kann der Teil /dev/ des Namens der Gerätedatei immer weggelassen werden.).

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>.