25.7. Das komplette Basissystem neu bauen

Wenn Sie Ihren lokalen Quellbaum mit einer bestimmten FreeBSD Version (FreeBSD-STABLE, FreeBSD-CURRENT, usw.) synchronisiert haben, können Sie diesen benutzen, um das System neu zu bauen.

Erstellen Sie eine Sicherungskopie!:

Es kann nicht oft genug betont werden, wie wichtig es ist, Ihr System zu sichern, bevor Sie die nachfolgenden Schritte ausführen. Obwohl der Neubau des Systems eine einfache Aufgabe ist, wenn Sie sich an die folgende Anleitung halten, kann es dennoch vorkommen, dass Sie einen Fehler machen, oder dass Ihr System nicht mehr bootet, weil andere Entwickler Fehler in den Quellbaum eingeführt haben.

Stellen Sie sicher, dass Sie eine Sicherung erstellt haben und über eine Fixit-Floppy oder eine startfähige CD verfügen. Wahrscheinlich werden Sie die Startmedien nicht benötigen, aber gehen Sie auf Nummer sicher!

Abonnieren Sie die richtige Mailingliste:

Die FreeBSD-STABLE und FreeBSD-CURRENT Zweige befinden sich in ständiger Entwicklung. Die Leute, die zu FreeBSD beitragen, sind Menschen und ab und zu machen sie Fehler.

Manchmal sind diese Fehler harmlos und lassen Ihr System eine Warnung ausgeben. Die Fehler können allerdings auch katastrophal sein und dazu führen, dass Sie Ihr System nicht mehr booten können, Dateisysteme beschädigt werden oder Schlimmeres passiert.

Wenn solche Probleme auftauchen, wird ein heads up an die passende Mailingliste geschickt, welches das Problem erklärt und die betroffenen Systeme benennt. Eine all clear Meldung wird versendet, wenn das Problem gelöst ist.

Wenn Sie FreeBSD-STABLE oder FreeBSD-CURRENT benutzen und nicht die Mailinglisten FreeBSD-STABLE beziehungsweise FreeBSD-CURRENT lesen, bringen Sie sich nur unnötig in Schwierigkeiten.

Finger weg von make world:

Ältere Dokumentationen empfehlen, das Kommando make world für den Neubau. Das Kommando überspringt wichtige Schritte. Setzen Sie es nur ein, wenn Sie wissen was Sie tun. In fast allen Fällen ist make world falsch, benutzen Sie stattdessen die nachstehende Anleitung.

25.7.1. Richtig aktualisieren

Um Ihr System zu aktualisieren, sollten Sie zuerst /usr/src/UPDATING lesen, und eventuelle, für Ihre Quellcodeversion nötigen Aufgaben erledigen, bevor Sie das System bauen. Danach aktualisieren Sie Ihr System mit den folgenden Schritten.

Bei den hier dargestellten Aktualisierungsschritten wird davon ausgegangen, dass Sie momentan eine alte FreeBSD-Version verwenden, die aus einem alten Compiler, Kernel, sowie einem alten Basissystem und veralteten Konfigurationsdateien besteht. Mit Basissystem sind hier die zentralen Binärdateien, Bibliotheken und Entwicklerdateien gemeint. Der Compiler ist Teil des Basissystems, beinhaltet aber ein paar Besonderheiten.

Es wird ausserdem davon ausgegangen, dass Sie bereits die Quellen für ein neues System bezogen haben. Falls die Quellen in dem vorliegenden System zu alt sind, lesen Sie Abschnitt 25.6, „Synchronisation der Quellen“, um detaillierte Hilfe über die Aktualisierung der Quellen zu erhalten.

Die Aktualisierung des Systems aus den Quellen ist ein wenig ausgetüftelter als es zunächst den Anschein hat. Die Entwickler von FreeBSD haben es über die Jahre für Nötig befunden, den vorgeschlagenen Ablauf ziemlich stark zu verändern, da neue Arten von unvermeidlichen Abhängigkeiten mit der Zeit ans Licht kamen. Der übrige Teil dieses Abschnitts beschreibt die Überlegungen hinter der aktuell empfohlenen Aktualisierungsreihenfolge.

Jede erfolgreiche Aktualisierung muss sich mit den folgenden Sachverhalten auseinandersetzen:

  • Der alte Compiler ist möglicherweise nicht in der Lage, den neuen Kernel zu übersetzen (alte Compiler besitzen manchmal Fehler). Deshalb sollte der neue Kernel mit dem neuen Compiler übersetzt werden. Ganz besonders muss darauf geachtet werden, dass der neue Compiler vor dem neuen Kernel gebaut wird. Das bedeutet nicht unbedingt, dass der neue Compiler auch installiert werden muss, bevor der neue Kernel gebaut wird.

  • Das neue Basissystem benötigt eventuell neue Eigenschaften des Kernels. Also muss der neue Kernel installiert sein, bevor das neue Basissystem installiert wird.

Diese ersten beiden Sachverhalte sind die Grundlage für die zentrale Sequenz von buildworld, buildkernel, installkernel und installworld, die in den folgenden Abschnitten beschrieben wird. Dies ist keine vollständige Liste all der Gründe, warum Sie den aktuell empfohlenen Prozess der Aktualisierung bevorzugen sollten. Ein paar der weniger naheliegenden Gründe sind im folgenden aufgezählt:

  • Das alte Basissystem wird möglicherweise nicht korrekt mit dem neuen Kernel funktionieren, weshalb Sie das neue Basissystem sofort nach der Installation des neuen Kernels installieren müssen.

  • Manche Änderungen an der Konfiguration müssen erledigt worden sein, bevor das neue Basissystem installiert wird, jedoch können andere die Funktionalität des alten Basissystems beeinträchtigen. Aus diesem Grund sind zwei verschiedene Schritte notwendig, um eine Aktualisierung der Konfiguration durchzuführen.

  • Der Aktualisierungsprozess ersetzt zum Grossteil Dateien oder fügt neue hinzu, bestehende Dateien werden nicht gelöscht. In wenigen Ausnahmefällen kann dies Probleme verursachen. Aus diesem Grund wird der Aktualisierungsprozess manchmal bestimmte Dateien zum manuellen Löschen vorschlagen. Dies wird eventuell in der Zukunft automatisch durchgeführt.

