diff --git a/de_DE.ISO8859-1/books/handbook/cutting-edge/chapter.sgml b/de_DE.ISO8859-1/books/handbook/cutting-edge/chapter.sgml new file mode 100644 index 0000000000..8c8f9dfe10 --- /dev/null +++ b/de_DE.ISO8859-1/books/handbook/cutting-edge/chapter.sgml @@ -0,0 +1,1930 @@ + + + + + + + Jim + Mock + Umstrukturiert und aktualisiert von + + + + + + Jordan + Hubbard + Im Original von + + + Poul-Henning + Kamp + + + John + Polstra + + + Nik + Clayton + + + + + + Martin + Heinen + Übersetzt von + + + + + Das Neueste und Beste + + + Übersicht + + &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 mit make world das + komplette Basissystem wieder neu bauen und installieren + können. + + + + Bevor Sie dieses Kapitel lesen, sollten Sie + + + Ihr Netzwerk richtig konfiguriert haben und + + wissen, wie Sie Software Dritter installieren + (). + + + + + + &os.current; vs. &os.stable; + -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;. + + + &os.current; + + Beachten Sie im folgenden, daß &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. + + + Was ist &os.current;? + 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äßt. 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! + + + + Wer braucht &os.current;? + + &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, daß + &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. + + + + + + Was &os.current; <emphasis>nicht</emphasis> ist! + + + + Der schnellste Weg, neue Sachen vor dem offiziellen + Release auszuprobieren. Bedenken Sie, daß 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, daß 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. + + + + + + Benutzen von &os.current; + + + + Es ist essentiell, die Mailinglisten + &a.current; und &a.cvsall; zu lesen. Wenn Sie + &a.current; 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, daß Sie wichtige + Bekanntmachungen verpassen, die entscheidende Auswirkungen + auf die Stabilität Ihres Systems haben können. + + In der &a.cvsall; Mailingliste sehen Sie zu jeder + Änderung das Commit-Log, das Informationen zu + möglichen Seiteneffekten enthält. + + Um diese Listen zu lesen, senden Sie eine E-Mail + mit dem folgenden Inhalt im Textkörper der Nachricht + an &a.majordomo;: + + subscribe freebsd-current +subscribe cvs-all + + majordomo + + + Sie können Majordomo auch + den Text help schicken und erhalten dann + eine ausführliche Hilfe, die beschreibt, wie Sie die + verschiedenen Mailinglisten abonnieren bzw. wieder + abbestellen. + + + + Beschaffen Sie sich die Quellen von + ftp.FreeBSD.org. Sie haben dazu + drei Möglichkeiten: + + + + cvsup + + + cron + + + -CURRENT + Synchronisation mit CVSup + + + + Benutzen Sie cvsup mit + + einer geeigneten Sup-Datei. 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. + Sie können sich die Arbeit vereinfachen, indem Sie + das folgende Kommando absetzen: + + &prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/packages/All/cvsupit-3.0.tgz + + + + -CURRENT + Herunterladen mit ftp + + + + Benutzen Sie ftp. Der Quellbaum + für &os.current; ist unter ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/ + erhältlich. Einige FTP-Spiegel unterstützen + das Herunterladen von komprimierten mit + tar gepackten Dateibäumen. + Wenn Sie beispielsweise das Verzeichnis + usr.bin/lex als + tar-Datei herunterladen wollen, geben + Sie folgendes ein: + + ftp> cd usr.bin +ftp> get lex.tar + + + + -CURRENT + Synchronisation mit CTM + + + Benutzen Sie + CTM. + 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, daß 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, + daß die verschiedenen Teile der Quellen voneinander + abhängen. Es ist ziemlich sicher, daß Sie in + Schwierigkeiten geraten, wenn Sie versuchen, nur einen Teil + der Quellen zu übersetzen. + + Bevor Sie &os.current; übersetzen, sollten Sie sich + das Makefile in + /usr/src genau anschauen. Wenn Sie Ihr + System das erste Mal aktualisieren, sollten Sie mindestens + make world laufen lassen. + Lesen Sie bitte die Mailingliste &a.current;, 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. + + + + + + + &os.stable; + + + Was ist &os.stable;? + -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, daß 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. + + + + Wer braucht &os.stable;? + + Wenn Sie den FreeBSD Entwicklungsprozeß, 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, daß Sie neben + Fehlerbehebungen auch eine Vielzahl unerwünschter + Änderungen erhalten werden. + + Obwohl wir versuchen sicherzustellen, daß der + &os.stable; Zweig sich jederzeit übersetzen läßt + und läuft, können wir dafür keine Garantie + übernehmen. Auch wenn Neuentwicklungen in &os.current; + stattfinden, ist es jedoch so, daß mehr Leute + &os.stable; benutzen als &os.current; und es daher unvermeidlich + ist, daß 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, daß 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. + + + + Benutzen von &os.stable; + + + -STABLE + benutzen + + + + Lesen Sie Mailingliste &a.stable;, 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 bekanntgegeben. Dies + erlaubt es den Benutzern, Einwände gegen die + vorgeschlagenen Änderungen vorzubringen. + + In der &a.cvsall; Mailingliste sehen Sie zu jeder + Änderung das Commit-Log, das Informationen zu + möglichen Seiteneffekten enthält. + + Um diese Listen zu lesen, senden Sie eine E-Mail + mit dem folgenden Inhalt im Textkörper der Nachricht + an &a.majordomo;: + + subscribe freebsd-stable +subscribe cvs-all + + + majordomo + + Sie können Majordomo auch + den Text help schicken und erhalten dann + eine ausführliche Hilfe, die beschreibt, wie Sie die + verschiedenen Mailinglisten abonnieren bzw. wieder + abbestellen. + + + + Wenn Sie ein neues System installieren und so aktuell wie + möglich sein wollen, holen Sie sich einfach den neusten + Snapshot von ftp://releng4.FreeBSD.org/pub/FreeBSD/ + und installieren ihn wie ein normales Release. + + Wenn Sie schon ein älteres Release von &os; + benutzen und mit dem Quellcode migrieren wollen, stehen Ihnen + dazu ausgehend von ftp.FreeBSD.org + drei Möglichkeiten zur Verfügung: + + + + -STABLE + Synchronisation mit CVSup + + + Benutzen Sie cvsup mit + + einer geeigneten Sup-Datei. 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. Wenn Sie dazu + eine einfache Schnittstelle benötigen, geben sie + folgendes ein: + +
&prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
+ + + + -STABLE + Herunterladen mit ftp + + + Benutzen Sie ftp. Der Quellbaum + für &os.stable; ist unter ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-stable/ + erhältlich. Einige FTP-Spiegel unterstützen + das Herunterladen von komprimierten mit + tar gepackten Dateibäumen. + Wenn Sie beispielsweise das Verzeichnis + usr.bin/lex als + tar-Datei herunterladen wollen, geben + Sie folgendes ein: + + ftp> cd usr.bin +ftp> get lex.tar + + + + -STABLE + Synchronisation mit CTM + + + 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 Ihr + System das erste Mal aktualisieren, sollten Sie mindestens + make world laufen lassen. + Lesen Sie bitte die Mailingliste &a.stable;, um über + Änderungen im Installationsverfahren, die manchmal + vor der Einführung eines neuen Releases notwendig sind, + informiert zu sein. + + + + + + + + Synchronisation der Quellen + + 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 daß 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 mit <command>make world</command> + + + make world + + 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. + + + Erstellen Sie eine Sicherung! + + 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, daß Sie Fehler machen, oder Ihr + System nicht mehr bootet, weil andere Fehler in den Quellbaum + eingeführt haben. + + Stellen Sie sicher, daß Sie eine Sicherung erstellt haben + und über eine Fixit-Floppy verfügen. Wahrscheinlich + brauchen Sie sie nicht zu benutzen, aber gehen Sie auf Nummer + Sicher! + + + + Abonnieren Sie die richtige Mailingliste + + 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 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, daß 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. + + + + Lesen Sie <filename>/usr/src/UPDATING</filename> + + 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. + + + + + Überprüfen Sie + <filename>/etc/make.conf</filename> + + make.conf + + + Überprüfen Sie die Dateien + /etc/defaults/make.conf und + /etc/make.conf. Die erste enthält + Vorgabewerte, von denen die meisten auskommentiert sind. Um diese + während des Neubaus des Systems zu nutzen, tragen Sie die + Werte in /etc/make.conf ein. Beachten Sie, + daß 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 /etc/defaults/make.conf nach + /etc/make.conf übertragen und dort + aktivieren. + + Sehen Sie sich auch die anderen Definitionen, wie + COPTFLAGS oder NOPORTDOCS an + und entscheiden Sie, ob Sie diese aktivieren wollen. + + + + Aktualisieren Sie die Dateien in <filename>/etc</filename> + + 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 der Installationsteil von + make world auf das Vorhandensein von bestimmten + Accounts oder Gruppen angewiesen war, die aber zur Zeit des Updates + noch nicht vorhanden waren. Demzufolge kam es zu Problemen + bei der Migration. + + Ein Beispiel dafür ist der vor kurzem hinzugefügte + Benutzer smmsp. Die Installationsprozedur + schlug an der Stelle fehl, an der mtree + 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 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 + 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. + + + + + Wechseln Sie in den Single-User Modus + Single-User Modus + + Sie können erwägen, das System im Single-User Modus zu + übersetzen. Abgesehen davon, daß dies etwas schneller + ist, werden bei der Installation des Systems viele wichtige Dateien, + wie die Standard-Systemprogramme, die Bibliotheken und + Include-Dateien, angefaßt. 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. + + 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 + 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. + + + Wenn Ihre CMOS-Uhr auf lokale Zeit und nicht auf GMT + eingestellt ist, setzen Sie noch das folgende Kommando + ab: +&prompt.root; adjkerntz -i + + Dies stellt sicher, daß Ihre Zeitzone richtig + eingestellt ist. Ohne dieses Kommando werden Sie + vielleicht später Probleme bekommen. + + + + + + Entfernen Sie <filename>/usr/obj</filename> + + 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 world Prozeß + 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 -Option + (siehe &man.chflags.1;) schreibgeschützt, die vor dem + Löschen entfernt werden muß. + + &prompt.root; cd /usr/obj +&prompt.root; chflags -R noschg * +&prompt.root; rm -rf * + + + + Übersetzen der Quellen + + + Sichern der Ausgaben + + Für den Fall, daß 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. + + + + Übersetzen und Installation des Basissystems + + 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 + + In diesem Beispiel ist + 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 + 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, daß die profiled + Bibliotheken gebaut werden, rufen Sie make wie + folgt auf: + &prompt.root; make -DNOPROFILE=true 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 + Bauprozeß in eine Reihe von Einzelschritten. + + Im Regelfall müssen Sie &man.make.1; keine Parameter + mitgeben, so daß 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. + + 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äßt 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 können Sie + make anweisen, mehrere Prozesse zu starten. + Besonders effektiv ist das auf Mehrprozessor-Systemen. Da aber + der Übersetzungsprozeß 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, + daß 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, daß dies noch nicht richtig + unterstützt wird und daß 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. + + + + Laufzeiten + + make world + Laufzeiten + + + Die Laufzeit eines Baus wird von vielen Faktoren + beeinflußt. Ein 500 MHz Pentium III braucht + ungefähr zwei Stunden um &os.stable; zu bauen. Der Bau von + &os.current; dauert etwas länger. + + + + + Übersetzen und Installation des Kernels + + 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 paßt. + + 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, daß das System + ordnungsgemäß funktioniert. Nachdem Sie mit + GENERIC gebootet und sichergestellt haben, + daß Ihr System funktioniert, können Sie einen neuen + Kernel mit Ihrer Konfigurationsdatei bauen. + + Wenn Sie einen Update nach &os; 4.0 oder höher + durchführen, sollten Sie den Kernel nicht mit der + alten Methode, die in + beschrieben ist, bauen. Stattdessen benutzen Sie die folgenden + Kommandos (die neue Methode) + nach dem + Bau des Basissystems mit + buildworld: + + &prompt.root; cd /usr/src +&prompt.root; make buildkernel +&prompt.root; make installkernel + + Wenn Sie ein Update auf eine &os; Version vor 4.0 + durchführen, sollten Sie die alte 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 + + + + Booten Sie in den Single-User Modus + 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 + . + + + + Installation des Systems + + 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: + darf mit installworld + nicht benutzt werden. + + Sie haben zum Bauen die folgende Kommandozeile + verwendet: + + &prompt.root; make -DNOPROFILE=true buildworld + + Bei der Installation setzen Sie dann das folgende Kommando + ab: + + &prompt.root; make -DNOPROFILE=true 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. + + + + + Aktualisieren der von <command>make installworld</command> + ausgelassenen Dateien + + Neue oder geänderte Konfigurationsdateien aus einigen + Verzeichnissen, besonders /etc, + /var und /usr werden bei + der Installationsprozedur nicht berücksichtigt. + + Sie können diese Dateien mit &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, daß etwas schief + geht. + + + <command>mergemaster</command> + 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 + daß 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, daß 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 Paßwort-Datei neu bauen + oder MAKEDEV laufen lassen wollen. Am Ende + haben Sie die Möglichkeit, den Rest der temporären Dateien + zu löschen. + + + + Manueller Abgleich der Konfigurationsdateien + + Wenn Sie den Abgleich lieber selbst ausführen wollen, + beachten Sie bitte, daß 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 , daß + /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. + + + Sichern Sie die Inhalte von <filename>/etc</filename> + + 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 wird rekursiv kopiert und + 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 /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 + + 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. Entscheiden Sie anhand der Unterschiede, ob + Sie beide Dateien abgleichen oder die neue Version über die + alte kopieren wollen. + + + Versehen Sie das temporäre Verzeichnis mit einem + Zeitstempel + + Wenn Sie das System oft neu bauen, müssen Sie + /etc genauso oft aktualisieren. Dies kann + mit der Zeit sehr lästig werden. + + Sie können das Verfahren beschleunigen, wenn Sie sich + eine Kopie der Dateien behalten, die Sie zuletzt nach + /etc installiert haben. Das folgende + Verfahren zeigt Ihnen, wie das geht. + + + + Folgen Sie der normalen Prozedur um das System zu + bauen. Wenn Sie /etc und die anderen + Verzeichnisse aktualisieren wollen, geben Sie dem + temporären Verzeichnis einen Namen, der das aktuelle + Datum enthält. Wenn Sie dies zum Beispiel am 14.  + Februar 1998 durchführten, hätten Sie die + folgenden Kommandos abgesetzt: + + &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 Prozeß jedesmal 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"` + + + + + + Aktualisieren Sie <filename>/dev</filename> + + + DEVFS + DEVFS + Wenn Sie DEVFS benutzen, brauchen Sie diesen Schritt nicht + auszuführen. + + + 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 Prozeß 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äten, 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. + + + + + + Aktualisieren Sie <filename>/stand</filename> + + + Dieser Schritt wurde nur der Vollständigkeit wegen + aufgenommen. Sie können ihn komplett auslassen. + + + 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 daß es unabhängig von den Dateien + in anderen Dateisystemen, insbesondere /usr, + ist. + + &prompt.root; cd /usr/src/release/sysinstall +&prompt.root; make all install + + + + Booten + + Sie sind nun am Ende der Prozedur angelangt. Nachdem Sie sich + davon überzeugt haben, daß Ihr System funktioniert, + booten Sie das System mit &man.fastboot.8;: + + &prompt.root; fastboot + + + + Ende + + Herzlichen Glückwunsch! Sie haben gerade erfolgreich Ihr + &os; System aktualisiert. + + Es ist übrigens leicht einen Teil des Systems + wiederherzustellen, für den Fall, daß 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; + + + + Fragen + + + + + Muß 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, daß 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 world + 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, + daß 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, daß er + Probleme hat, weil er eine Abkürzung genommen hat. + + Wenn Sie gefährlich leben wollen, übergeben Sie + make die Variable + NOCLEAN: + + &prompt.root; make -DNOCLEAN world + + + + + + Kann ein abgebrochener Bau weitergeführt + werden? + + + + Das hängt davon ab, wieweit der Bauprozeß + 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, + daß 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, + daß make world die vorher erstellten + Dateien löscht. + + Das Sie sich im letzten Schritt der Bauprozedur + befinden, erkennen Sie daran, daß 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 Bauprozesß 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 . Die Optimierungsstufe + ist deutlich langsamer und die + Performance-Unterschiede zwischen und + sind vernachlässigbar klein. + veranlaßt den Kompiler Pipes + anstelle von Dateien für die Kommunikation zu + benutzen. Dies spart einige Plattenzugriffe, geht aber + auf Kosten des Speichers. + + + + Benutzen Sie + , um + mehrere Prozesse parallel laufen zu lassen. + Normalerweise beschleunigt dies den Bauprozeß + unabhängig davon, ob Sie ein Einprozessor oder + Mehrprozessor System einsetzen. + + + + Sie können das Dateisystem + /usr/src mit der Option + einhängen. Dies + verhindert, daß 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, daß 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 eingehangen werden. Dies + bewirkt, daß 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 zusammengefaßt werden, was einen + erheblichen Geschwindigkeitszuwachs mit sich bringen + kann. + + + Beachten Sie, daß dies Ihr Dateisystem + anfälliger für Fehler macht. Im Fall eines + Stromausfalls besteht eine erhöhte + Wahrscheinlichkeit, daß 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, daß + 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, daß 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 muß wirklich + zweimal aufgerufen werden. + + Nachdem Sie aufgeräumt haben, starten Sie den + Bauprozeß 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 + + + + Installation mehrerer Maschinen + + 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. + + + Voraussetzungen + + 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 + world 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, daß + /etc/make.conf auf allen Maschinen einer + Baugruppe mit der Datei des Bau-Masters übereinstimmt. Der + Bau-Master muß 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 bekanntgegeben + werden. Geben Sie dabei den Kernel des Bau-Masters zuerst an. + Für jeden zu bauenden Kernel muß auf dem Bau-Master die + entsprechende Konfigurationsdatei unter + /usr/src/sys/arch/conf + abgelegt werden. + + + + Installation des Basissystems + + 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, daß die Testmaschine + einwandfrei funktioniert, wiederholen Sie diese Prozedur für + jede Maschine in der Baugruppe. + + + + Die Ports-Sammlung + + 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. + + + + +