Sobald der lokalen Quellbaum mit einer bestimmten FreeBSD Version, z.B. FreeBSD-STABLE oder FreeBSD-CURRENT synchronisiert wurde, kann dieser dazu benutzt werden das System neu zu bauen.
Es kann nicht oft genug betont werden, wie wichtig es ist, das System zu sichern, bevor die nachfolgenden Schritte ausgeführt werden. Obwohl der Neubau des Systems eine einfache Aufgabe ist, kann dennoch vorkommen, dass Fehler im Quellbaum dazu führen, dass das System nicht mehr bootet.
Stellen Sie sicher, dass Sie eine Sicherung erstellt haben und über ein startfähiges Installationsmedium verfügen. Wahrscheinlich werden die Medien nicht benötigt, aber gehen Sie auf Nummer sicher!
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 das System eine Warnung ausgeben. Die Fehler können allerdings auch katastrophal sein und dazu führen, dass das System nicht mehr booten kann, oder Dateisysteme beschädigt werden.
Wenn 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.
Benutzer, die FreeBSD-STABLE oder FreeBSD-CURRENT benutzen und nicht die Mailinglisten FreeBSD-STABLE beziehungsweise FreeBSD-CURRENT lesen, bringen sich nur unnötig in Schwierigkeiten.
make world
: Einige ältere Dokumentationen empfehlen
make world
für den Neubau.
Das Kommando überspringt jedoch wichtige Schritte und sollte
nur von Experten verwendet werden. In fast allen Fällen ist
make world
falsch. Benutzen Sie
stattdessen die nachstehende Anleitung.
Bevor das System aktualisiert wird, lesen Sie
/usr/src/UPDATING
, um die für
die Quellcodeversion nötigen Aufgaben zu erledigen, bevor
das System neu gebaut wird. Danach kann das System mit den
folgenden Schritten aktualisiert werden.
Bei den hier dargestellten Aktualisierungsschritten wird davon ausgegangen, dass momentan eine alte FreeBSD-Version verwendet wird, 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 außerdem davon ausgegangen, dass bereits die Quellen für ein neues System bezogen wurden. Falls die Quellen nicht auf dem aktuellen Stand sind, lesen Sie Abschnitt 24.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 aufgrund von Fehlern möglicherweise nicht in der Lage, den neuen Kernel zu übersetzen. Deshalb sollte der neue Kernel mit dem neuen Compiler übersetzt werden, was bedeutet, dass der neue Compiler vor dem neuen Kernel gebaut werden muss. 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. Weitere Gründe für diese
Vorgehensweise sind hier aufgeführt:
Das alte Basissystem wird möglicherweise nicht korrekt mit dem neuen Kernel funktionieren, weshalb das neue Basissystem sofort nach der Installation des neuen Kernels installiert werden muss.
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
Dieser Ansatz nutzt den neuen
Compiler, der in /usr/obj
abgelegt
ist, um vor falschen Compiler-Kernel-Kombinationen zu
schützen.
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
. Der neue Kernel und das
neue Basissystem sind jetzt auf der Platte
installiert.
mergemaster
Aktualisiert die verbleibenden Konfigurationsdateien, da nun das neue Basissystem auf der Platte ist.
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 9.0 auf 9.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
spezielle und zusätzliche Schritte benötigen, wie
beispielsweise das umbenennen oder löschen von bestimmten
Dateien vor installworld. Lesen Sie
/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
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 das
FreeBSD-System um eine oder mehrere Hauptversionen aktualisiert
wird.
Nachdem installkernel
erfolgreich
abgeschlossen wurde, starten Sie das System durch die Eingabe
von boot -s
am Loaderprompt im
Single-User-Modus. Danach führen Sie die folgenden Kommandos
aus:
#
mount -u /
#
mount -a -t ufs
#
adjkerntz -i
#
mergemaster -p
#
cd /usr/src
#
make installworld
#
mergemaster
#
reboot
Die folgenden Abschnitte beschreiben detailliert die einzelnen Schritte, insbesondere wenn eine angepasste Kernelkonfiguration verwendet wird.
Lesen Sie vor der Aktualisierung
/usr/src/UPDATING
. Die Datei enthält
wichtige Informationen zu potentiellen Problemen, und gibt die
Reihenfolge vor, in der bestimmte Kommandos gestartet werden
müssen. Die Anweisungen in UPDATING
sind
aktueller als die in diesem Handbuch. Im Zweifelsfall folgen
Sie bitte den Anweisungen aus
UPDATING
.
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.
Die verfügbaren make(1)-Optionen werden in
make.conf(5) und
/usr/share/examples/etc/make.conf
dargestellt. Diese Einstellungen können in
/etc/make.conf
hinzugefügt werden, um das
Verhalten von make(1) beim Übersetzen von Programmen zu
beeinflussen. Änderungen an einigen Einstellungen können
weitreichende und unerwartete Auswirkungen nach sich ziehen.
Lesen Sie die Kommentare in diesen beiden Ressourcen und
beachten Sie, dass die Standardwerte aus einer Kombination von
Leistung und Sicherheit gewählt wurden.
Die in /etc/make.conf
gesetzten
Optionen wirken sich bei jedem Aufruf von make(1) aus,
einschließlich der Übersetzung von Programmen aus der
Ports-Sammlung, vom Benutzer geschriebene C-Programme oder
beim Bau des FreeBSD-Betriebssystems.
/etc/src.conf
kontrolliert den Bau
des Betriebssystems aus dem Quellcode. Im Gegensatz zu
/etc/make.conf
greifen die Optionen in
/etc/src.conf
nur dann, wenn das
FreeBSD Betriebssystem selbst gebaut wird. Die vielen Optionen
für diese Datei werden in src.conf(5) beschrieben.
Seien Sie vorsichtig mit dem Entfernen von scheinbar nicht
mehr benötigten Kernelmodulen und Optionen. Manchmal gibt es
unerwartete oder subtile Wechselwirkungen.
/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, wie beispielsweise
/etc/group
, werden für den Normalbetrieb
des Systems gebraucht.
Es gab Fälle, in denen die Installationsroutine von
make installworld
auf bestimmte
Accounts oder Gruppen angewiesen war. Bei einer
Aktualisierung ist es jedoch wahrscheinlich, dass diese
Accounts oder Gruppen noch nicht existieren. In einigen
Fällen prüft make buildworld
ob die
Accounts oder Gruppen vorhanden sind.
Um dieses Problem zu umgehen, rufen Sie
mergemaster(8) im 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.
Um im System nach Dateien zu suchen die der Gruppe gehören, die umbenannt oder gelöscht werden soll:
#
find / -group
GID
-print
Dieses Kommando zeigt alle Dateien an, die der Gruppe
GID
gehören. Dies kann entweder
ein Gruppenname oder eine numerische ID sein.
Sie können das System im Single-User-Modus übersetzen. Bei der Installation des Systems werden 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.
Bei dieser Methode übersetzen Sie das System im
Mehrbenutzermodus und wechseln anschließend 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 abgeschlossen ist. Wechseln Sie dann in
den Single-User-Modus, um
installkernel
oder
installworld
auszuführen.
Mit dem folgenden Kommando kann ein laufendes System in den Single-User-Modus gebracht werden:
#
shutdown now
Alternativ können Sie das System mit der Option „single user“ in den Single-User-Modus booten. Geben Sie dann die folgenden Befehle am Single-User-Modus Shell-Prompt 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.
Zeigt die 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 die Zeitzone richtig eingestellt ist.
Die neu gebauten Teile des Systems werden in der Voreinstellung
unter /usr/obj
gespeichert. Die Verzeichnisse
dort spiegeln die Struktur unter
/usr/src
.
Um den make buildworld
Prozess zu
beschleunigen und Ärger aufgrund von Abhängigkeiten zu
vermeiden, können Sie dieses Verzeichnis entfernen.
Einige Dateien unter /usr/obj
haben
vielleicht die immutable
-Option gesetzt, die
zuvor mit chflags(1) entfernt werden muss:
#
cd /usr/obj
#
chflags -R noschg *
#
rm -rf *
Es ist ratsam, die Ausgaben von make(1) in einer Datei zu sichern. Wenn etwas schief geht, kann eine Kopie der Fehlermeldung zu einer der FreeBSD-Mailinglisten gesendet werden.
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 Reboot aufgeräumt werden kann. Ein geeigneteres
Verzeichnis ist /var/tmp
, 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
Benutzen Sie make(1), um das Basissystem neu zu
bauen. Dieses Kommando liest Anweisungen aus einem
Makefile
, wechles beschreibt, 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
-
eine Option,
die an make(1) weitergegeben wird. Eine Liste gültiger
Optionen finden Sie in make(1).x
Das Verhalten eines Makefile
s wird von
Variablen bestimmt. Mit
-D
setzen Sie
eine Variable. Diese Variablen sind dieselben, die auch in
VARIABLE
/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
werden
verwendet, um den Bauprozess in eine Reihe von
Einzelschritten zu unterteilen.
Im Regelfall müssen make(1) keine Parameter mitgegeben werden, so dass die 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
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 gefahrlos
auf einem laufenden System bauen, da die Bauprozedur vom
Rest des Systems isoliert 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 kann NFS benutzt werden, um mehrere Maschinen
in einem Netzwerk zu aktualisieren. Um die Maschinen
A
, B
und
C
zu aktualisieren, 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, sollte es wirklich nicht mehr benutzt
werden.
Benutzen Sie stattdessen:
#
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 I/O 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 eingeben:
#
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 im Kernel konfiguriert ist, probieren Sie Werte zwischen 6 und 10 aus.
Kompilieren Sie einen neuen Kernel, um den vollen Nutzen aus dem System zu ziehen. Praktisch gesehen ist das sogar notwendig, da sich einige Datenstrukturen geändert haben und Programme wie ps(1) und 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
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 das System mit GENERIC
gebootet
wurde und sichergestellt ist, dass das System funktioniert,
kann ein neuer Kernel basierend auf einer angepassten
Konfigurationsdatei erstellt werden.
In FreeBSD müssen Sie das Basissystem neu bauen, bevor Sie einen neuen Kernel erstellen.
Verwenden Sie
KERNCONF=
,
um einen Kernel mit einer vorhandenen, angepassten
Konfigurationsdatei zu erstellen:MYKERNEL
#
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
Single-User-Modus ausführen. Andernfalls laufen diese beiden
Kommandos problemlos im Mehrbenutzermodus. Weitere
Informationen über kern.securelevel
finden
Sie in init(8). Optionen, die auf Dateien gesetzt werden
können, werden in chflags(1) detailliert
erläutert.
Booten Sie in den Single-User-Modus, um zu prüfen ob der neue Kernel funktioniert. Folgen Sie dazu den Anweisungen aus Abschnitt 24.7.6, „Wechseln Sie in den Single-User-Modus“.
Nun kann das neue System mit
installworld
installiert
werden:
#
cd /usr/src
#
make installworld
Wenn mit make buildworld
Variablen
verwendet werden, müssen dieselben Variablen auch bei
make installworld
angegeben werden. Auf
die anderen Optionen trifft das nur bedingt zu:
-j
darf mit
installworld
nicht benutzt
werden.
Haben Sie zum Bauen die folgende Kommandozeile verwendet:
#
make -DNO_PROFILE buildworld
dann installieren Sie das Ergebnis mit:
#
make -DNO_PROFILE installworld
Andernfalls würde das System bei der Installation 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.
Diese Dateien können einfach mit mergemaster(8)
aktualisiert werden. Sichern Sie
/etc
für den Fall, dass während der
Aktualisierung etwas schief geht.
mergemaster(8) ist ein Bourne-Shell Skript, das
dabei behilflich ist die Unterschiede zwischen den
Konfigurationsdateien in /etc
und denen
im Quellbaum unter /usr/src/etc
zu
finden. mergemaster
ist der empfohlene
Weg, die Systemkonfiguration mit dem Quellbaum
abzugleichen.
Um zu beginnen, rufen Sie mergemaster
auf. Ausgehend von /
wird
mergemaster
einen virtuellen Root-Baum
aufbauen und darin die neuen Konfigurationsdateien ablegen.
Diese Dateien werden dann mit den auf dem System
installierten Dateien 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 -
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.
Wenn Sie die temporäre Datei löschen, geht
mergemaster
davon aus, dass Sie die
aktuelle Datei unverändert behalten möchten. Wählen Sie die
Option 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, in dem 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 mergemaster(8) dieselbe Ausgabe, die bereits vor der Eingabeaufforderung ausgegeben wurde.
Wenn mergemaster(8) alle Systemdateien abgearbeitet hat, werden weitere Optionen abgefragt. Sie werden unter Umständen gefragt, ob die Passwort-Datei neu gebaut werden soll. Am Ende haben Sie die Möglichkeit, die restlichen 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.
/etc
: Es wird empfohlen, zuerst das bestehende
/etc
an einen sicheren Ort zu
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.
Erstellen Sie ein temporäres Verzeichnis für
die Installation der neuen Dateien in
/etc
.
#
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
Dadurch werden alle leeren Verzeichnisse entfernt. Um
die Warnungen über nicht leere Verzeichnisse zu
unterdrücken, wurde die Standardfehlerausgabe nach
/dev/null
umgeleitet.
/var/tmp/root
enthält nun alle
Dateien, die unterhalb von /
installiert werden sollten. Sie müssen nun jede dieser
Dateien mit den schon existierenden Dateien des Systems
vergleichen.
Einige der installierten Dateien unter
/var/tmp/root
beginnen mit einem
„.“. Verwenden Sie ls -a
um
sicherzustellen, dass Sie alle derartigen Dateien
finden.
Benutzen Sie diff(1), um zwei Dateien zu vergleichen:
#
diff /etc/shells /var/tmp/root/etc/shells
Dieses Kommando zeigt 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 alte Version durch die neue Version
ersetzen wollen.
/var/tmp/root
mit einem
Zeitstempel: Wenn das System oft neu gebaut wird, muss auch
/etc
genauso oft aktualisiert werden.
Dies kann mit der Zeit ein bisschen mühsam werden.
Um diesen Prozess zu beschleunigen, behalten Sie
eine Kopie der Dateien, die zuletzt nach
/etc
installiert wurden.
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.
#
mkdir /var/tmp/root-20130214
#
cd /usr/src/etc
#
make DESTDIR=/var/tmp/root-20130214 \ distrib-dirs distribution
Gleichen Sie die Änderungen entsprechend der
Anleitung von oben ab. Wenn Sie fertig sind,
entfernen Sie das Verzeichnis
/var/tmp/root-20130214
nicht.
Nachdem die neuen Quellen heruntergeladen und
gebaut haben, folgen Sie Schritt 1. Erstellen Sie
ein neues Verzeichnis mit einem aktuellen Datum.
Dieses Beispiel verwendet
/var/tmp/root-20130221
.
Vergleichen Sie die Unterschiede, die sich in einer Woche ergeben haben, indem Sie diff(1) rekursiv anwenden:
#
cd /var/tmp
#
diff -r root-20130214 root-20130221
Üblicherweise sind diese Differenzen kleiner, als
die Differenzen zwischen
/var/tmp/root-20130221/etc
und
/etc
. Da die angezeigten Differenzen
kleiner sind, ist es jetzt einfacher den Abgleich der
Dateien in /etc
durchzuführen.
Wenn Sie fertig sind, können Sie das ältere der
beiden /var/tmp/root-*
Verzeichnisse entfernen:
#
rm -rf /var/tmp/root-20130214
Wiederholen Sie diesen Prozess jedes Mal wenn Sie
Dateien in /etc
abgleichen
müssen.
Benutzen Sie date(1), um die Verzeichnisnamen automatisch zu erzeugen:
#
mkdir /var/tmp/root-`date "+%Y%m%d"`
Nachdem Sie sich davon überzeugt haben, dass alle Dateien an der richtigen Stelle sind, starten Sie das System mit shutdown(8) neu:
#
shutdown -r now
Herzlichen Glückwunsch! Sie haben gerade erfolgreich ein FreeBSD System aktualisiert.
Es ist leicht einen Teil des Systems wiederherzustellen,
für den Fall, dass Ihnen ein kleiner Fehler unterlaufen ist.
Wenn beispielsweise während des Updates oder Abgleichs
/etc/magic
aus Versehen gelöscht wurde,
wird file(1) nicht mehr funktionieren. In diesem Fall
kann das Problem mit dem folgenden Kommando behoben
werden:
#
cd /usr/src/usr.bin/file
#
make all install
24.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 svn-Lauf nur die folgenden Dateien geändert haben:
In diesem Fall können Sie in die entsprechenden
Unterverzeichnisse wechseln und dort 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 auch noch davon ab, wie oft Sie ein Update durchführen wollen und ob Sie FreeBSD-STABLE oder FreeBSD-CURRENT benutzen. | |
24.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 die Hardware und zeigt oft Probleme mit dem Speicher auf. Dies äußert sich darin, dass der Compiler mit seltsamen Signalen abbricht. Es liegt garantiert ein Hardwarefehler vor, wenn
In diesem Fall können nur einzelne Komponenten des Systems getauscht werden, um zu bestimmen, welche Komponente den Fehler verursacht. | |
24.7.14.3. | Kann |
Kurze Antwort: Ja. In Erfahrene Benutzer können
| |
24.7.14.4. | Kann ein abgebrochener Bau weitergeführt werden? |
Das hängt davon ab, wieweit der Bauprozess fortgeschritten ist. Üblicherweise werden durch
Während der letzten Phase können Sie relativ gefahrlos folgende Kommandos ausführen: … Fehler beheben … Diese Variablen verhindern,
dass Das Sie sich im letzten Schritt der Bauprozedur
befinden, erkennen Sie daran, dass Sie in der Ausgabe
von -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- Wenn diese Meldung nicht angezeigt wird, oder Sie sich nicht sicher sind, dann ist es besser, noch einmal ganz von Vorne anzufangen. | |
24.7.14.5. | Wie kann ich den Bauprozess beschleunigen? |
| |
24.7.14.6. | Was mache ich, wenn etwas nicht funktioniert? |
Stellen Sie sicher, dass sich in Ihrer Umgebung keine Reste eines vorherigen Baus befinden:
Ja, Danach starten Sie den Bauprozess wieder mit
Wenn Sie immer noch Probleme haben, schicken Sie die
Fehlermeldungen und die Ausgabe von |
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>.