Jim Mock Umstrukturiert und aktualisiert von Jordan Hubbard Im Original von Poul-Henning Kamp John Polstra Nik Clayton Martin Heinen Übersetzt von &os; wird zwischen einzelnen Releases konstant weiter entwickelt. Es gibt mehrere einfache Möglichkeiten, ein System auf dem aktuellen Stand der Entwicklung zu halten. Seien Sie jedoch gewarnt: Die neueste Version ist nicht für jeden geeignet! Dieses Kapitel hilft Ihnen bei der Entscheidung, ob Sie mit dem Entwicklungssystem Schritt halten oder ein Release verwenden wollen. Nachdem Sie dieses Kapitel gelesen haben, werden Sie den Unterschied der beiden Entwicklerversionen &os.stable; und &os.current; kennen, wissen, wie Sie Ihr System mit CVSup, CVS oder CTM aktualisieren. Wissen, wie Sie das komplette Basissystem mit make buildworld neu bauen und installieren. Bevor Sie dieses Kapitel lesen, sollten Sie Ihr Netzwerk richtig konfiguriert haben () und wissen, wie Sie Software Dritter installieren (). -CURRENT -STABLE FreeBSD besitzt zwei Entwicklungszweige: &os.current; und &os.stable;. Dieser Abschnitt beschreibt beide Zweige und erläutert, wie Sie Ihr System auf dem aktuellen Stand eines Zweiges halten. Zuerst wird &os.current; vorgestellt, dann &os.stable;. Beachten Sie im Folgenden, dass &os.current; die Spitze der Entwicklung von &os; ist. Benutzer von &os.current; sollten über sehr gute technische Fähigkeiten verfügen und in der Lage sein, schwierige Probleme alleine zu lösen. Wenn &os; neu für Sie ist, überlegen Sie sich genau, ob Sie &os.current; benutzen wollen. Snapshot &os.current; besteht aus den neuesten Quellen des FreeBSD-Systems. Es enthält Sachen, an denen gerade gearbeitet wird, experimentelle Änderungen und Übergangsmechanismen, die im nächsten offiziellen Release der Software enthalten sein können oder nicht. Obwohl &os.current; täglich von vielen Entwicklern gebaut wird, gibt es Zeiträume, in denen sich das System nicht bauen lässt. Diese Probleme werden so schnell wie möglich gelöst, aber ob Sie mit &os.current; Schiffbruch erleiden oder die gewünschten Verbesserungen erhalten, kann von dem Zeitpunkt abhängen, an dem Sie sich den Quelltext besorgt haben! &os.current; wird hauptsächlich für 3 Interessengruppen zur Verfügung gestellt: Entwickler, die an einem Teil des Quellbaums arbeiten und daher über die aktuellen Quellen verfügen müssen. Tester, die bereit sind, Zeit in das Lösen von Problemen zu investieren und sicherstellen, dass &os.current; so stabil wie möglich bleibt. Weiterhin Leute, die Vorschläge zu Änderungen oder der generellen Entwicklung von &os; machen und Patches bereitstellen, um diese Vorschläge zu realisieren. Für Leute, die die Entwicklung im Auge behalten wollen, oder die Quellen zu Referenzzwecken (zum Beispiel darin lesen, aber nicht verwenden) benutzen wollen. Auch diese Gruppe macht Vorschläge oder steuert Quellcode bei. Der schnellste Weg, neue Sachen vor dem offiziellen Release auszuprobieren. Bedenken Sie, dass der erste, der die neuen Sachen ausprobiert, auch der erste ist, der die neuen Fehler findet. Ein schneller Weg, um an Fehlerbehebungen (engl. bug fixes) zu kommen. Jede Version von &os.current; führt mit gleicher Wahrscheinlichkeit neue Fehler ein, mit der sie alte behebt. In irgendeiner Form offiziell unterstützt. Wir tun unser Bestes, um Leuten aus den drei legitimen Benutzergruppen von &os.current; zu helfen, aber wir haben einfach nicht die Zeit, technische Unterstützung zu erbringen. Das kommt nicht daher, dass wir kleinliche, gemeine Leute sind, die anderen nicht helfen wollen (wenn wir das wären, würden wir &os; nicht machen), wir können einfach nicht jeden Tag Hunderte Nachrichten beantworten und an &os; arbeiten! Vor die Wahl gestellt, &os; zu verbessern oder jede Menge Fragen zu experimentellem Code zu beantworten, haben sich die Entwickler für ersteres entschieden. -CURRENT benutzen Es ist essentiell, die Mailinglisten &a.current.name; und &a.cvsall.name; zu lesen. Wenn Sie &a.current.name; nicht lesen, verpassen Sie die Kommentare anderer über den momentanen Zustand des Systems und rennen demzufolge in viele bekannte Probleme, die schon gelöst sind. Noch kritischer ist, dass Sie wichtige Bekanntmachungen verpassen, die erhebliche Auswirkungen auf die Stabilität Ihres Systems haben können. In der &a.cvsall.name; Mailingliste sehen Sie zu jeder Änderung das Commit-Log, das Informationen zu möglichen Seiteneffekten enthält. Um diese Listen zu abonnieren (oder zu lesen) besuchen Sie bitte die Seite &a.mailman.lists.link;. Weitere Informationen erhalten Sie, wenn Sie dort auf die gewünschte Liste klicken. Beschaffen Sie sich die Quellen von einem &os;-Spiegel. Sie haben dazu zwei Möglichkeiten: cvsup cron -CURRENT mit CVSup synchronisieren Benutzen Sie das Programm cvsup mit der Datei standard-supfile aus dem Verzeichnis /usr/share/examples/cvsup. Dies ist die empfohlene Methode, da Sie die ganzen Quellen nur einmal herunterladen und danach nur noch Änderungen beziehen. Viele lassen cvsup aus cron heraus laufen, um ihre Quellen automatisch auf Stand zu bringen. Sie müssen die obige Sup-Datei anpassen und cvsup in Ihrer Umgebung konfigurieren. -CURRENT mit CTM synchronisieren CTM kommt in Frage, wenn Sie über eine schlechte Internet-Anbindung (hoher Preis oder nur E-Mail Zugriff) verfügen. Der Umgang mit CTM ist allerdings recht mühsam und Sie können beschädigte Dateien erhalten. Daher wird es selten benutzt, was wiederum dazu führt, dass es über längere Zeit nicht funktioniert. Wir empfehlen jedem mit einem 9600 bps oder schnellerem Modem, CVSup zu benutzen. Wenn Sie die Quellen einsetzen und nicht nur darin lesen wollen, besorgen Sie sich bitte die kompletten Quellen von &os.current; und nicht nur ausgesuchte Teile. Der Grund hierfür ist, dass die verschiedenen Teile der Quellen voneinander abhängen. Es ist ziemlich sicher, dass Sie in Schwierigkeiten geraten, wenn Sie versuchen, nur einen Teil der Quellen zu übersetzen. -CURRENT übersetzen Sehen Sie sich das Makefile in /usr/src genau an, bevor Sie &os.current; übersetzen. Wenn Sie &os; das erste Mal aktualisieren, sollten Sie sowohl einen Kernel als auch das System neu installieren. Lesen Sie bitte die Mailingliste &a.current; und /usr/src/UPDATING, um über Änderungen im Installationsverfahren, die manchmal vor der Einführung eines neuen Releases notwendig sind, informiert zu sein. Seien Sie aktiv! Wenn Sie &os.current; laufen lassen, wollen wir wissen, was Sie darüber denken, besonders wenn Sie Verbesserungsvorschläge oder Fehlerbehebungen haben. Verbesserungsvorschläge, die Code enthalten, werden übrigens begeistert entgegengenommen. -STABLE &os.stable; ist der Entwicklungszweig, auf dem Releases erstellt werden. Dieser Zweig ändert sich langsamer als &os.current; und alle Änderungen hier sollten zuvor in &os.current; ausgetestet sein. Beachten Sie, dass dies immer noch ein Entwicklungszweig ist und daher zu jedem Zeitpunkt die Quellen von &os.stable; verwendbar sein können oder nicht. &os.stable; ist Teil des Entwicklungsprozesses und nicht für Endanwender gedacht. Wenn Sie den FreeBSD-Entwicklungsprozess, besonders im Hinblick auf das nächste Release, verfolgen oder dazu beitragen wollen, sollten Sie erwägen, &os.stable; zu benutzen. Auch wenn sicherheitsrelevante Fehlerbehebungen in den &os.stable; Zweig einfließen, müssen Sie deswegen noch lange nicht &os.stable; verfolgen. Jeder der FreeBSD Sicherheitshinweise beschreibt für jedes betroffene Release, Das stimmt nicht ganz. Obwohl wir alte FreeBSD Releases für einige Jahre unterstützen, können wir sie nicht ewig unterstützen. Eine vollständige Beschreibung der Sicherheitspolitik für alte FreeBSD Releases entnehmen Sie bitte http://www.FreeBSD.org/security/. wie sie einen sicherheitsrelevanten Fehler beheben. Wenn Sie den Entwicklungszweig aus Sicherheitsgründen verfolgen wollen, bedenken Sie, dass Sie neben Fehlerbehebungen auch eine Vielzahl unerwünschter Änderungen erhalten werden. Obwohl wir versuchen sicherzustellen, dass der &os.stable; Zweig sich jederzeit übersetzen lässt und läuft, können wir dafür keine Garantie übernehmen. Auch wenn Neuentwicklungen in &os.current; stattfinden, ist es jedoch so, dass mehr Leute &os.stable; benutzen als &os.current; und es daher unvermeidlich ist, dass Fehler und Grenzfälle erst in &os.stable; auffallen. Aus diesen Gründen empfehlen wir Ihnen nicht, blindlings &os.stable; zu benutzen. Es ist wichtig, dass Sie &os.stable; zuerst sorgfältig in einer Testumgebung austesten, bevor Sie Ihre Produktion auf &os.stable; migrieren. Wenn Sie dies nicht leisten können, empfehlen wir Ihnen, das aktuelle FreeBSD-Release zu verwenden. Benutzen Sie dann den binären Update-Mechanismus, um auf neue Releases zu migrieren. -STABLE benutzen Lesen Sie Mailingliste &a.stable.name;, damit Sie über Abhängigkeiten beim Bau von &os.stable; und Sachen, die besondere Aufmerksamkeit erfordern, informiert sind. Umstrittene Fehlerbehebungen oder Änderungen werden von den Entwicklern auf dieser Liste bekannt gegeben. Dies erlaubt es den Benutzern, Einwände gegen die vorgeschlagenen Änderungen vorzubringen. In der &a.cvsall.name; Mailingliste sehen Sie zu jeder Änderung das Commit-Log, das Informationen zu möglichen Seiteneffekten enthält. Um diese Listen oder andere Listen zu abonnieren besuchen Sie bitte die Seite &a.mailman.lists.link;. Weitere Informationen erhalten Sie, wenn Sie dort auf die gewünschte Liste klicken. Wenn Sie ein neues System installieren und so aktuell wie möglich sein wollen, holen Sie sich einfach den neusten Snapshot von und installieren ihn wie ein normales Release. Sie können ebenfalls das neuste &os.stable; von den Spiegeln beziehen und Ihr System nach den folgenden Anweisungen aktualisieren. Wenn Sie schon ein älteres Release von &os; und das System mit dem Quellcode aktualisieren wollen, benutzen Sie einen der &os;-Spiegel. Sie haben dazu zwei Möglichkeiten: cvsup cron -STABLE mit CVSup synchronisieren Benutzen Sie das Programm cvsup mit der Datei stable-supfile aus dem Verzeichnis /usr/share/examples/cvsup. Dies ist die empfohlene Methode, da Sie die ganzen Quellen nur einmal herunterladen und danach nur noch Änderungen beziehen. Viele lassen cvsup aus cron heraus laufen, um ihre Quellen automatisch auf Stand zu bringen. Sie müssen das oben erwähnte supfile anpassen und cvsup konfigurieren. -STABLE mit CTM synchronisieren Benutzen Sie CTM. Wenn Sie über keine schnelle und billige Internet-Anbindung verfügen, sollten Sie diese Methode in Betracht ziehen. Benutzen Sie cvsup oder ftp, wenn Sie schnellen Zugriff auf die Quellen brauchen und die Bandbreite keine Rolle spielt, andernfalls benutzen Sie CTM. -STABLE übersetzen Bevor Sie &os.stable; übersetzen, sollten Sie sich das Makefile in /usr/src genau anschauen. Wenn Sie &os; das erste Mal aktualisieren, sollten Sie sowohl einen Kernel als auch das System neu installieren. Lesen Sie bitte die Mailingliste &a.stable; und /usr/src/UPDATING, um über Änderungen im Installationsverfahren, die manchmal vor der Einführung eines neuen Releases notwendig sind, informiert zu sein. Sie können eine Internet-Verbindung (oder E-Mail) dazu nutzen, Teile von &os;, wie die Quellen zu einzelnen Projekten, oder das Gesamtsystem, aktuell zu halten. Dazu bieten wir die Dienste AnonymousCVS, CVSup und CTM an. Obwohl es möglich ist, nur Teile des Quellbaums zu aktualisieren, ist die einzige unterstütze Migrationsprozedur, den kompletten Quellbaum zu aktualisieren und alles, das heißt das Userland (z.B. alle Programme in /bin und /sbin) und die Kernelquellen, neu zu übersetzen. Wenn Sie nur einen Teil der Quellen, zum Beispiel nur den Kernel oder nur die Programme aus dem Userland, aktualisieren, werden Sie oft Probleme haben, die von Übersetzungsfehlern über Kernel-Panics bis hin zu Beschädigungen Ihrer Daten reichen können. anonymous CVS Anonymous CVS und CVSup benutzen die Pull-Methode Von engl. to pull = ziehen. Der Client holt sich bei dieser Methode die Dateien ab. , um die Quellen zu aktualisieren. Im Fall von CVSup ruft der Benutzer oder ein cron-Skript cvsup auf, das wiederum mit einem cvsupd Server interagiert, um Ihre Quellen zu aktualisieren. Mit beiden Methoden erhalten Sie aktuelle Updates zu einem genau von Ihnen bestimmten Zeitpunkt. Sie können die Prozedur auf bestimmte Dateien oder Verzeichnisse einschränken, so dass Sie nur die Updates bekommen, die für Sie von Interesse sind. Die Updates werden zur Laufzeit, abhängig von den Sachen, die Sie schon haben und den Sachen, die Sie haben wollen, auf dem Server generiert. Anonymous CVS ist eine Erweiterung von CVS, die es Ihnen erlaubt, Änderungen direkt aus einem entfernten CVS-Repository zu ziehen. Anonymous CVS ist leichter zu handhaben als CVSup, doch ist letzteres sehr viel effizienter. CTM Im Gegensatz dazu vergleicht CTM Ihre Quellen nicht mit denen auf einem Server. Stattdessen läuft auf dem Server ein Skript, das Änderungen an Dateien gegenüber seinem vorigen Lauf bemerkt, die Änderungen komprimiert, mit einer Sequenznummer versieht und für das Verschicken per E-Mail kodiert (es werden nur druckbare ASCII-Zeichen verwendet). Wenn Sie diese CTM-Deltas erhalten haben, können Sie sie mit &man.ctm.rmail.1; benutzen, welches die Deltas dekodiert, verifiziert und dann die Änderungen an Ihren Quellen vornimmt. Dieses Verfahren ist viel effizienter als CVSup und erzeugt auch weniger Last auf unseren Servern, da es die Push-Methode Von engl. to push = schieben. Der Server schickt dem Client die Dateien. verwendet. Es gibt natürlich noch weitere Unterschiede, die Sie beachten sollten. Wenn Sie unabsichtlich Teile Ihres Archivs löschen, wird das von CVSup wie Anonymous CVS erkannt und repariert. Wenn sich fehlerhafte Dateien in Ihrem Quellbaum befinden, löschen Sie diese einfach und synchronisieren erneut. CTM leistet das nicht, wenn Sie Teile des Quellbaums gelöscht haben und keine Sicherung besitzen, müssen Sie von neuem, das heißt vom letzten Basis-Delta, starten und die Änderungen wieder mit CTM nachziehen. Bau des Basissystems Wenn Sie Ihren lokalen Quellbaum mit einer bestimmten FreeBSD Version (&os.stable;, &os.current;, usw.) synchronisiert haben, können Sie diesen benutzen, um das System neu zu bauen. 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, solange Sie sich an die folgende Anleitung halten, ist es unvermeidlich, dass Sie Fehler machen, oder Ihr System nicht mehr bootet, weil andere 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! Mailingliste Die &os.stable; und &os.current; Zweige befinden sich in ständiger Entwicklung. Die Leute, die zu &os; 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 &os.stable; oder &os.current; benutzen und nicht die Mailinglisten &a.stable; beziehungsweise &a.current; lesen, bringen Sie sich nur unnötig in Schwierigkeiten. Ä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. Aktualisieren Sie ein System nach der folgenden Vorschrift: &prompt.root; make buildworld &prompt.root; make buildkernel &prompt.root; make installkernel &prompt.root; reboot Fahren Sie das System in den Einbenutzermodus (beispielsweise indem Sie im Loader boot -s eingeben) und starten Sie dann die nachstehenden Kommandos: &prompt.root; mergemaster -p &prompt.root; make installworld &prompt.root; mergemaster &prompt.root; reboot 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. 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. make.conf Überprüfen Sie die Dateien /usr/share/examples/etc/make.conf (/etc/defaults/make.conf unter &os; 4.X) 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 NOPROFILE enthalten, aus /usr/share/examples/etc/make.conf (/etc/defaults/make.conf unter &os; 4.X) 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 ist der vor kurzem hinzugefügte Benutzer smmsp. Die Installationsprozedur schlug an der Stelle fehl, an der &man.mtree.8; versuchte, /var/spool/clientmqueue anzulegen. Um dieses Problem zu umgehen, vergleichen Sie die Gruppen in /usr/src/etc/group mit den auf Ihrem System vorhandenen Gruppen. Wenn sich in dieser Datei neue Gruppen befinden, kopieren Sie diese nach /etc/group. Gruppen, die in /etc/group dieselbe GID wie in /usr/src/etc/group aber einen unterschiedlichen Namen haben, sollten Sie umbenennen. Seit 4.6-RELEASE besitzt &man.mergemaster.8; einen prä-buildworld Modus, der mit -p aktiviert wird. In diesem Modus werden nur Dateien verglichen, die für den Erfolg von buildworld oder installworld essentiell sind. Wenn Ihre alte Version von mergemaster die Option -p noch nicht unterstützt, nehmen Sie beim ersten Lauf die neue Version aus dem Quellbaum: &prompt.root; cd /usr/src/usr.sbin/mergemaster &prompt.root; ./mergemaster.sh -p Wenn Sie besonders paranoid sind, sollten Sie Ihr System nach Dateien absuchen, die der Gruppe, die Sie umbenennen oder löschen, gehören: &prompt.root; find / -group GID -print Das obige Kommando zeigt alle Dateien an, die der Gruppe GID (dies kann entweder ein Gruppenname oder eine numerische ID sein) gehören. Single-User Modus Sie können das System im Single-User Modus übersetzen. Abgesehen davon, dass dies etwas schneller ist, werden bei der Installation des Systems viele wichtige Dateien, wie die Standard-Systemprogramme, die Bibliotheken und Include-Dateien, verändert. Sie bringen sich in Schwierigkeiten, wenn Sie diese Dateien auf einem laufenden System verändern, besonders dann, wenn zu dieser Zeit Benutzer auf dem System aktiv sind. Mehrbenutzermodus Eine andere Methode übersetzt das System im Mehrbenutzermodus und wechselt für die Installation 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: &prompt.root; Alternativ können Sie das System mit der Option -s in den Single-User Modus booten. Setzen Sie dann die folgenden Kommandos ab: &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; 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 Ihre CMOS-Uhr die lokale Zeit und nicht GMT an, dies erkennen Sie daran, dass &man.date.1; die falsche Zeit und eine flasche Zeitzone anzeigt, setzen Sie das folgende Kommando ab: &prompt.root; adjkerntz -i Dies stellt sicher, dass Ihre Zeitzone richtig eingestellt ist. Ohne dieses Kommando werden Sie vielleicht später Probleme bekommen. Die neugebauten 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 &man.chflags.1;) schreibgeschützt, die vor dem Löschen entfernt werden muss. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * Für den Fall, dass etwas schief geht, sollten Sie die Ausgaben von &man.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 &os;-Mailinglisten schildern. Dazu können Sie einfach das Kommando &man.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: &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … Ausgaben des Kommandos … &prompt.root; 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): &prompt.root; cd /usr/src make Zum Neubau der Welt benutzen Sie &man.make.1;. Dieses Kommando liest ein Makefile, das Anweisungen enthält, wie die Programme, aus denen &os; besteht, zu bauen sind und in welcher Reihenfolge diese zu bauen sind. Ein typischer Aufruf von make sieht wie folgt aus: &prompt.root; make -x -DVARIABLE target In diesem Beispiel ist -x eine Option, die Sie an &man.make.1; weitergeben wollen. Eine Liste gültiger Optionen finden Sie in der &man.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: &prompt.root; make -DNOPROFILE target Dieser Aufruf entspricht dem folgenden Eintrag in /etc/make.conf: NOPROFILE= 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 &man.make.1; keine Parameter mitgeben, so dass Ihre Kommandozeile wie folgt aussehen wird: &prompt.root; make target In der &os; Version 2.2.5 wurde das Ziel world in zwei Ziele aufgespalten: buildworld und installworld. Tatsächlich ist das zuerst in &os.current; passiert und wurde dann irgendwann zwischen den Versionen 2.2.2 und 2.2.5 in &os.stable; eingebaut. In der Voreinstellung wird das Ziel world ab &os; 5.3 nicht mehr funktionieren, da es in den meisten Fällen Schaden anrichtet. Mit buildworld wird ein kompletter Baum unterhalb von /usr/obj gebaut, der mit installworld auf dem System installiert werden kann. Dies ist aus zwei 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: &prompt.root; 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: &prompt.root; make -j4 buildworld &man.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. Beachten Sie bitte, dass dies noch nicht richtig unterstützt wird und dass es bei einigen Änderungen am Quellbaum zu Fehlern kommen kann. Wenn Sie diesen Parameter benutzt haben und der Bau nicht funktioniert, bauen Sie bitte noch einmal ohne den Parameter, bevor Sie ein Problem melden. Bau des Basissystems Laufzeiten Die Laufzeit eines Baus wird von vielen Faktoren beeinflusst. Ein 500 MHz &pentium; III braucht ungefähr zwei Stunden um &os.stable; zu bauen. Der Bau von &os.current; dauert etwas länger. Kernel Übersetzen 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 &man.ps.1; oder &man.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 &os;-Versionen müssen Sie das Basissystem neu bauen, bevor Sie einen neuen Kernel erstellen. 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: &prompt.root; cd /usr/src &prompt.root; make buildkernel KERNCONF=MYKERNEL &prompt.root; make installkernel KERNCONF=MYKERNEL Wenn Sie FreeBSD 4.2 oder eine ältere Version verwenden, ersetzen Sie KERNCONF= durch KERNEL=. Ab der 4.2-STABLE Version vom 2. Februar 2001 können Sie die Variable KERNCONF verwenden. 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 &man.init.8; und &man.chflags.1; erläutert Optionen, die Sie auf Dateien setzen können. Wenn Sie ein Update auf eine &os; Version vor 4.0 durchführen, sollten Sie die herkömmliche Methode benutzen. Es ist allerdings empfohlen, dazu die frisch gebaute Version von &man.config.8; zu benutzen: &prompt.root; /usr/obj/usr/src/usr.sbin/config/config KERNELNAME Single-User Modus Um zu prüfen, ob der neue Kernel funktioniert, sollten Sie in den Single-User Modus booten. Folgen Sie dazu der Anleitung aus . Wenn Sie make buildworld benutzt haben, um das System zu bauen, sollten Sie jetzt installworld benutzen, um es zu installieren. Rufen Sie dazu das folgende Kommando auf: &prompt.root; cd /usr/src &prompt.root; make installworld Wenn Sie mit dem make buildworld Kommando Variablen verwenden haben, müssen Sie dieselben Variablen auch bei dem make installworld Kommando angeben. Auf die anderen Optionen trifft das nur bedingt zu: -j darf mit installworld nicht benutzt werden. Sie haben zum Bauen die folgende Kommandozeile verwendet: &prompt.root; make -DNOPROFILE buildworld Bei der Installation setzen Sie dann das folgende Kommando ab: &prompt.root; make -DNOPROFILE installworld Würden Sie die Variable bei der Installation weglassen, so würde das System versuchen, die profiled Bibliotheken, die aber gar nicht gebaut wurden, zu installieren. 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 &man.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. Tom Rhodes Beigetragen von mergemaster Das Bourne-Shell Skript &man.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. Zwischen 3.3-RELEASE und 3.4-RELEASE wurde mergemaster in das Basissystem integriert, so dass es in allen -STABLE und -CURRENT Systemen seit der Version 3.3 vorhanden ist. 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 &man.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 &man.diff.1; genauer erklärt. &man.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 &man.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 &man.mergemaster.8; dieselbe Ausgabe, die Sie gesehen haben, bevor die Eingabeaufforderung ausgegeben wurde. Wenn &man.mergemaster.8; alle Systemdateien abgearbeitet hat, werden weitere Optionen abgefragt. Sie werden unter Umständen gefragt, ob Sie die Passwort-Datei neu bauen oder &man.MAKEDEV.8; laufen 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, lesen Sie bitte im nächsten Abschnitt weiter. 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. Obwohl bei dieser Prozedur keine Dateien in /etc automatisch verändert werden, sollten Sie dessen Inhalt an einen sicheren Ort kopieren: &prompt.root; cp -Rp /etc /etc.old Mit -R wird rekursiv kopiert und -p erhält die Attribute der kopierten Dateien, wie Zugriffszeiten und Eigentümer. Sie müssen die neuen Dateien in einem temporären Verzeichnis installieren. /var/tmp/root ist eine gute Wahl für das temporäre Verzeichnis, in dem auch noch einige Unterverzeichnisse angelegt werden müssen. &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; 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: &prompt.root; cd /var/tmp/root &prompt.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 &man.diff.1; um Unterschiede zwischen zwei Dateien festzustellen: &prompt.root; 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. 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: &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution Gleichen 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 &man.diff.1; rekursiv anwenden: &prompt.root; cd /var/tmp &prompt.root; 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: &prompt.root; rm -rf /var/tmp/root-19980214 Wiederholen Sie diesen Prozess jedes Mal wenn Sie Dateien in /etc abgleichen müssen. Mit &man.date.1; können Sie den Verzeichnisnamen automatisch erzeugen: &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` DEVFS Überspringen Sie diesen Abschnitt, wenn Sie FreeBSD 5.0 oder eine neuere Version benutzen. In diesen Versionen werden die Gerätedateien automatisch von &man.devfs.5; angelegt. In den meisten Fällen bemerkt &man.mergemaster.8; wann es notwendig ist, Gerätedateien in /dev zu erstellen. Die folgenden Anweisungen zeigen Ihnen, wie Sie dies manuell durchführen. Um sicher zu gehen, besteht dieser Prozess aus mehreren Schritten. Kopieren Sie /var/tmp/root/dev/MAKEDEV nach /dev: &prompt.root; cp /var/tmp/root/dev/MAKEDEV /dev MAKEDEV Wenn Sie &man.mergemaster.8; benutzt haben, sollte MAKEDEV schon aktualisiert sein, obwohl es nicht schadet, das mit diff zu überprüfen und die Datei, wenn nötig, manuell zu kopieren. Sichern Sie jetzt die Dateiinformationen aus /dev. Sie brauchen die Rechte, Eigentümer, sowie die Major und Minor Nummern der Gerätedateien (die Zeitstempel sind nicht wichtig). Am besten erledigen Sie das mit &man.awk.1;: &prompt.root; cd /dev &prompt.root; ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/tmp/dev.out Erstellen Sie alle Gerätedateien neu: &prompt.root; Sammeln Sie erneut die Dateiinformationen aus /dev, diesmal in der Datei /var/tmp/dev2.out ein. Vergleichen Sie beide Dateien und suchen Sie nach Gerätedateien, die nicht erstellt wurden. Sie sollten keine finden, aber es ist besser das jetzt wirklich zu kontrollieren: &prompt.root; diff /var/tmp/dev.out /var/tmp/dev2.out Wenn es doch fehlende Einträge gibt, sind dies wahrscheinlich fehlende Geräte für Slices. Diese können Sie mit einem Befehl wie dem folgenden wiederherstellen: &prompt.root; sh MAKEDEV sd0s1 Die genauen Geräte können bei Ihnen natürlich andere sein. Dieser Schritt wurde nur der Vollständigkeit wegen aufgenommen. Sie können ihn komplett auslassen. Ab &os; 5.2 werden beim Lauf von make installworld automatisch aktuelle statisch übersetzte Programme im Verzeichnis /rescue installiert. Daher ist es überflüssig, /stand zu aktualisieren. Der Vollständigkeit halber wollen Sie vielleicht auch die Dateien in /stand aktualisieren. Alle Dateien in diesem Verzeichnis sind Hardlinks zu /stand/sysinstall. Dieses Programm ist statisch gelinkt, so dass es unabhängig von den Dateien in anderen Dateisystemen, insbesondere /usr, ist. &prompt.root; cd /usr/src/release/sysinstall &prompt.root; make all install Sie sind nun am Ende der Prozedur angelangt. Nachdem Sie sich davon überzeugt haben, dass Ihr System funktioniert, booten Sie das System mit &man.shutdown.8;: &prompt.root; shutdown -r now Herzlichen Glückwunsch! Sie haben gerade erfolgreich Ihr &os; 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 &man.file.1; nicht mehr funktionieren. In diesem Fall können Sie das Problem mit dem folgenden Kommando beheben: &prompt.root; cd /usr/src/usr.bin/file &prompt.root; Muss ich wirklich immer alles neu bauen, wenn sich etwas geändert hat? Darauf gibt es keine einfache Antwort. Was zu tun ist, hängt von den Änderungen ab. Es lohnt wahrscheinlich nicht, alles neu zu bauen, wenn sich bei einem CVSup-Lauf nur die folgenden Dateien geändert haben: src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/mk/bsd.port.mk In diesem Fall können Sie in die entsprechenden Unterverzeichnisse wechseln und dort make all install ausführen. Wenn sich allerdings etwas Wichtiges, wie src/lib/libc/stdlib, geändert hat, sollten Sie die Welt oder mindestens die statisch gelinkten Teile des Systems (sowie Ihre statisch gelinkten Ergänzungen) neu bauen. Letztendlich ist das Ihre Entscheidung. Sie sind vielleicht damit zufrieden, das System alle zwei Wochen neu zu bauen und in der Zwischenzeit die anfallenden Änderungen zu sammeln. Wenn Sie sich zutrauen, alle Abhängigkeiten zu erkennen, bauen Sie vielleicht auch nur die geänderten Sachen neu. Das hängt natürlich auch noch davon ab, wie oft Sie ein Update durchführen wollen und ob Sie &os.stable; oder &os.current; benutzen. Der Bau bricht mit vielen Signal 11-Fehlern (oder anderen Signalnummern) ab. Was ist da passiert? Signal 11 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 Kompiler 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. Kann ich /usr/obj löschen, wenn ich fertig bin? Kurze Antwort: Ja. In /usr/obj werden alle Dateien abgelegt, die während der Übersetzungsphase erstellt wurden. Dieses Verzeichnis wird in einem der ersten Schritte der Bauprozedur entfernt. Es macht daher wenig Sinn, dieses Verzeichnis zu behalten und Sie setzen eine Menge Plattenplatz, momentan ungefähr 340 MB, 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 &os; Mailinglisten, wenn sich jemand über einen kaputten Bau beschwert, aber nicht sieht, dass er Probleme hat, weil er eine Abkürzung genommen hat. Kann ein abgebrochener Bau weitergeführt werden? Das hängt davon ab, wieweit der Bauprozess fortgeschritten ist. Üblicherweise werden essentielle Werkzeuge, wie &man.gcc.1; und &man.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 … &prompt.root; cd /usr/src &prompt.root; make -DNOCLEAN all Die Variable NOCLEAN verhindert, 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. Wie kann ich den Bauprozesss beschleunigen? Bauen Sie im Single-User Modus. Legen Sie /usr/src und /usr/obj in getrennte Dateisysteme auf unterschiedliche Festplatten. Benutzen Sie nach Möglichkeit auch getrennte Platten-Controller. Noch besser ist es, diese Dateisysteme auf mehrere Festplatten mit &man.ccd.4; zu verteilen. Bauen Sie die profiled-Bibliotheken, die Sie wahrscheinlich sowieso nicht brauchen, nicht. /etc/make.conf sollte dazu NOPROFILE=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 Kompiler 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 Mehrprozessor System 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). &prompt.root; mount -u -o noatime /usr/src 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. 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. &prompt.root; mount -u -o async /usr/obj Ersetzen Sie /usr/obj durch den Mountpoint des entsprechenden Dateisystems, wenn es sich nicht auf einem eigenen Dateisystem befindet. Was mache ich, wenn etwas nicht funktioniert? Stellen Sie sicher, dass sich in Ihrer Umgebung keine Reste eines vorherigen Baus befinden. Das geht ganz einfach: &prompt.root; chflags -R noschg /usr/obj/usr &prompt.root; rm -rf /usr/obj/usr &prompt.root; cd /usr/src &prompt.root; make cleandir &prompt.root; 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 &a.de.questions;. Bereiten Sie sich darauf vor, weitere Fragen zu Ihrer Umgebung zu beantworten. Mike Meyer Beigetragen von Wenn Sie mehrere Maschinen besitzen, die Sie alle auf dem gleichen Stand halten wollen, ist es eine Verschwendung von Ressourcen, die Quellen auf jeder Maschine vorzuhalten und zu übersetzen. Die Lösung dazu ist, eine Maschine den Großteil der Arbeit durchführen zu lassen und den anderen Maschinen das Ergebnis mit NFS zur Verfügung zu stellen. Dieser Abschnitt zeigt Ihnen wie das geht. Stellen Sie zuerst eine Liste der Maschinen zusammen, die auf demselben Stand sein sollen. Wir nennen diese Maschinen die Baugruppe. Jede dieser Maschinen kann mit einem eigenen Kernel laufen, doch sind die Programme des Userlands auf allen Maschinen gleich. Wählen Sie aus der Baugruppe eine Maschine aus, auf der der Bau durchgeführt wird, den Bau-Master. Dies sollte eine Maschine sein, die über die nötigen Ressourcen für make buildworld und make installworld verfügt. Sie brauchen auch eine Testmaschine, auf der Sie die Updates testen, bevor Sie sie in Produktion installieren. Dies sollte eine Maschine, eventuell der Bau-Master, sein, die über einen längeren Zeitraum nicht zur Verfügung stehen kann. Alle Maschinen der Baugruppe müssen /usr/obj und /usr/src von derselben Maschine an gleichem Ort einhängen. Idealerweise befinden sich die beiden Verzeichnisse auf dem Bau-Master auf verschiedenen Festplatten, sie können allerdings auch auf dem Bau-Master über NFS zur Verfügung gestellt werden. Wenn Sie mehrere Baugruppen haben, sollte sich /usr/src auf einem Bau-Master befinden und über NFS für den Rest der Maschinen zur Verfügung gestellt werden. Stellen Sie sicher, dass /etc/make.conf auf allen Maschinen einer Baugruppe mit der Datei des Bau-Masters übereinstimmt. Der Bau-Master muss jeden Teil des Systems bauen, den irgendeine Maschine der Baugruppe benötigt. Auf dem Bau-Master müssen in /etc/make.conf alle zu bauenden Kernel mit der Variablen KERNCONF bekannt gegeben werden. Geben Sie dabei den Kernel des Bau-Masters zuerst an. Für jeden zu bauenden Kernel muss auf dem Bau-Master die entsprechende Konfigurationsdatei unter /usr/src/sys/arch/conf abgelegt werden. Nach diesen Vorbereitungen können Sie mit dem Bau beginnen. Bauen Sie auf dem Bau-Master, wie in beschrieben, den Kernel und die Welt, installieren Sie aber nichts. Wechseln Sie auf die Testmaschine und installieren Sie den gerade gebauten Kernel. Wenn diese Maschine /usr/src und /usr/obj über NFS bekommt, müssen Sie das Netzwerk im Single-User Modus aktivieren und die beiden Dateisysteme einhängen. Am einfachsten ist dies, wenn Sie auf der Testmaschine ausgehend vom Mehrbenutzermodus mit shutdown now in den Single-User Modus wechseln. Sie können dann mit der normalen Prozedur den neuen Kernel und das System installieren und anschließend mergemaster laufen lassen. Wenn Sie damit fertig sind, können Sie die Maschine wieder in den Mehrbenutzermodus booten. Nachdem Sie sichergestellt haben, dass die Testmaschine einwandfrei funktioniert, wiederholen Sie diese Prozedur für jede Maschine in der Baugruppe. Dasselbe Verfahren können Sie auch für die Ports-Sammlung anwenden. Zuerst müssen alle Maschinen einer Baugruppe /usr/ports von derselben Maschine über NFS zur Verfügung gestellt bekommen. Setzen Sie dann ein Verzeichnis für die Quellen auf, das sich alle Maschinen teilen. Dieses Verzeichnis können Sie in /etc/make.conf mit der Variablen DISTDIR angeben. Das Verzeichnis sollte für den Benutzer beschreibbar sein, auf den der Benutzer root vom NFS Subsystem abgebildet wird. Jede Maschine sollte noch WRKDIRPREFIX auf ein lokales Bauverzeichnis setzen. Wenn Sie vorhaben, Pakete zu bauen und zu verteilen, sollten Sie PACKAGES auf ein Verzeichnis mit den gleichen Eigenschaften wie DISTDIR setzen.