Diese Bedenken haben zu der folgenden Reihenfolge geführt. Beachten Sie, dass der genaue Ablauf für bestimmte Aktualisierungen zusätzliche Schritte nach sich zieht, jedoch sollte der Kernprozess davon nicht beeinträchtigt werden:

  1. make buildworld

    Dieser Schritt übersetzt zuerst den neuen Compiler und ein paar damit zusammenhängende Werkzeuge und verwendet dann den neuen Compiler, um den Rest des Basissystems zu erstellen. Das Ergebnis landet dann in /usr/obj.

  2. make buildkernel

    Statt dem alten Ansatz, config(8) und make(1) zu verwenden, nutzt dieser den neuen Compiler, der in /usr/obj abgelegt ist. Das schützt Sie vor falschen Compiler-Kernel-Kombinationen.

  3. make installkernel

    Platziert den neuen Kernel und Kernelmodule auf der Platte, was es erlaubt, mit dem frisch aktualisierten Kernel zu starten.

  4. Starten Sie das System neu in den Single-User-Modus.

    Der Single-User-Modus minimiert Probleme mit der Aktualisierung von Programmen, die bereits gestartet sind. Ebenso minimiert es Probleme, die mit der Verwendung des alten Basissystems und des neuen Kernels zu tun haben könnten.

  5. mergemaster -p

    Dieser Schritt aktualisiert ein paar initiale Konfigurationsdateien als Vorbereitung für das neue Basissystem. Beispielsweise fügt es neue Benutzergruppen zum System oder neue Benutzernamen in die Passwortdatenbank hinzu. Dies wird oftmals benötigt, wenn neue Gruppen oder bestimmte Systembenutzerkonten seit der letzten Aktualisierung hinzu gekommen sind, so dass der installworld-Schritt in der Lage ist, auf dem neu installierten System die Benutzer oder Systemgruppennamen ohne Probleme zu verwenden.

  6. make installworld

    Kopiert das Basissystem aus /usr/obj. Sie haben jetzt den neuen Kernel und das neue Basissystem auf der Festplatte.

  7. mergemaster

    Sie können nun die verbleibenden Konfigurationsdateien aktualisieren, da Sie nun das neue Basissystem auf der Platte haben.

  8. Starten Sie das System neu.

    Ein kompletter Systemneustart ist notwendig, um den neuen Kernel und das neue Basissystem mit den neuen Konfigurationsdateien zu laden.

Beachten Sie, dass wenn Sie von einem Release des gleichen FreeBSD-Zweigs auf ein aktuelleres Release des gleichen Zweigs, z.B. von 7.0 auf 7.1, aktualisieren, dann ist diese Vorgehensweise nicht unbedingt notwendig, da Sie nur sehr unwahrscheinlich in ungünstige Kombinationen zwischen Compiler, Kernel, Basissystem und den Konfigurationsdateien geraten werden. Die ältere Vorgehensweise von make world, gefolgt von der Erstellung und Installation des neuen Kernels funktioniert möglicherweise gut genug, um kleinere Aktualisierungen vorzunehmen.

Wenn Sie allerdings zwischen Hauptversionen aktualisieren wollen und befolgen diese Schritte nicht, sollten Sie sich auf Probleme gefasst machen.

Es ist auch wichtig zu wissen, dass viele Aktualisierungen, z.B. von 4.X auf 5.0, viele spezielle und zusätzliche Schritte benötigt, wie beispielsweise das umbennen oder löschen von speziellen Dateien vor installworld. Lesen Sie die Datei /usr/src/UPDATING gründlich, besonders am Ende, wo die aktuell vorgeschlagene Aktualisierungssequenz explizit aufgelistet ist.

Diese Prozedur hat sich mit der Zeit weiterentwickelt, da die Entwickler es für unmöglich erachtet haben, bestimmte Arten von Kombinationsproblemen vollständig auszuschliessen. Hoffentlich wird die aktuelle Aktualisierungsprozedur für lange Zeit stabil bleiben.

Als Zusammenfassung ist hier nochmal die aktuell vorgeschlagene Vorgehensweise für die Aktualisierung von FreeBSD aus den Quellen aufgelistet:

# cd /usr/src
# make buildworld
# make buildkernel
# make installkernel
# shutdown -r now

Anmerkung:

Es gibt einige, sehr seltene Situationen, in denen Sie mergemaster -p zusätzlich ausführen müssen, bevor Sie das System mit buildworld bauen. Diese Situationen werden in UPDATING beschrieben. Solche Situationen treten aber in der Regel nur dann auf, wenn Sie Ihr FreeBSD-System um eine oder mehrere Hauptversionen aktualisieren.

Nachdem installkernel erfolgreich abgeschlossen wurde, starten Sie das System im Single-User-Modus (etwa durch die Eingabe von boot -s am Loaderprompt). Danach führen Sie die folgenden Anweisungen aus:

# mount -u /
# mount -a -t ufs
# adjkerntz -i
# mergemaster -p
# cd /usr/src
# make installworld
# mergemaster
# reboot

Lesen Sie bitte weiter:

