24.6. Das komplette Basissystem neu bauen

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. Dieser Prozess wird auch als die Welt neu bauen bezeichnet.

Bevor das System neu gebaut wird, müssen die folgende Aufgaben erledigt werden:

Prozedur 24.1. Führen Sie diese Aufgaben aus, bevor das System neu gebaut wird
  1. Sichern Sie alle wichtigen Daten auf ein anderes System oder auf Wechselmedien und überprüfen Sie die Integrität der Sicherungskopie. Zudem sollten Sie bootfähige Installationsmedien zur Hand haben. Es kann nicht oft genug betont werden, wie wichtig es ist, vor dem Neubau des Systems eine Sicherung zu machen. Während der Neubau des Systems eine einfache Aufgabe ist, wird es zwangsläufig einmal vorkommen, dass Fehler im Quellcode dazu führen, dass das System nicht mehr bootet. Wahrscheinlich wird die Sicherungskopie nicht benötigt, aber gehen Sie auf Nummer sicher!

  2. Lesen Sie die neuesten Einträge in FreeBSD-STABLE oder FreeBSD-CURRENT, je nachdem welchen Zweig Sie folgen. Informieren Sie sich über bekannte Probleme und welche Systeme davon betroffen sind. Wenn ein Problem für den von Ihnen synchronisierten Code besteht, warten Sie auf eine all clear-Nachricht, die besagt, dass das Problem behoben wurde. Synchronisieren Sie dann die Quellen neu um sicherzustellen, dass die lokale Version die benötigten Korrekturen hat.

  3. Lesen Sie /usr/src/UPDATING für zusätzliche Aufgaben, die für diese Version des Quellcodes notwendig sind. Diese Datei enthält wichtige Informationen über potentielle Probleme. Gegebenenfalls müssen einige Kommandos in einer bestimmten Reihenfolge ausgeführt werden. Manche Aktualisierungen erfordern bestimmte zusätzliche Schritte, die ausgeführt werden müssen, bevor das System neu gebaut wird, wie beispielsweise das umbenennen oder löschen von bestimmten Datein. Diese Aufgaben sind am Ende der Datei aufgeführt. Die Anweisungen in UPDATING sind aktueller als die in diesem Handbuch. Im Zweifelsfall folgen Sie bitte den Anweisungen aus UPDATING.

Verwenden Sie nicht 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.

24.6.1. Übersicht

Dieser Prozess geht davon aus, dass ein System von einer älteren Version von FreeBSD auf eine neuere Version aktualisiert wird. Der Quellcode für die neue Version wurde nach den Anweisungen in Abschnitt 24.5, „Synchronisation der Quellen“ synchronisiert.

Das Basissystem enthält den FreeBSD-Kernel, die zentralen Binärdateien, Bibliotheken und Entwicklerdateien sowie einen integrierten Compiler. Die Reihenfolge, in der diese Komponenten gebaut werden, ist wichtig.

Beispielsweise könnte der alte Compiler aufgrund von Fehlern nicht in der Lage sein, den neuen Kernel zu übersetzen. Da der neue Kernel mit dem neuen Compiler übersetzt wird, muss der neue Compiler gebaut, aber nicht notwendigerweise installiert werden, bevor der neue Kernel gebaut wird.

Das neue Basissystem ist eventuell auf neue Funktionen des Kernels angewiesen. Aus diesem Grund muss der neue Kernel installiert sein, bevor das neue Basissystem installiert wird.

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 Großteil Dateien oder fügt neue hinzu, bestehende Dateien werden nicht gelöscht. Da dieser Prozess Probleme verursachen kann, werden in /usr/src/UPDATING gegebenenfalls Dateien aufgelistet, die manuell entfernt werden müssen.

Diese Bedenken haben zu einer empfohlenen Reihenfolge bei der Aktualisierung geführt, die im folgenden Prozess beschrieben wird.

Prozedur 24.2. Zusammenfassung des Aktualisierungsprozesses

