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.
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, 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:
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.
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.
make installkernel
Platziert den neuen Kernel und Kernelmodule auf der Platte, was es erlaubt, mit dem frisch aktualisierten Kernel zu starten.
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.
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.
make installworld
Kopiert das Basissystem aus /usr/obj. Sie haben jetzt den neuen Kernel und das neue Basissystem auf der Festplatte.
mergemaster
Sie können nun die verbleibenden Konfigurationsdateien aktualisieren, da Sie nun das neue Basissystem auf der Platte haben.
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.
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.
Ü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.
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 -printDas obige Kommando zeigt alle Dateien an, die der Gruppe GID (dies kann entweder ein Gruppenname oder eine numerische ID sein) gehören.
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 -iDies stellt sicher, dass Ihre Zeitzone richtig eingestellt ist. Ohne dieses Kommando werden Sie vielleicht später Probleme bekommen.
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 *
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.
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.
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.
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.
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.
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:
-jdarf mit installworld nicht benutzt werden.Sie haben zum Bauen die folgende Kommandozeile verwendet:
# make -DNO_PROFILE buildworldBei der Installation setzen Sie dann das folgende Kommando ab:
# make -DNO_PROFILE installworldWü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.
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.
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.
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.oldMit
-Rwird rekursiv kopiert und-perhä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.
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 distributionGleichen Sie die Änderungen entsprechend der Anleitung von oben ab.
Wenn Sie fertig sind, entfernen Sie das Verzeichnis /var/tmp/root-19980214 nicht.
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.
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.
Sie können nun das älteste der beiden /var/tmp/root-* Verzeichnisse entfernen:
# rm -rf /var/tmp/root-19980214Wiederholen 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"`
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
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
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.
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.
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.
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.
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.
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' <de-bsd-questions@de.FreeBSD.org>.
Bereiten Sie sich darauf vor, weitere Fragen zu Ihrer Umgebung zu
beantworten.
| Zurück | Zum Anfang | Weiter |
| Synchronisation der Quellen | Nach oben | Veraltete Dateien, Verzeichnisse und Bibliotheken löschen |
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>.