Die obige Vorschrift ist nur eine Gedächtnisstütze. Um die einzelnen Schritte zu verstehen, lesen Sie bitte die folgenden Abschnitte, insbesondere wenn Sie einen angepassten Kernel erstellen.

25.7.2. Lesen Sie /usr/src/UPDATING

Bevor Sie etwas anderes tun, lesen Sie bitte /usr/src/UPDATING (oder die entsprechende Datei, wenn Sie den Quellcode woanders installiert haben). Die Datei enthält wichtige Informationen zu Problemen, auf die Sie stoßen könnten oder gibt die Reihenfolge vor, in der Sie bestimmte Kommandos laufen lassen müssen. Die Anweisungen in UPDATING sind aktueller als die in diesem Handbuch. Im Zweifelsfall folgen Sie bitte den Anweisungen aus UPDATING.

Wichtig:

Das Lesen von UPDATING ersetzt nicht das Abonnieren der richtigen Mailingliste. Die beiden Voraussetzungen ergänzen sich, es reicht nicht aus, nur eine zu erfüllen.

25.7.3. Überprüfen Sie /etc/make.conf

Überprüfen Sie die Dateien /usr/share/examples/etc/make.conf und /etc/make.conf. Die erste enthält Vorgabewerte, von denen die meisten auskommentiert sind. Um diese während des Neubaus des Systems zu nutzen, tragen Sie die Werte in /etc/make.conf ein. Beachten Sie, dass alles, was Sie in /etc/make.conf eintragen, bei jedem Aufruf von make angezogen wird. Es ist also klug, hier etwas Sinnvolles einzutragen.

Typischerweise wollen Sie die Zeilen, die CFLAGS und NO_PROFILE enthalten, aus /usr/share/examples/etc/make.conf nach /etc/make.conf übertragen und dort aktivieren.

Sehen Sie sich auch die anderen Definitionen, wie COPTFLAGS oder NOPORTDOCS an und entscheiden Sie, ob Sie diese aktivieren wollen.

25.7.4. Aktualisieren Sie die Dateien in /etc

Das Verzeichnis /etc enthält den Großteil der Konfigurationsdateien des Systems und Skripten, die beim Start des Systems ausgeführt werden. Einige dieser Skripten ändern sich bei einer Migration auf eine neue FreeBSD-Version.

Einige der Konfigurationsdateien, besonders /etc/group, werden für den Normalbetrieb des Systems gebraucht.

Es gab Fälle, in denen das Kommando make installworld auf bestimmte Accounts oder Gruppen angewiesen war, die aber während der Aktualisierung fehlten. Demzufolge kam es zu Problemen bei der Aktualisierung. In einigen Fällen prüft make buildworld ob die Accounts oder Gruppen vorhanden sind.

Ein Beispiel dafür trat beim Anlegen des Benutzers smmsp auf. Die Installationsprozedur schlug an der Stelle fehl, an der mtree(8) versuchte, /var/spool/clientmqueue anzulegen.

Um dieses Problem zu umgehen,rufen Sie mergemaster(8) prä-buildworld-Modus auf, der mit -p aktiviert wird. In diesem Modus werden nur Dateien verglichen, die für den Erfolg von buildworld oder installworld essentiell sind.

Tipp:

Wenn Sie besonders paranoid sind, sollten Sie Ihr System nach Dateien absuchen, die der Gruppe, die Sie umbenennen oder löschen, gehören:

# find / -group GID -print

Das obige Kommando zeigt alle Dateien an, die der Gruppe GID (dies kann entweder ein Gruppenname oder eine numerische ID sein) gehören.

25.7.5. Wechseln Sie in den Single-User-Modus

Sie können das System im Single-User-Modus übersetzen. Abgesehen davon, dass dies etwas schneller ist, werden bei der Installation des Systems viele wichtige Dateien, wie die Standard-Systemprogramme, die Bibliotheken und Include-Dateien, verändert. Sie bringen sich in Schwierigkeiten, wenn Sie diese Dateien auf einem laufenden System verändern, besonders dann, wenn zu dieser Zeit Benutzer auf dem System aktiv sind.

Eine andere Methode übersetzt das System im Mehrbenutzermodus und wechselt für die Installation in den Single-User-Modus. Wenn Sie diese Methode benutzen wollen, warten Sie mit den folgenden Schritten, bis der Bau des Systems fertig ist und Sie mit installkernel oder installworld installieren wollen.

Als Superuser können Sie mit dem folgenden Kommando ein laufendes System in den Single-User-Modus bringen:

# shutdown now

Alternativ können Sie das System mit der Option single user in den Single-User-Modus booten. Danach geben Sie die folgenden Befehle ein:

# fsck -p
# mount -u /
# mount -a -t ufs
# swapon -a

Die Kommandos überprüfen die Dateisysteme, hängen / wieder beschreibbar ein, hängen dann alle anderen UFS Dateisysteme aus /etc/fstab ein und aktivieren den Swap-Bereich.

Anmerkung:

Zeigt Ihre CMOS-Uhr die lokale Zeit und nicht GMT an, dies erkennen Sie daran, dass date(1) die falsche Zeit und eine falsche Zeitzone anzeigt, setzen Sie das folgende Kommando ab:

# adjkerntz -i

Dies stellt sicher, dass Ihre Zeitzone richtig eingestellt ist. Ohne dieses Kommando werden Sie vielleicht später Probleme bekommen.

25.7.6. Entfernen Sie /usr/obj

Die neu gebauten Teile des Systems werden in der Voreinstellung unter /usr/obj gespeichert. Die Verzeichnisse dort spiegeln die Struktur unter /usr/src.

