From owner-freebsd-doc Tue Jun 25 15:41:53 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0CB9537B40D for ; Tue, 25 Jun 2002 15:40:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g5PMe4J14181; Tue, 25 Jun 2002 15:40:04 -0700 (PDT) (envelope-from gnats) Received: from guest.reppep.com (guest.reppep.com [64.81.19.110]) by hub.freebsd.org (Postfix) with ESMTP id 46E4737B401 for ; Tue, 25 Jun 2002 15:34:31 -0700 (PDT) Received: by guest.reppep.com (Postfix, from userid 501) id F3B8FA827; Tue, 25 Jun 2002 18:34:40 -0400 (EDT) Message-Id: <20020625223440.F3B8FA827@guest.reppep.com> Date: Tue, 25 Jun 2002 18:34:40 -0400 (EDT) From: Chris Pepper Reply-To: Chris Pepper To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: docs/39858: handbook/cutting-edge/chapter.sgml: various fixes Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 39858 >Category: docs >Synopsis: handbook/cutting-edge/chapter.sgml: various fixes >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Tue Jun 25 15:40:03 PDT 2002 >Closed-Date: >Last-Modified: >Originator: Chris Pepper >Release: FreeBSD 4.6-STABLE i386 >Organization: >Environment: System: FreeBSD guest.reppep.com 4.6-STABLE FreeBSD 4.6-STABLE #0: Tue Jun 25 14:38:05 EDT 2002 root@guest.reppep.com:/usr/obj/usr/src/sys/REPPEP i386 >Description: Removed some inline tabs and trailing whitespace. The docs suggest dropping to single-user before doing anything, but point out this can be deferred until the actual installation phase. Inserted a reminder on when to go single, if deferring. Clarified when "adjkerntz -i" is required -- it seemed to cause some trouble once when I ran it unnecessarily. Removed suggestion re: "make -j 4" on single-CPU systems. This has been confirmed on -questions to cause a slowdown, rather than faster building. >How-To-Repeat: >Fix: --- chapter.sgml.diff begins here --- Index: chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml,v retrieving revision 1.127 diff -u -r1.127 chapter.sgml --- chapter.sgml 2002/06/23 21:13:50 1.127 +++ chapter.sgml 2002/06/25 21:28:30 @@ -746,7 +746,7 @@ from the obvious benefit of making things go slightly faster, reinstalling the system will touch a lot of important system files, all the standard system binaries, libraries, include files - and so on. Changing these on a running system (particularly if + and so on. Changing these on a running system (particularly if you have active users on the system at the time) is asking for trouble. @@ -754,7 +754,9 @@ Another method is to compile the system in multi-user mode, and then drop into single user mode for the installation. If you would like to do it this way, simply hold off on the following steps until - the build has completed. + the builds have completed; drop to single-user mode before using + installkernel or + installworld. As the superuser, you can execute @@ -778,7 +780,9 @@ - If your CMOS clock is set to local time and not to GMT, + If your CMOS clock is set to local time and not to GMT + (if the output of the date doesn't show the + correct time and zone), you may also need to run the following command: &prompt.root; adjkerntz -i @@ -830,9 +834,9 @@ when the process has finished. &prompt.root; script /var/tmp/mw.out -Script started, output file is /var/tmp/mw.out +Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET -… compile, compile, compile … +… compile, compile, compile … &prompt.root; exit Script done, … @@ -944,18 +948,8 @@ It is now possible to specify a option to make which will cause it to spawn several - simultaneous processes. This is most useful on multi-CPU machines. - However, since much of the compiling process is IO bound rather - than CPU bound it is also useful on single CPU machines. + simultaneous processes. This is most useful on multi-CPU machines. - On a typical single-CPU machine you would run: - - &prompt.root; make -j4 buildworld - - &man.make.1; will then have up to 4 processes running at any one - time. Empirical evidence posted to the mailing lists shows this - generally gives the best performance benefit. - If you have a multi-CPU machine and you are using an SMP configured kernel try values between 6 and 10 and see how they speed things up. @@ -1000,7 +994,7 @@ system back to single user mode. This is a good test that the new system works properly. After booting from GENERIC and verifying that your system works you - can then build a new kernel based on your normal kernel configuration + can then build a new kernel based on your normal kernel configuration file. If you are upgrading to &os; 4.0 or above then the old @@ -1008,12 +1002,22 @@ is deprecated. Instead, you should run these commands after you have built the world with - buildworld. + buildworld. + + If you are building in multi-user mode, you'll need to drop to + single user mode before using make + installkernel; details are in . + + &prompt.root; cd /usr/src &prompt.root; make buildkernel &prompt.root; make installkernel @@ -1045,7 +1049,7 @@ &prompt.root; make installworld - If you specified variables on the make + If you specified variables on the make buildworld command line, you must specify the same variables in the make installworld command line. This does not necessarily hold true for other options; @@ -1601,9 +1605,7 @@ Pass the option to &man.make.1; to - run multiple processes in parallel. This usually helps - regardless of whether you have a single or a multi processor - machine. + run multiple processes in parallel. The filesystem holding --- chapter.sgml.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message