Die verwendeten Kommandos sollten in der hier angegebenen Reihenfolge ausgeführt werden. Die Funktionen der einzelnen Kommandos werden in diesem Abschnitt beschrieben.

  1. Wenn der Bauprozess bereits einmal auf diesem System durchgeführt wurde, existiert vielleicht noch eine Kopie davon in /usr/obj. Um den neuen Bauprozess zu beschleunigen und Ärger aufgrund von Abhängigkeiten zu vermeiden, kann dieses Verzeichnis entfernt werden:

    # chflags -R noschg /usr/obj/*
    # rm -rf /usr/obj
  2. Übersetzen Sie zuerst den neuen Compiler und ein paar damit zusammenhängende Werkzeuge. Verwenden Sie dann den neuen Compiler, um den Rest des Basissystems zu erstellen. Das Ergebnis wird in /usr/obj abgelegt.

    # cd /usr/src
    # make buildworld
  3. Benutzen Sie den neuen Compiler aus /usr/obj, um sich vor falschen Compiler-Kernel-Kombinationen abzusichern.

    # make buildkernel
  4. Installieren Sie den neuen Kernel und die Kernelmodule, damit Sie den frisch aktualisierten Kernel starten können.

    # make installkernel
  5. Starten Sie das System in den Single-User-Modus, damit Probleme mit der Aktualisierung von Programmen, die bereits gestartet sind, minimiert werden. Ebenso minimiert dieser Modus Probleme, die mit der Verwendung des alten Basissystems und des neuen Kernels zu tun haben.

    # shutdown now

    Führen Sie folgende Befehle im Single-User-Modus aus, wenn das System mit einem UFS-Dateisystem formatiert ist:

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

    Wenn das System mit ZFS formatiert ist, führen Sie stattdessen folgende Befehle aus. In diesem Beispiel ist der Name des Pools zroot:

    # zfs set readonly=off zroot
    # zfs mount -a
  6. Optional: Wenn eine andere Tastaturbelegung als US-Englisch gewünscht wird, kann diese mit kbdmap(1) angepasst werden:

    # kbdmap
  7. Führen Sie folgenden Befehl aus, wenn die CMOS-Uhr auf die lokale Zeit eingestellt ist (dies ist der Fall, wenn die Ausgabe von date(1) nicht die richtige Zeit anzeigt):

    # adjkerntz -i
  8. Bei der Aktualisierung des Basissystems werden bestimmte Verzeichnisse, wie /etc, /var und /usr ausgelassen. Im nächsten Schritt werden ein paar initiale Konfigurationsdateien zur Vorbereitung für das neue Basissystem aktualisiert. Der folgende Befehl aktualisiert lediglich Dateien, die für das Gelingen von installworld unerlässlich sind. Beispielsweise können neue Gruppen, Systembenutzerkonten, oder neue Startskripten erstellt werden, die seit der letzten Aktualisierung hinzugefügt wurden. Dieser Schritt ist notwendig, damit installworld in der Lage ist, die neuen Konten, Gruppen und Skripten zu verwenden. Weitere Informationen zu diesem Befehl finden Sie in Abschnitt 24.6.11.1, „mergemaster:

    # mergemaster -p
  9. Installieren Sie das neue Basissystem aus /usr/obj:

    # cd /usr/src
    # make installworld
  10. Aktualisieren Sie die verbleibenden Konfigurationsdateien:

    # mergemaster -iF
  11. Löschen Sie veraltete Dateien. Dieser Schritt ist wichtig, da alte Dateien manchmal Probleme bereiten, falls sie nicht entfernt werden:

    # make delete-old
  12. Nun wird ein Neustart benötigt, um den neuen Kernel und das neue Basissystem zu laden:

    # reboot
  13. Stellen Sie sicher, dass alle Ports neu gebaut wurden, bevor die alten Bibliotheken entfernt werden. Verwenden Sie dazu die Anweisungen aus Abschnitt 5.5.3, „Ports aktualisieren“. Entfernen Sie anschließend alle veralteten Bibliotheken um Konflikte mit den neuen Bibliotheken zu vermeiden.

    # make delete-old-libs

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

Die folgenden Abschnitte beschreiben detailliert die einzelnen Schritte, insbesondere wenn eine angepasste Kernelkonfiguration verwendet wird.

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.

24.6.3. /etc/src.conf überprüfen

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

24.6.4. Aktualisieren Sie die Dateien in /etc

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

Tipp:

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.

24.6.5. Wechseln Sie in den Single-User-Modus

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.

Anmerkung:

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.

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

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 *

24.6.7. Übersetzen der Quellen des Basissystems

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 -x eine Option, die an make(1) weitergegeben wird. Eine Liste gültiger Optionen finden Sie in make(1).

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

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.

24.6.8. Übersetzen und Installation des Kernels

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.

Anmerkung:

Verwenden Sie KERNCONF=MYKERNEL, um einen Kernel mit einer vorhandenen, angepassten Konfigurationsdatei zu erstellen:

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