Sie können den make buildworld Prozess beschleunigen, indem Sie dieses Verzeichnis entfernen. Dies erspart Ihnen zudem einigen Ärger aufgrund von Abhängigkeiten.

Einige Dateien unter /usr/obj sind vielleicht durch die immutable-Option (siehe chflags(1)) schreibgeschützt, die vor dem Löschen entfernt werden muss.

# cd /usr/obj
# chflags -R noschg *
# rm -rf *

25.7.7. Übersetzen der Quellen des Basissystems

25.7.7.1. Sichern der Ausgaben

Für den Fall, dass etwas schief geht, sollten Sie die Ausgaben von make(1) in einer Datei sichern, damit Sie eine Kopie der Fehlermeldung besitzen. Das mag Ihnen nicht helfen, den Fehler zu finden, kann aber anderen helfen, wenn Sie Ihr Problem in einer der FreeBSD-Mailinglisten schildern.

Dazu können Sie einfach das Kommando script(1) benutzen, dem Sie beim Aufruf als Parameter den Dateinamen für die Ausgaben mitgeben. Setzen Sie das Kommando unmittelbar vor dem Neubau ab und geben Sie exit ein, wenn der Bau abgeschlossen ist:

# script /var/tmp/mw.out
Script started, output file is /var/tmp/mw.out
# make TARGET
… Ausgaben des Kommandos …
# exit
Script done, …

Sichern Sie die Ausgaben nicht in /tmp, da dieses Verzeichnis beim nächsten Boot aufgeräumt werden kann. Ein geeigneteres Verzeichnis ist /var/tmp, wie im vorigen Beispiel gezeigt, oder das Heimatverzeichnis von root.

25.7.7.2. Übersetzen des Basissystems

Wechseln Sie in das Verzeichnis, in dem die Quellen liegen (in der Voreinstellung ist das /usr/src):

# cd /usr/src

Zum Neubau der Welt benutzen Sie make(1). Dieses Kommando liest ein Makefile, das Anweisungen enthält, wie die Programme, aus denen FreeBSD besteht, zu bauen sind und in welcher Reihenfolge diese zu bauen sind.

Ein typischer Aufruf von make sieht wie folgt aus:

# make -x -DVARIABLE target

In diesem Beispiel ist -x eine Option, die Sie an make(1) weitergeben wollen. Eine Liste gültiger Optionen finden Sie in der make(1) Manualpage.

Das Verhalten eines Makefiles wird von Variablen bestimmt. Mit -DVARIABLE setzen Sie eine Variable. Diese Variablen sind dieselben, die auch in /etc/make.conf gesetzt werden, dies ist nur ein alternativer Weg, Variablen zu setzen.

Um zu verhindern, dass die profiled Bibliotheken gebaut werden, rufen Sie make wie folgt auf:

# make -DNO_PROFILE target

Dieser Aufruf entspricht dem folgenden Eintrag in /etc/make.conf:

NO_PROFILE=    true     #    Avoid compiling profiled libraries

Jedes Makefile definiert einige Ziele, die festlegen, was genau zu tun ist. Mit target wählen Sie eins dieser Ziele aus.

Einige Ziele im Makefile sind nicht für den Endanwender gedacht, sondern unterteilen den Bauprozess in eine Reihe von Einzelschritten.

Im Regelfall müssen Sie make(1) keine Parameter mitgeben, so dass Ihre Kommandozeile wie folgt aussehen wird:

# make target

target steht dabei für die verschiedenen Ziele. Das erste Ziel sollte immer buildworld sein.

Mit buildworld wird ein kompletter Baum unterhalb von /usr/obj gebaut, der mit installworld, einem weiteren Ziel, auf dem System installiert werden kann.

Über separate Optionen zu verfügen, ist aus mehreren Gründen nützlich. Erstens können Sie das System auf einem laufenden System bauen, da die Bauprozedur abgekapselt vom Rest des Systems ist. Das System lässt sich im Mehrbenutzermodus ohne negative Seiteneffekte bauen. Die Installation mit installworld sollte aber immer noch im Single-User-Modus erfolgen.

Zweitens können Sie NFS benutzen, um mehrere Maschinen in Ihrem Netzwerk zu aktualisieren. Wenn Sie die Maschinen A, B und C aktualisieren wollen, lassen sie make buildworld und make installworld auf A laufen. Auf den Maschinen B und C können Sie die Verzeichnisse /usr/src und /usr/obj von A einhängen und brauchen dort nur noch make installworld auszuführen, um die Bauresultate zu installieren.

Obwohl das Ziel world noch existiert, sollten Sie es wirklich nicht mehr benutzen.

Um das System zu bauen, setzen Sie das folgende Kommando ab:

# make buildworld

Mit -j können Sie make anweisen, mehrere Prozesse zu starten. Besonders effektiv ist das auf Mehrprozessor-Systemen. Da aber der Übersetzungsprozess hauptsächlich von IO statt der CPU bestimmt wird, ist diese Option auch auf Einprozessor-Systemen nützlich.

Auf einem typischen Einprozessor-System können Sie den folgenden Befehl absetzen:

# make -j4 buildworld

make(1) wird dann bis zu vier Prozesse gleichzeitig laufen lassen. Erfahrungsberichte aus den Mailinglisten zeigen, dass dieser Aufruf typischerweise den besten Geschwindigkeitsgewinn bringt.

Wenn Sie ein Mehrprozessor-System besitzen und SMP in Ihrem Kernel konfiguriert ist, probieren Sie Werte zwischen 6 und 10 aus.

25.7.7.3. Laufzeiten

Die Laufzeit eines Baus wird von vielen Faktoren beeinflusst, ein aktuelles System benötigt aber etwa zwei Stunden um FreeBSD-STABLE zu bauen. Der Bau von FreeBSD-CURRENT dauert etwas länger.

