From owner-p4-projects@FreeBSD.ORG Sun Feb 1 12:39:36 2009 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id BC4CA1065672; Sun, 1 Feb 2009 12:39:35 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64705106564A for ; Sun, 1 Feb 2009 12:39:35 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 1B90F8FC0A for ; Sun, 1 Feb 2009 12:39:35 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.3/8.14.3) with ESMTP id n11CdZrR074679 for ; Sun, 1 Feb 2009 12:39:35 GMT (envelope-from rene@FreeBSD.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.14.3/8.14.3/Submit) id n11CdZrX074677 for perforce@freebsd.org; Sun, 1 Feb 2009 12:39:35 GMT (envelope-from rene@FreeBSD.org) Date: Sun, 1 Feb 2009 12:39:35 GMT Message-Id: <200902011239.n11CdZrX074677@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to rene@FreeBSD.org using -f From: Rene Ladan To: Perforce Change Reviews Cc: Subject: PERFORCE change 156992 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 12:39:36 -0000 http://perforce.freebsd.org/chv.cgi?CH=156992 Change 156992 by rene@rene_self on 2009/02/01 12:38:45 IFC Affected files ... .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml#12 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml#12 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml#8 integrate .. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml#19 integrate .. //depot/projects/docproj_nl/www/en/where.sgml#3 integrate Differences ... ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml#12 (text+ko) ==== @@ -1,7 +1,7 @@ @@ -1588,9 +1588,190 @@ The Canonical Way to Update Your System To update your system, you should check - /usr/src/UPDATING for any pre-buildworld steps - necessary for your version of the sources and then use the following - procedure: + /usr/src/UPDATING for any pre-buildworld + steps necessary for your version of the sources and then use the + procedure outlined here. + + These upgrade steps assume that you are currently using an old + &os; version, consisting of an old compiler, old kernel, old world and + old configuration files. By world here we mean the + core system binaries, libraries and programming files. The compiler + is part of world, but has a few special concerns. + + We also assume that you have already obtained the sources to a + newer system. If the sources available on the particular system are + old too, see for detailed help about + synchronizing them to a newer version. + + Updating the system from sources is a bit more subtle than it + might initially seem to be, and the &os; developers have found it + necessary over the years to change the recommended approach fairly + dramatically as new kinds of unavoidable dependencies come to light. + The rest of this section describes the rationale behind the currently + recommended upgrade sequence. + + Any successful update sequence must deal with the following + issues: + + + + The old compiler might not be able to compile the new + kernel. (Old compilers sometimes have bugs.) So, the new + kernel should be built with the new compiler. In particular, + the new compiler must be built before the new kernel is built. + This does not necessarily mean that the new compiler must + be installed before building the new + kernel. + + + + The new world might rely on new kernel features. So, the + new kernel must be installed before the new world is + installed. + + + + These first two issues are the basis for the + core buildworld, + buildkernel, + installkernel, + installworld sequence that we describe in + the following paragraphs. This is not an exhaustive list of all the + reasons why you should prefer the currently recommended upgrade + process. Some of the less obvious ones are listed below: + + + + The old world might not run correctly on the new kernel, so + you must install the new world immediately upon installing the + new kernel. + + + + Some configuration changes must be done before the new world + is installed, but others might break the old world. Hence, two + different configuration upgrade steps are generally + needed. + + + + For the most part, the update process only replaces or adds + files; existing old files are not deleted. In a few cases, this + can cause problems. As a result, the update procedure will + sometimes specify certain files that should be manually deleted + at certain steps. This may or may not be automated in the + future. + + + + These concerns have led to the following recommended sequence. + Note that the detailed sequence for particular updates may require + additional steps, but this core process should remain unchanged for + some time: + + + + make buildworld + + This first compiles the new compiler and a few related + tools, then uses the new compiler to compile the rest of the new + world. The result ends up + in /usr/obj. + + + + make buildkernel + + Unlike the older approach, using &man.config.8; and + &man.make.1;, this uses the new compiler + residing in /usr/obj. + This protects you against compiler-kernel mismatches. + + + + make installkernel + + Place the new kernel and kernel modules onto the disk, + making it possible to boot with the newly updated kernel. + + + + Reboot into single user mode. + + Single user mode minimizes problems from updating software + that's already running. It also minimizes any problems from + running the old world on a new kernel. + + + + mergemaster + + This does some initial configuration file updates in + preparation for the new world. For instance it may add new user + groups to the system, or new user names to the password database. + This is often necessary when new groups or special system-user + accounts have been added since the last update, so that + the installworld step will be able to + use the newly installed system user or system group names + without problems. + + + + make installworld + + Copies the world + from /usr/obj. You now + have a new kernel and new world on disk. + + + + mergemaster + + Now you can update the remaining configuration files, since + you have a new world on disk. + + + + Reboot. + + A full machine reboot is needed now to load the new kernel + and new world with new configuration files. + + + + Note that if you're upgrading from one release of the same &os; + branch to a more recent release of the same branch, i.e. from 7.0 to + 7.1, then this procedure may not be absolutely necessary, since + you're unlikely to run into serious mismatches between compiler, + kernel, userland and configuration files. The older approach + of make world followed + by building and installing a new kernel might work well enough for + minor updates. + + But, when upgrading across major releases, people who don't + follow this procedure should expect some problems. + + It is also worth noting that many upgrades + (i.e. 4.X to 5.0) may require + specific additional steps (renaming or deleting specific files prior + to installworld, for instance). Read + the /usr/src/UPDATING file carefully, + especially at the end, where the currently recommended upgrade + sequence is explicitly spelled out. + + This procedure has evolved over time as the developers have + found it impossible to completely prevent certain kinds of mismatch + problems. Hopefully, the current procedure will remain stable for a + long time. + + + Upgrading from &os; 3.X or earlier + releases is a bit trickier; read UPDATING + carefully if you have to perform this sort of upgrade. + + + To summarize, the currently recommended way of upgrading &os; + from sources is: &prompt.root; cd /usr/src &prompt.root; make buildworld ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml#12 (text+ko) ==== @@ -1,7 +1,7 @@ @@ -3227,7 +3227,7 @@ relatively simple. The default named configuration - is that of a basic resolving name server, ran in a + is that of a basic resolving name server, running in a &man.chroot.8; environment. To start the server one time with this configuration, use the following command: ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml#8 (text+ko) ==== @@ -1,7 +1,7 @@ @@ -156,9 +156,9 @@ - You have a modem or - other device connected to your system and configured - correctly which allows you to connect to your ISP. + A modem or + other device connected to your system and properly configured + to allow you to connect to your ISP. @@ -1825,9 +1825,14 @@ Check the Device Nodes - If you reconfigured your kernel then you recall the - sio device. If you did not - configure your kernel, there is no reason to worry. Just + When using a custom kernel, make sure to include the following + line in your kernel configuration file: + + device sio + + The sio device is already included + in the GENERIC kernel, so no additional steps + are necessary in this case. Just check the dmesg output for the modem device with: ==== //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml#19 (text+ko) ==== @@ -1,7 +1,7 @@