24.6.9. Booten Sie in den Single-User-Modus

Booten Sie in den Single-User-Modus, um zu prüfen ob der neue Kernel funktioniert. Folgen Sie dazu den Anweisungen aus Abschnitt 24.6.5, „Wechseln Sie in den Single-User-Modus“.

24.6.10. Installation des Systems

Nun kann das neue System mit installworld installiert werden:

# cd /usr/src
# make installworld

Anmerkung:

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.

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

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.

24.6.11.1. mergemaster

Beigetragen von Tom Rhodes.

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.

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

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.

Versehen Sie das temporäre Verzeichnis /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.

  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.

    # mkdir /var/tmp/root-20130214
    # cd /usr/src/etc
    # make DESTDIR=/var/tmp/root-20130214 \
        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-20130214 nicht.

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

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

  5. Wenn Sie fertig sind, können Sie das ältere der beiden /var/tmp/root-* Verzeichnisse entfernen:

    # rm -rf /var/tmp/root-20130214
  6. 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"`

24.6.12. Veraltete Dateien und Verzeichnisse löschen

Basiert auf Notizen von Anton Shterenlikht.

Aufgrund der ständigen Weiterentwicklung von FreeBSD kann es dazu kommen, dass Dateien und deren Inhalte obsolet werden, weil deren Funktionalität entweder in anderen Dateien implementiert wurde, sich die Versionsnummer der Bibliothek geändert hat oder deren Funktion nicht mehr benötigt wird. Dies kann sowohl Dateien und Verzeichnisse, aber auch Bibliotheken betreffen. Diese veralteten Dateien sollten daher entfernt werden, wenn das System aktualisiert wird. Der Vorteil besteht darin, dass das System von nicht mehr benötigten Dateien befreit wird. Falls die obsolete Bibliothek Sicherheits- oder Stabilitätsprobleme aufweist, sollte das System ebenfalls aktualisiert werden, um das System sicher zu halten und/oder durch die fehlerhafte Bibliothek verursachte Systemabstürze zu vermeiden. Veraltete Dateien, Verzeichnisse und Bibliotheken sind in /usr/src/ObsoleteFiles.inc aufgelistet. Verwenden Sie die folgenden Anweisungen, um diese Dateien während der Systemaktualisierung zu entfernen.

Nachdem Sie make installworld sowie mergemaster erfolgreich ausgeführt haben, überprüfen Sie das System auf veraltete Dateien und Bibliotheken:

# cd /usr/src
# make check-old

Werden dabei veraltete Dateien gefunden, können diese mit dem folgenden Kommando entfernt werden:

# make delete-old

Tipp:

Weitere interessante targets finden Sie in /usr/src/Makefile.

Bei jeder Datei wird nachgefragt, ob diese wirklich gelöscht werden soll. Es ist aber auch möglich, alle Dateien automatisch löschen zu lassen. Dies erreichen Sie, indem Sie die Umgebungsvariable BATCH_DELETE_OLD_FILES setzen:

# make -DBATCH_DELETE_OLD_FILES delete-old

Alternativ können Sie auch yes einsetzen und somit die Antwort yes an die einzelnen Abfragen weiterreichen:

# yes | make delete-old

24.6.13. Das System neu starten

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

24.6.14. Löschen von veralteten Bibliotheken

Warnung:

Das Löschen veralteter Dateien kann dazu führen, dass Programme, die auf diese Dateien angewiesen sind, nicht mehr funktionieren. Dies gilt insbesondere für veraltete Bibliotheken. In den meisten Fällen ist es dann notwendig, Programme, Ports und Bibliotheken, welche die veraltete Bibliothek verwenden, neu zu bauen, bevor Sie den Befehl make delete-old-libs ausführen.

Die Ports-Sammlung enthält Werkzeuge, die Bibliothek-Abhängigkeiten prüfen können: sysutils/libchk sowie sysutils/bsdadminscripts.

Veraltete Bibliotheken können zu Konflikten mit neueren Bibliotheken führen und beispielsweise folgende Meldungen verursachen:

/usr/bin/ld: warning: libz.so.4, needed by /usr/local/lib/libtiff.so, may conflict with libz.so.5
/usr/bin/ld: warning: librpcsvc.so.4, needed by /usr/local/lib/libXext.so, may conflict with librpcsvc.so.5

Um diese Probleme zu lösen, müssen Sie zuerst herausfinden, welcher Port die Bibliothek installiert hat:

# pkg which /usr/local/lib/libtiff.so
/usr/local/lib/libtiff.so was installed by package tiff-3.9.4
# pkg which /usr/local/lib/libXext.so
/usr/local/lib/libXext.so was installed by package libXext-1.1.1,1

Danach deinstallieren Sie den Port und bauen ihn neu, um ihn danach erneut zu installieren. Dieser Vorgang kann durch den Einsatz von ports-mgmt/portmaster automatisiert werden. Nachdem alle Ports neu gebaut wurden und keine alten alten Bibliotheken mehr verwenden werden, können Sie die alten Bibliotheken endgültig entfernen:

# make delete-old-libs

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

24.6.15.1. Muss ich wirklich immer alles neu bauen, wenn sich etwas geändert hat?
24.6.15.2. Der Bau bricht mit vielen Signal 11 Fehlern (oder anderen Signalnummern) ab. Was ist da passiert?
24.6.15.3. Kann /usr/obj entfernt werden, wenn ich fertig bin?
24.6.15.4. Kann ein abgebrochener Bau weitergeführt werden?
24.6.15.5. Wie kann ich den Bauprozess beschleunigen?
24.6.15.6. Was mache ich, wenn etwas nicht funktioniert?

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

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 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 auch noch davon ab, wie oft Sie ein Update durchführen wollen und ob Sie FreeBSD-STABLE oder FreeBSD-CURRENT benutzen.

24.6.15.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 make neu gestartet wird und an einer anderen Stelle abbricht.

In diesem Fall können nur einzelne Komponenten des Systems getauscht werden, um zu bestimmen, welche Komponente den Fehler verursacht.

24.6.15.3.

Kann /usr/obj entfernt werden, 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 von make buildworld entfernt. Es macht daher wenig Sinn, dieses Verzeichnis zu behalten. Zudem wird ungefähr 2 GB Plattenspeicher freigegeben, wenn dieses Verzeichnis gelöscht wird.

Erfahrene Benutzer können make buildworld anweisen, diesen Schritt zu überspringen. Nachfolgende Bauprozeduren werden dadurch erheblich schneller, da die meisten Quelldateien nicht mehr neu übersetzt werden müssen. 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.

24.6.15.4.

Kann ein abgebrochener Bau weitergeführt werden?

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

Üblicherweise werden durch make buildworld essentielle Werkzeuge, wie gcc(1) und make(1), und die Systembibliotheken neu erstellt. Die neu erstellten Werkzeuge und Bibliotheken werden dann benutzt, um sich selbst noch einmal zu bauen, und wieder installiert. Anschließend wird das Gesamtsystem, einschließlich der normalen Benutzerprogramme wie ls(1) und grep(1), mit den neu erstellten Systemdateien gebaut.

Während der letzten Phase können Sie relativ gefahrlos folgende Kommandos ausfü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 von make buildworld die folgenden Zeilen finden:

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

  • Alternativ können diese Dateisysteme mit ccd(4) auf mehrere Festplatten verteilt werden.

  • Deaktivieren Sie den Bau der profiled-Bibliotheken, indem Sie NO_PROFILE=true in /etc/make.conf aufnehmen.

  • Benutzen Sie make zusammen mit -jn, um mehrere Prozesse parallel laufen zu lassen. Normalerweise beschleunigt dies den Bauprozess auf Einprozessor- und Mehrprozessorsystemen.

  • Das Dateisystem /usr/src kann mit der Option noatime eingehangen werden. Dies verhindert, dass die Zugriffszeiten der Dateien aktualisiert werden.

    # mount -u -o noatime /usr/src

    Warnung:

    Das Beispiel geht davon aus, dass sich /usr/src auf einem separaten Dateisystem befindet. Wenn es Teil des /usr Dateisystems ist, muss dieses Dateisystem als Mountpoint angegeben werden.

  • Das Dateisystem, in dem sich /usr/obj befindet, kann mit async eingehangen werden, so 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 das 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 /usr/obj das einzige Verzeichnis auf auf diesem Dateisystem ist, stellt das kein Problem dar. Wenn sich allerdings auf diesem Dateisystem noch andere wertvolle Daten befinden, stellen Sie sicher, dass Sie über aktuelle Sicherungen verfügen.

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

24.6.15.6.

Was mache ich, wenn etwas nicht funktioniert?

Stellen Sie sicher, dass sich in Ihrer Umgebung keine Reste eines vorherigen Baus befinden:

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

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