25.7.8. Übersetzen und Installation des Kernels

Um das Beste aus Ihrem System zu holen, sollten Sie einen neuen Kernel kompilieren. Praktisch gesehen ist das sogar notwendig, da sich einige Datenstrukturen geändert haben und Programme wie ps(1) oder top(1) nur mit einem Kernel zusammen arbeiten, der auch zu dem entsprechenden Quellcode passt.

Am einfachsten und sichersten bauen Sie dazu den GENERIC Kernel. Obwohl der GENERIC Kernel vielleicht nicht alle Ihre Geräte unterstützt, sollte er alles enthalten, um das System in den Single-User-Modus zu booten. Dies ist auch ein guter Test, um zu sehen, dass das System ordnungsgemäß funktioniert. Nachdem Sie mit GENERIC gebootet und sichergestellt haben, dass Ihr System funktioniert, können Sie einen neuen Kernel mit Ihrer Konfigurationsdatei bauen.

In aktuellen FreeBSD-Versionen müssen Sie das Basissystem neu bauen, bevor Sie einen neuen Kernel erstellen.

Anmerkung:

Wenn Sie einen angepassten Kernel erstellen wollen und bereits über eine Konfigurationsdatei verfügen, geben Sie diese, wie im folgenden Beispiel gezeigt, auf der Kommandozeile an:

# cd /usr/src
# make buildkernel KERNCONF=MYKERNEL
# make installkernel KERNCONF=MYKERNEL

Wenn kern.securelevel einen Wert größer als 1 besitzt und der Kernel mit noschg oder ähnlichen Optionen geschützt ist, müssen Sie installkernel im Einbenutzermodus ausführen. Wenn das nicht der Fall ist, sollten die beiden Kommandos problemlos im Mehrbenutzermodus laufen. Weitere Informationen über kern.securelevel finden Sie in init(8) und chflags(1) erläutert Optionen, die Sie auf Dateien setzen können.

25.7.9. Booten Sie in den Single-User-Modus

Um zu prüfen, ob der neue Kernel funktioniert, sollten Sie in den Single-User-Modus booten. Folgen Sie dazu der Anleitung aus Abschnitt 25.7.5, „Wechseln Sie in den Single-User-Modus“.

25.7.10. Installation des Systems

Nun können Sie das neue System mit installworld installieren. Rufen Sie dazu das folgende Kommando auf:

# cd /usr/src
# make installworld

Anmerkung:

Wenn Sie mit dem make buildworld Kommando Variablen verwendet haben, müssen Sie dieselben Variablen auch bei dem make installworld Kommando angeben. Auf die anderen Optionen trifft das nur bedingt zu: -j darf mit installworld nicht benutzt werden.

Sie haben zum Bauen die folgende Kommandozeile verwendet:

# make -DNO_PROFILE buildworld

Bei der Installation setzen Sie dann das folgende Kommando ab:

# make -DNO_PROFILE installworld

Würden Sie die Variable bei der Installation weglassen, so würde das System versuchen, die profiled Bibliotheken, die aber gar nicht gebaut wurden, zu installieren.

25.7.11. Aktualisieren der von make installworld ausgelassenen Dateien

Neue oder geänderte Konfigurationsdateien aus einigen Verzeichnissen, besonders /etc, /var und /usr werden bei der Installationsprozedur nicht berücksichtigt.

Sie können diese Dateien mit mergemaster(8) aktualisieren. Alternativ können Sie das auch manuell durchführen, obwohl wir diesen Weg nicht empfehlen. Egal welchen Weg Sie beschreiten, sichern Sie vorher den Inhalt von /etc für den Fall, dass etwas schief geht.

25.7.11.1. mergemaster

Beigetragen von Tom Rhodes.

Das Bourne-Shell Skript mergemaster(8) hilft Ihnen dabei, die Unterschiede zwischen den Konfigurationsdateien in /etc und denen im Quellbaum unter /usr/src/etc zu finden. mergemaster ist der empfohlene Weg, Ihre Systemkonfiguration mit dem Quellbaum abzugleichen.

Rufen Sie mergemaster einfach auf und schauen Sie zu. Ausgehend von / wird mergemaster einen virtuellen Root-Baum aufbauen und darin die neuen Konfigurationsdateien ablegen. Diese Dateien werden dann mit den auf Ihrem System installierten verglichen. Unterschiede zwischen den Dateien werden im diff(1)-Format dargestellt. Neue oder geänderte Zeilen werden mit + gekennzeichnet. Zeilen die gelöscht oder ersetzt werden, sind mit einem - gekennzeichnet. Das Anzeigeformat wird in diff(1) genauer erklärt.

mergemaster(8) zeigt Ihnen jede geänderte Datei an und Sie haben die Wahl, die neue Datei (in mergemaster wird sie temporäre Datei genannt) zu löschen, sie unverändert zu installieren, den Inhalt der neuen Datei mit dem Inhalt der alten Datei abzugleichen, oder die diff(1) Ausgabe noch einmal zu sehen. Sie können die aktuelle Datei auch überspringen, sie wird dann noch einmal angezeigt, nachdem alle anderen Dateien abgearbeitet wurden. Sie erhalten Hilfe, wenn Sie bei der Eingabeaufforderung von mergemaster ein ? eingeben.

Wenn Sie die temporäre Datei löschen, geht mergemaster davon aus, dass Sie Ihre aktuelle Datei behalten möchten. Wählen Sie die Option bitte nur dann, wenn Sie keinen Grund sehen, die aktuelle Datei zu ändern.

Wenn Sie die temporäre Datei installieren, wird Ihre aktuelle Datei mit der neuen Datei überschrieben. Sie sollten alle unveränderten Konfigurationsdateien auf diese Weise aktualisieren.

Wenn Sie sich entschließen den Inhalt beider Dateien abzugleichen, wird ein Texteditor aufgerufen, indem Sie beide Dateien nebeneinander betrachten können. Mit der Taste l übernehmen Sie die aktuelle Zeile der links dargestellten Datei, mit der Taste r übernehmen Sie die Zeile der rechts dargestellten Datei. Das Ergebnis ist eine Datei, die aus Teilen der beiden ursprünglichen Dateien besteht und installiert werden kann. Dieses Verfahren wird gewöhnlich bei veränderten Dateien genutzt.

Haben Sie sich entschieden die Differenzen noch einmal anzuzeigen, zeigt Ihnen mergemaster(8) dieselbe Ausgabe, die Sie gesehen haben, bevor die Eingabeaufforderung ausgegeben wurde.

Wenn mergemaster(8) alle Systemdateien abgearbeitet hat, werden weitere Optionen abgefragt. Sie werden unter Umständen gefragt, ob Sie die Passwort-Datei neu bauen lassen wollen. Am Ende haben Sie die Möglichkeit, den Rest der temporären Dateien zu löschen.

25.7.11.2. Manueller Abgleich der Konfigurationsdateien

Wenn Sie den Abgleich lieber selbst ausführen wollen, beachten Sie bitte, dass Sie nicht einfach die Dateien aus /usr/src/etc nach /etc kopieren können. Einige dieser Dateien müssen zuerst installiert werden, bevor sie benutzt werden können. Das liegt daran, dass /usr/src/etc keine exakte Kopie von /etc ist. Zudem gibt es Dateien, die sich in /etc befinden aber nicht in /usr/src/etc.

Wenn Sie, wie empfohlen, mergemaster benutzen, können Sie direkt in den nächsten Abschnitt wechseln.

Am einfachsten ist es, wenn Sie die neuen Dateien in ein temporäres Verzeichnis installieren und sie nacheinander auf Differenzen zu den bestehenden Dateien durchsehen.

Sichern Sie die Inhalte von /etc:

Obwohl bei dieser Prozedur keine Dateien in /etc automatisch verändert werden, sollten Sie dessen Inhalt an einen sicheren Ort kopieren:

# cp -Rp /etc /etc.old

Mit -R wird rekursiv kopiert und -p erhält die Attribute der kopierten Dateien, wie Zugriffszeiten und Eigentümer.

Sie müssen die neuen Dateien in einem temporären Verzeichnis installieren. /var/tmp/root ist eine gute Wahl für das temporäre Verzeichnis, in dem auch noch einige Unterverzeichnisse angelegt werden müssen.

# mkdir /var/tmp/root
# cd /usr/src/etc
# make DESTDIR=/var/tmp/root distrib-dirs distribution

Die obigen Kommandos bauen die nötige Verzeichnisstruktur auf und installieren die neuen Dateien in diese Struktur. Unterhalb von /var/tmp/root wurden einige leere Verzeichnisse angelegt, die Sie am besten wie folgt entfernen:

# cd /var/tmp/root
# find -d . -type d | xargs rmdir 2>/dev/null

Im obigen Beispiel wurde die Fehlerausgabe nach /dev/null umgeleitet, um die Warnungen über nicht leere Verzeichnisse zu unterdrücken.

/var/tmp/root enthält nun alle Dateien, die unterhalb von / installiert werden müssen. Sie müssen nun jede dieser Dateien mit den schon existierenden Dateien vergleichen.

Einige der installierten Dateien unter /var/tmp/root beginnen mit einem .. Als dieses Kapitel verfasst wurde, waren das nur die Startdateien für die Shells in /var/tmp/root/ und /var/tmp/root/root/. Abhängig davon, wann Sie dieses Handbuch lesen, können mehr Dateien dieser Art existieren. Verwenden Sie ls -a um sicherzustellen, dass Sie alle derartigen Dateien finden.

Benutzen Sie diff(1) um Unterschiede zwischen zwei Dateien festzustellen:

# diff /etc/shells /var/tmp/root/etc/shells

Das obige Kommando zeigt Ihnen die Unterschiede zwischen der installierten Version von /etc/shells und der neuen Version in /var/tmp/root/etc/shells. Entscheiden Sie anhand der Unterschiede, ob Sie beide Dateien abgleichen oder die neue Version über die alte kopieren wollen.

Versehen Sie das temporäre Verzeichnis mit einem Zeitstempel:

Wenn Sie das System oft neu bauen, müssen Sie /etc genauso oft aktualisieren. Dies kann mit der Zeit sehr lästig werden.

Sie können das Verfahren beschleunigen, wenn Sie sich eine Kopie der Dateien behalten, die Sie zuletzt nach /etc installiert haben. Das folgende Verfahren zeigt Ihnen, wie das geht.

  1. Folgen Sie der normalen Prozedur um das System zu bauen. Wenn Sie /etc und die anderen Verzeichnisse aktualisieren wollen, geben Sie dem temporären Verzeichnis einen Namen, der das aktuelle Datum enthält. Wenn Sie dies zum Beispiel am 14. Februar 1998 durchführten, hätten Sie die folgenden Kommandos abgesetzt:

    # mkdir /var/tmp/root-19980214
    # cd /usr/src/etc
    # make DESTDIR=/var/tmp/root-19980214 \
        distrib-dirs distribution
  2. Gleichen Sie die Änderungen entsprechend der Anleitung von oben ab.

    Wenn Sie fertig sind, entfernen Sie das Verzeichnis /var/tmp/root-19980214 nicht.

  3. Wenn Sie nun neue Quellen heruntergeladen und gebaut haben, folgen Sie bitte Schritt 1. Wenn Sie zwischen den Updates eine Woche gewartet haben, haben Sie nun ein Verzeichnis mit dem Namen /var/tmp/root-19980221.

  4. Sie können nun die Unterschiede, die sich in einer Woche ergeben haben, sehen, indem Sie diff(1) rekursiv anwenden:

    # cd /var/tmp
    # diff -r root-19980214 root-19980221

    Üblicherweise sind die Differenzen, die Sie jetzt sehen, kleiner als die Differenzen zwischen /var/tmp/root-19980221/etc und /etc. Da die angezeigten Differenzen kleiner sind, ist es jetzt einfacher den Abgleich der Dateien durchzuführen.

  5. Sie können nun das älteste der beiden /var/tmp/root-* Verzeichnisse entfernen:

    # rm -rf /var/tmp/root-19980214
  6. Wiederholen Sie diesen Prozess jedes Mal wenn Sie Dateien in /etc abgleichen müssen.

Mit date(1) können Sie den Verzeichnisnamen automatisch erzeugen:

# mkdir /var/tmp/root-`date "+%Y%m%d"`

25.7.12. Das System neu starten

Sie sind nun am Ende der Prozedur angelangt. Nachdem Sie sich davon überzeugt haben, dass Ihr System funktioniert, starten Sie Ihr System mit shutdown(8) neu:

# shutdown -r now

25.7.13. Ende

Herzlichen Glückwunsch! Sie haben gerade erfolgreich Ihr FreeBSD System aktualisiert.

Es ist übrigens leicht einen Teil des Systems wiederherzustellen, für den Fall, dass Ihnen ein kleiner Fehler unterlaufen ist. Wenn Sie beispielsweise während des Updates oder Abgleichs /etc/magic aus Versehen gelöscht haben, wird file(1) nicht mehr funktionieren. In diesem Fall können Sie das Problem mit dem folgenden Kommando beheben:

# cd /usr/src/usr.bin/file
# make all install

25.7.14. Fragen

25.7.14.1. Muss ich wirklich immer alles neu bauen, wenn sich etwas geändert hat?
25.7.14.2. Der Bau bricht mit vielen Signal 11-Fehlern (oder anderen Signalnummern) ab. Was ist da passiert?
25.7.14.3. Kann ich /usr/obj löschen, wenn ich fertig bin?
25.7.14.4. Kann ein abgebrochener Bau weitergeführt werden?
25.7.14.5. Wie kann ich den Bauprozess beschleunigen?
25.7.14.6. Was mache ich, wenn etwas nicht funktioniert?

25.7.14.1.

Muss ich wirklich immer alles neu bauen, wenn sich etwas geändert hat?

Darauf gibt es keine einfache Antwort. Was zu tun ist, hängt von den Änderungen ab. Es lohnt wahrscheinlich nicht, alles neu zu bauen, wenn sich bei einem CVSup-Lauf nur die folgenden Dateien geändert haben:

src/games/cribbage/instr.c
src/games/sail/pl_main.c
src/release/sysinstall/config.c
src/release/sysinstall/media.c
src/share/mk/bsd.port.mk

In diesem Fall können Sie in die entsprechenden Unterverzeichnisse wechseln und dort make all install ausführen. Wenn sich allerdings etwas Wichtiges, wie src/lib/libc/stdlib, geändert hat, sollten Sie die Welt oder mindestens die statisch gelinkten Teile des Systems (sowie Ihre statisch gelinkten Ergänzungen) neu bauen.

Letztendlich ist das Ihre Entscheidung. Sie sind vielleicht damit zufrieden, das System alle zwei Wochen neu zu bauen und in der Zwischenzeit die anfallenden Änderungen zu sammeln. Wenn Sie sich zutrauen, alle Abhängigkeiten zu erkennen, bauen Sie vielleicht auch nur die geänderten Sachen neu.

Das hängt natürlich auch noch davon ab, wie oft Sie ein Update durchführen wollen und ob Sie FreeBSD-STABLE oder FreeBSD-CURRENT benutzen.

25.7.14.2.

Der Bau bricht mit vielen Signal 11-Fehlern (oder anderen Signalnummern) ab. Was ist da passiert?

Normalerweise zeigen diese Meldungen Hardwarefehler an. Ein Neubau der Welt ist ein guter Belastungstest für Ihre Hardware und zeigt oft Probleme mit dem Speicher auf. Dies äußert sich darin, dass der Compiler mit dem Erhalt von seltsamen Signalen abbricht.

Es liegt garantiert ein Hardwarefehler vor, wenn ein neuer Übersetzungslauf an einer anderen Stelle abbricht.

In diesem Fall können Sie nur einzelne Komponenten Ihres Systems tauschen, um zu bestimmen, welche Komponente den Fehler verursacht.

25.7.14.3.

Kann ich /usr/obj löschen, wenn ich fertig bin?

Kurze Antwort: Ja.

In /usr/obj werden alle Dateien abgelegt, die während der Übersetzungsphase erstellt wurden. Dieses Verzeichnis wird in einem der ersten Schritte der Bauprozedur entfernt. Es macht daher wenig Sinn, dieses Verzeichnis zu behalten und Sie setzen eine Menge Plattenplatz, momentan ungefähr 2 GB, frei, wenn Sie es löschen.

Wenn Sie allerdings genau wissen, was Sie tun, können Sie diesen Schritt bei make buildworld auslassen. Nachfolgende Bauprozeduren werden dadurch erheblich schneller, da die meisten Quelldateien nicht mehr neu übersetzt werden. Dafür können aber subtile Abhängigkeitsprobleme entstehen, die dazu führen, dass der Bau auf merkwürdige Weise abbrechen kann. Dies führt häufig zu unnötigen Diskussionen auf den FreeBSD Mailinglisten, wenn sich jemand über einen kaputten Bau beschwert, aber nicht sieht, dass er Probleme hat, weil er eine Abkürzung genommen hat.

25.7.14.4.

Kann ein abgebrochener Bau weitergeführt werden?

Das hängt davon ab, wieweit der Bauprozess fortgeschritten ist.

Üblicherweise werden essentielle Werkzeuge, wie gcc(1) und make(1), und die Systembibliotheken während des Bauprozesses neu erstellt (dies ist aber keine allgemein gültige Regel). Die neu erstellen Werkzeuge und Bibliotheken werden dann benutzt, um sich selbst noch einmal zu bauen, und wieder installiert. Anschließend wird das Gesamtsystem mit den neu erstellten Systemdateien gebaut.

Wenn Sie sich im letzten Schritt befinden und Sie wissen, dass Sie dort sind, weil Sie durch die Ausgaben, die Sie ja sichern, der Bauprozedur gesehen haben, können Sie mit ziemlicher Sicherheit den Bau weiterführen:

… Fehler beheben …
# cd /usr/src
# make -DNO_CLEAN all

Diese Variablen verhindern, dass make buildworld die vorher erstellten Dateien löscht.

Das Sie sich im letzten Schritt der Bauprozedur befinden, erkennen Sie daran, dass Sie in der Ausgabe die folgenden Zeilen finden:

--------------------------------------------------------------
Building everything..
--------------------------------------------------------------

Wenn Sie diese Meldung nicht finden, oder sich nicht sicher sind, dann ist es besser, noch einmal ganz von Vorne anzufangen.

25.7.14.5.

Wie kann ich den Bauprozess beschleunigen?

  • Bauen Sie im Single-User-Modus.

  • Legen Sie /usr/src und /usr/obj in getrennte Dateisysteme auf unterschiedliche Festplatten. Benutzen Sie nach Möglichkeit auch getrennte Platten-Controller.

  • Noch besser ist es, diese Dateisysteme auf mehrere Festplatten mit ccd(4) zu verteilen.

  • Bauen Sie die profiled-Bibliotheken, die Sie wahrscheinlich sowieso nicht brauchen, nicht. /etc/make.conf sollte dazu NO_PROFILE=true enthalten.

  • Setzen Sie die CFLAGS in /etc/make.conf auf -O -pipe. Die Optimierungsstufe -O2 ist deutlich langsamer und die Performance-Unterschiede zwischen -O und -O2 sind vernachlässigbar klein. -pipe veranlasst den Compiler Pipes anstelle von Dateien für die Kommunikation zu benutzen. Dies spart einige Plattenzugriffe, geht aber auf Kosten des Speichers.

  • Benutzen Sie -jn, um mehrere Prozesse parallel laufen zu lassen. Normalerweise beschleunigt dies den Bauprozess unabhängig davon, ob Sie ein Einprozessor- oder Mehrprozessorsystem einsetzen.

  • Sie können das Dateisystem /usr/src mit der Option noatime einhängen. Dies verhindert, dass die Zugriffszeiten der Dateien aktualisiert werden (eine Information, die Sie vielleicht gar nicht brauchen).

    # mount -u -o noatime /usr/src

    Warnung:

    Das Beispiel geht davon aus, dass sich /usr/src auf einem separaten Dateisystem befindet. Wenn das nicht der Fall ist, weil das Verzeichnis beispielsweise Teil des /usr Dateisystems ist, müssen Sie anstelle von /usr/src den Mountpoint des Dateisystems angeben.

  • Das Dateisystem, in dem sich /usr/obj befindet, kann mit der Option async eingehangen werden. Dies bewirkt, dass Schreibzugriffe auf die Platte asynchron stattfinden, das heißt ein Schreibzugriff ist sofort beendet, die Daten werden allerdings erst einige Sekunden später geschrieben. Dadurch können Schreibzugriffe zusammengefasst werden, was einen erheblichen Geschwindigkeitszuwachs mit sich bringen kann.

    Warnung:

    Beachten Sie, dass dies Ihr Dateisystem anfälliger für Fehler macht. Im Fall eines Stromausfalls besteht eine erhöhte Wahrscheinlichkeit, dass das Dateisystem beim Start der Maschine zerstört ist.

    Wenn sich /usr/obj auf einem extra Dateisystem befindet, ist das kein Problem. Wenn sich allerdings auf diesem Dateisystem noch andere wertvolle Daten befinden, stellen Sie sicher, dass Sie aktuelle Sicherungen besitzen.

    # mount -u -o async /usr/obj

    Warnung:

    Ersetzen Sie /usr/obj durch den Mountpoint des entsprechenden Dateisystems, wenn es sich nicht auf einem eigenen Dateisystem befindet.

25.7.14.6.

Was mache ich, wenn etwas nicht funktioniert?

Stellen Sie sicher, dass sich in Ihrer Umgebung keine Reste eines vorherigen Baus befinden. Das geht ganz einfach:

# chflags -R noschg /usr/obj/usr
# rm -rf /usr/obj/usr
# cd /usr/src
# make cleandir
# make cleandir

Ja, make cleandir muss wirklich zweimal aufgerufen werden.

Nachdem Sie aufgeräumt haben, starten Sie den Bauprozess wieder mit make buildworld.

Wenn Sie immer noch Probleme haben, schicken Sie die Fehlermeldungen und die Ausgabe von uname -a an die Mailingliste 'Fragen und Antworten zu FreeBSD' . Bereiten Sie sich darauf vor, weitere Fragen zu Ihrer Umgebung zu beantworten.

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