Date: Sun, 4 Mar 2001 11:56:49 +0000 From: Nik Clayton <nik@freebsd.org> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: nickhead@folino.com, freebsd-stable@FreeBSD.ORG Subject: Re: KERNCONF instead of KERNEL? Message-ID: <20010304115649.A420@canyon.nothing-going-on.org> In-Reply-To: <3A9FAF6B.29CC5157@newsguy.com>; from dcs@newsguy.com on Fri, Mar 02, 2001 at 11:34:19PM %2B0900 References: <20010302134531.26192.qmail@www1.nameplanet.com> <3A9FAF6B.29CC5157@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--PmA2V3Z32TCmWXqI Content-Type: multipart/mixed; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 02, 2001 at 11:34:19PM +0900, Daniel C. Sobral wrote: > Here is the order suggested and the why: >=20 > 1) make buildworld -- because the new kernel may depend on new tools > (config(8) is a common example, but no the only one). > 2) make buildkernel -- some programs may depend on new syscalls, so > build the kernel before installing the world. > 3) make installkernel -- install a new kernel (the copy of the old one > is preserved) > 4) reboot single user -- make sure the new kernel works > 5) mount filesystems, make installworld -- install the rest of the world > 6) mergemaster -- update /etc -- the new userland tools may require new > /etc scripts and configuration files. I think the attached diff to the Handbook brings it up to date with reality. I've also attached the generated HTML file, for those of you that don't want to build the docs. Comments? N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- --ZGiS0Q5IWpPtfppv Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="makeworld.html" Content-Transfer-Encoding: quoted-printable <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta name=3D"generator" content=3D"HTML Tidy, see www.w3.org"> <title>Using make world</title> <meta name=3D"GENERATOR" content=3D "Modular DocBook HTML Stylesheet Version 1.61 "> <link rel=3D"HOME" title=3D"FreeBSD Handbook" href=3D"index.html"> <link rel=3D"UP" title=3D"The Cutting Edge" href=3D "cutting-edge.html"> <link rel=3D"PREVIOUS" title=3D"Synchronizing Your Source" href=3D "synching.html"> <link rel=3D"NEXT" title=3D"Contributing to FreeBSD" href=3D "contrib.html"> </head> <body class=3D"SECT1" bgcolor=3D"#FFFFFF" text=3D"#000000" link=3D "#0000FF" vlink=3D"#840084" alink=3D"#0000FF"> <div class=3D"NAVHEADER"> <table width=3D"100%" border=3D"0" cellpadding=3D"0" cellspacing=3D "0"> <tr> <th colspan=3D"3" align=3D"center">FreeBSD Handbook</th> </tr> <tr> <td width=3D"10%" align=3D"left" valign=3D"bottom"><a href=3D "synching.html">Prev</a></td> <td width=3D"80%" align=3D"center" valign=3D"bottom">Chapter 19. The Cutting Edge</td> <td width=3D"10%" align=3D"right" valign=3D"bottom"><a href=3D "contrib.html">Next</a></td> </tr> </table> <hr align=3D"LEFT" width=3D"100%"> </div> <div class=3D"SECT1"> <h1 class=3D"SECT1"><a name=3D"MAKEWORLD">19.4. Using <tt class=3D "COMMAND">make world</tt></a></h1> <p>Once you have synchronized your local source tree against a particular version of FreeBSD (<tt class=3D "LITERAL">stable</tt>, <tt class=3D"LITERAL">current</tt> and so on) you must then use the source tree to rebuild the system.</p> <div class=3D"WARNING"> <blockquote class=3D"WARNING"> <p><b>Take a backup:</b> I cannot stress highly enough how important it is to take a backup of your system <i class=3D"EMPHASIS">before</i> you do this. While remaking the world is (as long as you follow these instructions) an easy task to do, there will inevitably be times when you make mistakes, or when mistakes made by others in the source tree render your system unbootable.</p> <p>Make sure you have taken a backup. And have a fix-it floppy to hand. I have never needed to use them, and, touch wood, I never will, but it is always better to be safe than sorry.</p> </blockquote> </div> <div class=3D"WARNING"> <blockquote class=3D"WARNING"> <p><b>Subscribe to the right mailing list:</b> The -STABLE and -CURRENT FreeBSD code branches are, by their nature, <i class=3D"EMPHASIS">in development</i>. People that contribute to FreeBSD are human, and mistakes occasionally happen.</p> <p>Sometimes these mistakes can be quite harmless, just causing your system to print a new diagnostic warning. Or the change may be catastrophic, and render your system unbootable or destroy your filesystems (or worse).</p> <p>If problems like these occur, a ``heads up'' is posted to the appropriate mailing list, explaining the nature of the problem and which systems it affects. And an ``all clear'' announcement is posted when the problem has been solved.</p> <p>If you try and track -STABLE or -CURRENT and do not read the <tt class=3D"EMAIL"><<a href=3D "mailto:stable@FreeBSD.org">stable@FreeBSD.org</a>></tt> or <tt class=3D"EMAIL"><<a href=3D "mailto:current@FreeBSD.org">current@FreeBSD.org</a>></tt> mailing lists then you are asking for trouble.</p> </blockquote> </div> <div class=3D"SECT2"> <h2 class=3D"SECT2"><a name=3D"AEN13206">19.4.1. Read <tt class=3D"FILENAME">/usr/src/UPDATING</tt></a></h2> <p>Before you do anything else, read <tt class=3D "FILENAME">/usr/src/UPDATING</tt> (or the equivalent file wherever you have a copy of the source code). This file should contain important information about problems you might encounter, or specify the order in which you might have to run certain commands. If <tt class=3D "FILENAME">UPDATING</tt> contradicts something you read here, <tt class=3D"FILENAME">UPDATING</tt> takes precedence.</p> <div class=3D"IMPORTANT"> <blockquote class=3D"IMPORTANT"> <p><b>Important:</b> Reading <tt class=3D "FILENAME">UPDATING</tt> is not an acceptable substitute for subscribing to the correct mailing list, as described previously. The two requirements are complementary, not exclusive.</p> </blockquote> </div> </div> <div class=3D"SECT2"> <h2 class=3D"SECT2"><a name=3D"AEN13216">19.4.2. Check <tt class=3D"FILENAME">/etc/make.conf</tt></a></h2> <p>Examine the files <tt class=3D "FILENAME">/etc/defaults/make.conf</tt> and <tt class=3D "FILENAME">/etc/make.conf</tt>. The first contains some default defines - most of which are commented out. To make use of them when you rebuild your system from source, add them to <tt class=3D"FILENAME">/etc/make.conf</tt>. Keep in mind that anything you add to <tt class=3D "FILENAME">/etc/make.conf</tt> is also used every time you run <tt class=3D"COMMAND">make</tt>, so it is a good idea to set them to something sensible for your system.</p> <p>As a typical user (not a FreeBSD developer), you will probably want to copy the <tt class=3D"MAKEVAR">CFLAGS</tt> and <tt class=3D"MAKEVAR">NOPROFILE</tt> lines found in <tt class=3D"FILENAME">/etc/defaults/make.conf</tt> to <tt class=3D "FILENAME">/etc/make.conf</tt> and uncomment them.</p> <div class=3D"NOTE"> <blockquote class=3D"NOTE"> <p><b>Version 2.1.7 and below:</b> If your machine has a floating point unit (386DX, 486DX, Pentium and up class machines) then you can also uncomment the HAVE_FPU line.</p> <p>This definition was removed for version 2.2.2 and up of FreeBSD.</p> </blockquote> </div> <p>Examine the other definitions (COPTFLAGS, NOPORTDOCS and so on) and decide if they are relevant to you.</p> </div> <div class=3D"SECT2"> <h2 class=3D"SECT2"><a name=3D"AEN13235">19.4.3. Update <tt class=3D"FILENAME">/etc/group</tt></a></h2> <p>The <tt class=3D"FILENAME">/etc</tt> directory contains a large part of your system's configuration information, as well as scripts that are run at system startup. Some of these scripts change from version to version of FreeBSD.</p> <p>Some of the configuration files are also used in the day to day running of the system. In particular, <tt class=3D "FILENAME">/etc/group</tt>.</p> <p>There have been occasions when the installation part of ``make world'' has expected certain usernames or groups to exist. When performing an upgrade it is likely that these groups did not exist. This caused problems when upgrading.</p> <p>The most recent example of this is when the ``ppp'' group (later renamed ``network'') was added. Users had the installation process fail for them when parts of the <tt class=3D"FILENAME">ppp</tt> subsystem were installed using a non-existent (for them) group name.</p> <p>The solution is to examine <tt class=3D "FILENAME">/usr/src/etc/group</tt> and compare its list of groups with your own. If they are any groups in the new file that are not in your file then copy them over. Similarly, you should rename any groups in <tt class=3D "FILENAME">/etc/group</tt> which have the same GID but a different name to those in <tt class=3D "FILENAME">/usr/src/etc/group</tt>.</p> <div class=3D"TIP"> <blockquote class=3D"TIP"> <p><b>Tip:</b> If you are feeling particularly paranoid, you can check your system to see which files are owned by the group you are renaming or deleting.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>find / -group <tt class=3D "REPLACEABLE"><i>GID</i></tt> -print</b></tt> </pre> <p>will show all files owned by group <tt class=3D "REPLACEABLE"><i>GID</i></tt> (which can be either a group name or a numeric group ID).</p> </blockquote> </div> </div> <div class=3D"SECT2"> <h2 class=3D"SECT2"><a name=3D"MAKEWORLD-SINGLEUSER">19.4.4. Drop to single user mode</a></h2> <p>You may want to compile the system in single user mode. Apart 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 you have active users on their at the time) is asking for trouble.</p> <p>That said, if you are confident, you can omit this step.</p> <div class=3D"NOTE"> <blockquote class=3D"NOTE"> <p><b>Version 2.2.5 and above:</b> As described in more detail below, versions 2.2.5 and above of FreeBSD have separated the building process from the installing process. You can therefore <i class=3D "EMPHASIS">build</i> the new system in multi-user mode, and then drop to single user mode to do the installation.</p> </blockquote> </div> <p>As the superuser, you can execute</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>shutdown now</b></tt> </pre> <p>from a running system, which will drop it to single user mode.</p> <p>Alternatively, reboot the system, and at the boot prompt, enter the <tt class=3D"OPTION">-s</tt> flag. The system will then boot single user. At the shell prompt you should then run:</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>fsck -p</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>mount -u /</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>mount -a -t ufs</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>swapon -a</b></tt> </pre> <p>This checks the filesystems, remounts <tt class=3D "FILENAME">/</tt> read/write, mounts all the other UFS filesystems referenced in <tt class=3D "FILENAME">/etc/fstab</tt> and then turns swapping on.</p> </div> <div class=3D"SECT2"> <h2 class=3D"SECT2"><a name=3D"AEN13287">19.4.5. Remove <tt class=3D"FILENAME">/usr/obj</tt></a></h2> <p>As parts of the system are rebuilt they are placed in directories which (by default) go under <tt class=3D "FILENAME">/usr/obj</tt>. The directories shadow those under <tt class=3D"FILENAME">/usr/src</tt>.</p> <p>You can speed up the ``make world'' process, and possibly save yourself some dependency headaches by removing this directory as well.</p> <p>Some files below <tt class=3D"FILENAME">/usr/obj</tt> will have the immutable flag set (see <span class=3D "CITEREFENTRY"><span class=3D "REFENTRYTITLE">chflags</span>(1)</span> for more information) which must be removed first.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>cd /usr/obj</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>chflags -R noschg *</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>rm -rf *</b></tt> </pre> </div> <div class=3D"SECT2"> <h2 class=3D"SECT2"><a name=3D"AEN13307">19.4.6. Recompile the source</a></h2> <div class=3D"SECT3"> <h3 class=3D"SECT3"><a name=3D"AEN13309">19.4.6.1. All versions</a></h3> <p>You must be in the <tt class=3D"FILENAME">/usr/src</tt> directory...</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>cd /usr/src</b></tt> </pre> <p>(unless, of course, your source code is elsewhere, in which case change to that directory instead).</p> <p>To rebuild the world you use the <span class=3D "CITEREFENTRY"><span class=3D "REFENTRYTITLE">make</span>(1)</span> command. This command reads instructions from the <tt class=3D "FILENAME">Makefile</tt> which describes how the programs that comprise FreeBSD should be rebuilt, the order they should be built in, and so on.</p> <p>The general format of the command line you will type is as follows:</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D"USERINPUT"><b>make <tt class=3D"OPTION">-<tt class=3D"REPLACEABLE"><i>x</i></tt></tt> <tt class=3D"OPTION">-D<tt class=3D "REPLACEABLE"><i>VARIABLE</i></tt></tt> <tt class=3D "REPLACEABLE"><i>target</i></tt></b></tt> </pre> <p>In this example, <tt class=3D"OPTION">-<tt class=3D "REPLACEABLE"><i>x</i></tt></tt> is an option that you would pass to <span class=3D"CITEREFENTRY"><span class=3D "REFENTRYTITLE">make</span>(1)</span>. See the <span class=3D"CITEREFENTRY"><span class=3D "REFENTRYTITLE">make</span>(1)</span> manual page for an example of the options you can pass.</p> <p><tt class=3D"OPTION">-D<tt class=3D "REPLACEABLE"><i>VARIABLE</i></tt></tt> passes a variable to the <tt class=3D"FILENAME">Makefile</tt>. The behavior of the <tt class=3D"FILENAME">Makefile</tt> is controlled by these variables. These are the same variables as are set in <tt class=3D"FILENAME">/etc/make.conf</tt>, and this provides another way of setting them.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make -DNOPROFILE=3Dtrue <tt class=3D "REPLACEABLE"><i>target</i></tt></b></tt> </pre> <p>is another way of specifying that profiled libraries should not be built, and corresponds with the</p> <pre class=3D"PROGRAMLISTING"> NOPROFILE=3D true # Avoid compiling profiled libraries </pre> <p>lines in <tt class=3D"FILENAME">/etc/make.conf</tt>.</p> <p><tt class=3D"REPLACEABLE"><i>target</i></tt> tells <span class=3D"CITEREFENTRY"><span class=3D "REFENTRYTITLE">make</span>(1)</span> what you want to do. Each <tt class=3D"FILENAME">Makefile</tt> defines a number of different ``targets'', and your choice of target determines what happens.</p> <p>Some targets are listed in the <tt class=3D "FILENAME">Makefile</tt>, but are not meant for you to run. Instead, they are used by the build process to break out the steps necessary to rebuild the system into a number of sub-steps.</p> <p>Most of the time you won't need to pass any parameters to <span class=3D"CITEREFENTRY"><span class=3D "REFENTRYTITLE">make</span>(1)</span>, and so your command like will look like this:</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D"USERINPUT"><b>make <tt class=3D"REPLACEABLE"><i>target</i></tt></b></tt> </pre> </div> <div class=3D"SECT3"> <h3 class=3D"SECT3"><a name=3D"AEN13371">19.4.6.2. Saving the output</a></h3> <p>It's a good idea to save the output you get from running <span class=3D"CITEREFENTRY"><span class=3D "REFENTRYTITLE">make</span>(1)</span> to another file. If something goes wrong you will have a copy of the error message, and a complete list of where the process had got to. While this might not help you in diagnosing what has gone wrong, it can help others if you post your problem to one of the FreeBSD mailing lists.</p> <p>The easiest way to do this is to use the <span class=3D "CITEREFENTRY"><span class=3D "REFENTRYTITLE">script</span>(1)</span> command, with a parameter that specifies the name of the file to save all output to. You would do this immediately before remaking the world, and then type <tt class=3D "USERINPUT"><b>exit</b></tt> when the process has finished.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>script /var/tmp/mw.out</b></tt> Script started, output file is /var/tmp/mw.out =20 <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make world</b></tt> <i class=3D"EMPHASIS">... compile, compile, compile ...</i> =20 <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>exit</b></tt> Script done, ... </pre> <p>If you do this, <i class=3D"EMPHASIS">do not</i> save the output in <tt class=3D"FILENAME">/tmp</tt>. This directory may be cleared next time you reboot. A better place to store it is in <tt class=3D "FILENAME">/var/tmp</tt> (as in the previous example) or in <tt class=3D"USERNAME">root</tt>'s home directory.</p> </div> <div class=3D"SECT3"> <h3 class=3D"SECT3"><a name=3D"AEN13395">19.4.6.3. Version 2.2.2 and below</a></h3> <p><tt class=3D"FILENAME">/usr/src/Makefile</tt> contains the <tt class=3D"MAKETARGET">world</tt> target, which will rebuild the entire system and then install it.</p> <p>Use it like this:</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make world</b></tt> </pre> <p>This will also install the new system binaries.</p> </div> <div class=3D"SECT3"> <h3 class=3D"SECT3"><a name=3D"AEN13405">19.4.6.4. Version 2.2.5 and above</a></h3> <p>Beginning with version 2.2.5 of FreeBSD (actually, it was first created on the -CURRENT branch, and then retrofitted to -STABLE midway between 2.2.2 and 2.2.5) the <tt class=3D"MAKETARGET">world</tt> target has been split in two. <tt class=3D"MAKETARGET">buildworld</tt> and <tt class=3D"MAKETARGET">installworld</tt>.</p> <p>As the names imply, <tt class=3D "MAKETARGET">buildworld</tt> builds a complete new tree under <tt class=3D"FILENAME">/usr/obj</tt>, and <tt class=3D "MAKETARGET">installworld</tt> installs this tree on the current machine.</p> <p>This is very useful for 2 reasons. First, it allows you to do the build safe in the knowledge that no components of your running system will be affected. The build is ``self hosted''. Because of this, you can safely run <tt class=3D"MAKETARGET">buildworld</tt> on a machine running in multi-user mode with no fear of ill-effects. I still recommend you run the <tt class=3D "MAKETARGET">installworld</tt> part in single user mode though.</p> <p>Secondly, it allows you to use NFS mounts to upgrade multiple machines on your network. If you have three machines, A, B and C that you want to upgrade, run <tt class=3D"COMMAND">make buildworld</tt> and <tt class=3D "COMMAND">make installworld</tt> on A. B and C should then NFS mount <tt class=3D"FILENAME">/usr/src</tt> and <tt class=3D"FILENAME">/usr/obj</tt> from A, and you can then run <tt class=3D"COMMAND">make installworld</tt> to install the results of the build on B and C.</p> <p>Although the <tt class=3D"MAKETARGET">world</tt> target still exists, you are strongly encouraged not to use it.</p> <p>Run</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make buildworld</b></tt> </pre> </div> <div class=3D"SECT3"> <h3 class=3D"SECT3"><a name=3D"AEN13431">19.4.6.5. -CURRENT and above</a></h3> <p>If you are tracking -CURRENT you can also pass the <tt class=3D"OPTION">-j</tt> option to <tt class=3D "COMMAND">make</tt>. This lets <tt class=3D "COMMAND">make</tt> spawn several simultaneous processes.</p> <p>This is most useful on true 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.</p> <p>On a typical single-CPU machine you would run:</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make -j4 buildworld</b></tt> </pre> <p><span class=3D"CITEREFENTRY"><span class=3D "REFENTRYTITLE">make</span>(1)</span> 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.</p> <p>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.</p> <p>Be aware that (at the time of writing) this is still experimental, and commits to the source tree may occasionally break this feature. If the world fails to compile using this parameter try again without it before you report any problems.</p> </div> <div class=3D"SECT3"> <h3 class=3D"SECT3"><a name=3D"AEN13448">19.4.6.6. Timings</a></h3> <p>As a general rule of thumb, a 200MHz P6 with more than 32MB of RAM and reasonable SCSI disks will complete <tt class=3D"COMMAND">make world</tt> in about an hour and a half. A 32MB P133 will take 5 or 6 hours. Revise these figures down if your machines are slower...</p> </div> </div> <div class=3D"SECT2"> <h2 class=3D"SECT2"><a name=3D"AEN13452">19.4.7. Compile and install a new kernel</a></h2> <p>To take full advantage of your new system you should recompile the kernel. This is practically a necessity, as certain memory structures may have changed, and programs like <span class=3D"CITEREFENTRY"><span class=3D "REFENTRYTITLE">ps</span>(1)</span> and <span class=3D "CITEREFENTRY"><span class=3D "REFENTRYTITLE">top</span>(1)</span> will fail to work until the kernel and source code versions are the same.</p> <p>The simplest, safest way to do this is to build and install a kernel based on <tt class=3D "FILENAME">GENERIC</tt>. While <tt class=3D "FILENAME">GENERIC</tt> may not have all the necessary devices for your system, it should contain everything necessary to boot your system back to single user mode. This is a good test that the new system works properly. After booting from <tt class=3D"FILENAME">GENERIC</tt> and verifying that your system works you can then build a new kernel based on your normal kernel config file.</p> <p>If you are upgrading to FreeBSD 4.0 or above then the standard kernel build procedure (as described in <a href=3D "kernelconfig.html">Chapter 7</a>) is deprecated. Instead, you should run these commands.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>cd /usr/src</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make buildkernel</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make installkernel</b></tt> </pre> <p>If you are upgrading to a version of FreeBSD below 4.0 you should use the standard kernel build procedure. However, it is recommended that you use the new version of <span class=3D"CITEREFENTRY"><span class=3D "REFENTRYTITLE">config</span>(8)</span>, using a command line like this.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>/usr/obj/usr/src/usr.sbin/config/config <tt class=3D "REPLACEABLE"><i>KERNELNAME</i></tt></b></tt> </pre> </div> <div class=3D"SECT2"> <h2 class=3D"SECT2"><a name=3D"AEN13482">19.4.8. Reboot in to single user mode</a></h2> <p>You should reboot in to single user mode to test the new kernel works. Do this by following the instructions in <a href=3D"makeworld.html#MAKEWORLD-SINGLEUSER">Section 19.4.4</a>.</p> </div> <div class=3D"SECT2"> <h2 class=3D"SECT2"><a name=3D"AEN13486">19.4.9. Install the new system binaries</a></h2> <p>If you were building a version of FreeBSD recent enough to have used <tt class=3D"COMMAND">make buildworld</tt> then you should now use the <tt class=3D "MAKETARGET">installworld</tt> to install the new system binaries.</p> <p>Run</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make installworld</b></tt> </pre> <div class=3D"NOTE"> <blockquote class=3D"NOTE"> <p><b>Note:</b> If you specified variables on the <tt class=3D"COMMAND">make buildworld</tt> command line, you must specify the same variables in the <tt class=3D "COMMAND">make installworld</tt> command line.</p> <p>For example, if you ran:</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make -DNOPROFILE=3Dtrue buildworld</b></tt> </pre> <p>you must install the results with:</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make -DNOPROFILE=3Dtrue installworld</b></tt> </pre> <p>otherwise it would try and install profiled libraries that had not been built during the <tt class=3D "COMMAND">make buildworld</tt> phase.</p> </blockquote> </div> </div> <div class=3D"SECT2"> <h2 class=3D"SECT2"><a name=3D"AEN13509">19.4.10. Update files not updated by <tt class=3D"COMMAND">make world</tt></a></h2> <p>Remaking the world will not update certain directories (in particular, <tt class=3D"FILENAME">/etc</tt>, <tt class=3D "FILENAME">/var</tt> and <tt class=3D"FILENAME">/usr</tt>) with new or changed configuration files.</p> <p>The simplest way to update these files is to use <span class=3D"CITEREFENTRY"><span class=3D "REFENTRYTITLE">mergemaster</span>(8)</span>, though it is possible to do it manually if you would prefer to do that. We strongly recommend you use <span class=3D "CITEREFENTRY"><span class=3D "REFENTRYTITLE">mergemaster</span>(8)</span>, however, and if you do then you can skip forward to the <a href=3D "makeworld.html#UPDATE-DEV">next section</a>, since <span class=3D"CITEREFENTRY"><span class=3D "REFENTRYTITLE">mergemaster</span>(8)</span> is very simple to use. You should read the manual page first, and make a backup of <tt class=3D"FILENAME">/etc</tt> in case anything goes wrong.</p> <p>If you wish to do the update manually, you cannot just copy over the files from <tt class=3D "FILENAME">/usr/src/etc</tt> to <tt class=3D "FILENAME">/etc</tt> and have it work. Some of these files must be ``installed'' first. This is because the <tt class=3D "FILENAME">/usr/src/etc</tt> directory <i class=3D "EMPHASIS">is not</i> a copy of what your <tt class=3D "FILENAME">/etc</tt> directory should look like. In addition, there are files that should be in <tt class=3D "FILENAME">/etc</tt> that are not in <tt class=3D "FILENAME">/usr/src/etc</tt>.</p> <p>The simplest way to do this by hand is to install the files into a new directory, and then work through them looking for differences.</p> <div class=3D"WARNING"> <blockquote class=3D"WARNING"> <p><b>Backup your existing <tt class=3D "FILENAME">/etc</tt>:</b> Although, in theory, nothing is going to touch this directory automatically, it is always better to be sure. So copy your existing <tt class=3D"FILENAME">/etc</tt> directory somewhere safe. Something like:</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>cp -Rp /etc /etc.old</b></tt> </pre> <p><tt class=3D"OPTION">-R</tt> does a recursive copy, <tt class=3D"OPTION">-p</tt> preserves times, ownerships on files and suchlike.</p> </blockquote> </div> <p>You need to build a dummy set of directories to install the new <tt class=3D"FILENAME">/etc</tt> and other files into. I generally choose to put this dummy directory in <tt class=3D"FILENAME">/var/tmp/root</tt>, and there are a number of subdirectories required under this as well.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>mkdir /var/tmp/root</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>cd /usr/src/etc</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make DESTDIR=3D/var/tmp/root distrib-dirs distribution</b></= tt> </pre> <p>This will build the necessary directory structure and install the files. A lot of the subdirectories that have been created under <tt class=3D"FILENAME">/var/tmp/root</tt> are empty and should be deleted. The simplest way to do this is to:</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>cd /var/tmp/root</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>find -d . -type d | xargs rmdir 2>/dev/null</b></tt> </pre> <p>This will remove all empty directories. (Standard error is redirected to <tt class=3D"FILENAME">/dev/null</tt> to prevent the warnings about the directories that are not empty.)</p> <p><tt class=3D"FILENAME">/var/tmp/root</tt> now contains all the files that should be placed in appropriate locations below <tt class=3D"FILENAME">/</tt>. You now have to go through each of these files, determining how they differ with your existing files.</p> <p>Note that some of the files that will have been installed in <tt class=3D"FILENAME">/var/tmp/root</tt> have a leading ``.''. At the time of writing the only files like this are shell startup files in <tt class=3D "FILENAME">/var/tmp/root/</tt> and <tt class=3D "FILENAME">/var/tmp/root/root/</tt>, although there may be others (depending on when you are reading this. Make sure you use <tt class=3D"COMMAND">ls -a</tt> to catch them.</p> <p>The simplest way to do this is to use <span class=3D "CITEREFENTRY"><span class=3D "REFENTRYTITLE">diff</span>(1)</span> to compare the two files.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>diff /etc/shells /var/tmp/root/etc/shells</b></tt> </pre> <p>This will show you the differences between your <tt class=3D"FILENAME">/etc/shells</tt> file and the new <tt class=3D"FILENAME">/etc/shells</tt> file. Use these to decide whether to merge in changes that you have made or whether to copy over your old file.</p> <div class=3D"TIP"> <blockquote class=3D"TIP"> <p><b>Name the new root directory (<tt class=3D "FILENAME">/var/tmp/root</tt>)with a time stamp, so you can easily compare differences between versions:</b> Frequently remaking the world means that you have to update <tt class=3D"FILENAME">/etc</tt> frequently as well, which can be a bit of a chore.</p> <p>You can speed this process up by keeping a copy of the last set of changed files that you merged into <tt class=3D"FILENAME">/etc</tt>. The following procedure gives one idea of how to do this.</p> <div class=3D"PROCEDURE"> <ol type=3D"1"> <li> <p>Make the world as normal. When you want to update <tt class=3D"FILENAME">/etc</tt> and the other directories, give the target directory a name based on the current date. If you were doing this on the 14th of February 1998 you could do the following.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>mkdir /var/tmp/root-19980214</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>cd /usr/src/etc</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make DESTDIR=3D/var/tmp/root-19980214 \ distrib-dirs distribution</b></tt> </pre> </li> <li> <p>Merge in the changes from this directory as outlined above.</p> <p><i class=3D"EMPHASIS">Do not</i> remove the <tt class=3D"FILENAME">/var/tmp/root-19980214</tt> directory when you have finished.</p> </li> <li> <p>When you have downloaded the latest version of the source and remade it, follow step 1. This will give you a new directory, which might be called <tt class=3D "FILENAME">/var/tmp/root-19980221</tt> (if you wait a week between doing updates).</p> </li> <li> <p>You can now see the differences that have been made in the intervening week using <span class=3D "CITEREFENTRY"><span class=3D "REFENTRYTITLE">diff</span>(1)</span> to create a recursive diff between the two directories.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>cd /var/tmp</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>diff -r root-19980214 root-19980221</b></tt> </pre> <p>Typically, this will be a much smaller set of differences than those between <tt class=3D "FILENAME">/var/tmp/root-19980221/etc</tt> and <tt class=3D"FILENAME">/etc</tt>. Because the set of differences is smaller, it is easier to migrate those changes across into your <tt class=3D "FILENAME">/etc</tt> directory.</p> </li> <li> <p>You can now remove the older of the two <tt class=3D"FILENAME">/var/tmp/root-*</tt> directories.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>rm -rf /var/tmp/root-19980214</b></tt> </pre> </li> <li> <p>Repeat this process every time you need to merge in changes to <tt class=3D "FILENAME">/etc</tt>.</p> </li> </ol> </div> <p>You can use <span class=3D"CITEREFENTRY"><span class=3D "REFENTRYTITLE">date</span>(1)</span> to automate the generation of the directory names.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>mkdir /var/tmp/root-`date "+%Y%m%d"`</b></tt> </pre> </blockquote> </div> </div> <div class=3D"SECT2"> <h2 class=3D"SECT2"><a name=3D"UPDATE-DEV">19.4.11. Update <tt class=3D"FILENAME">/dev</tt></a></h2> <div class=3D"NOTE"> <blockquote class=3D"NOTE"> <p><b>DEVFS:</b> If you are using DEVFS then this is probably unnecessary.</p> </blockquote> </div> <p>For safety's sake, this is a multi-step process.</p> <div class=3D"PROCEDURE"> <ol type=3D"1"> <li> <p>Copy <tt class=3D "FILENAME">/var/tmp/root/dev/MAKEDEV</tt> to <tt class=3D"FILENAME">/dev</tt>.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>cp /var/tmp/root/dev/MAKEDEV /dev</b></tt> </pre> <p>If you used <span class=3D"CITEREFENTRY"><span class=3D"REFENTRYTITLE">mergemaster</span>(8)</span> to update <tt class=3D"FILENAME">/etc</tt>, then your <tt class=3D"FILENAME">MAKEDEV</tt> script should have been updated already, though it can't hurt to check (with <span class=3D"CITEREFENTRY"><span class=3D "REFENTRYTITLE">diff</span>(1)</span>) and copy it manually if necessary.</p> </li> <li> <p>Now, take a snapshot of your current <tt class=3D "FILENAME">/dev</tt>. This snapshot needs to contain the permissions, ownerships, major and minor numbers of each filename, but it should not contain the time stamps. The easiest way to do this is to use <span class=3D"CITEREFENTRY"><span class=3D "REFENTRYTITLE">awk</span>(1)</span> to strip out some of the information.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>cd /dev</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/= tmp/dev.out</b></tt> </pre> </li> <li> <p>Remake all the devices.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>sh MAKEDEV all</b></tt> </pre> </li> <li> <p>Write another snapshot of the directory, this time to <tt class=3D"FILENAME">/var/tmp/dev2.out</tt>. Now look through these two files for any devices that you missed creating. There should not be any, but it is better to be safe than sorry.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>diff /var/tmp/dev.out /var/tmp/dev2.out</b></tt> </pre> <p>You are most likely to notice disk slice discrepancies which will involve commands such as</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>sh MAKEDEV sd0s1</b></tt> </pre> to recreate the slice entries. Your precise circumstances may vary.<br> <br> </li> </ol> </div> </div> <div class=3D"SECT2"> <h2 class=3D"SECT2"><a name=3D"AEN13693">19.4.12. Update <tt class=3D"FILENAME">/stand</tt></a></h2> <div class=3D"NOTE"> <blockquote class=3D"NOTE"> <p><b>Note:</b> This step is included only for completeness. It can safely be omitted.</p> </blockquote> </div> <p>For the sake of completeness, you may want to update the files in <tt class=3D"FILENAME">/stand</tt> as well. These files consist of hard links to the <tt class=3D "FILENAME">/stand/sysinstall</tt> binary. This binary should be statically linked, so that it can work when no other filesystems (and in particular <tt class=3D "FILENAME">/usr</tt>) have been mounted.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>cd /usr/src/release/sysinstall</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make all install</b></tt> </pre> <div class=3D"NOTE"> <blockquote class=3D"NOTE"> <p><b>Source older than 2 April 1998:</b> If your source code is older than 2nd April 1998, or the <tt class=3D"FILENAME">Makefile</tt> version is not 1.68 or higher (for FreeBSD current and 3.X systems) or 1.48.2.21 or higher (for 2.2.X systems) you will need to add the <tt class=3D "USERINPUT"><b>NOSHARED=3Dyes</b></tt> option, like so;</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make NOSHARED=3Dyes all install</b></tt> </pre> </blockquote> </div> </div> <div class=3D"SECT2"> <h2 class=3D"SECT2"><a name=3D"AEN13715">19.4.13. Rebooting</a></h2> <p>You are now done. After you have verified that everything appears to be in the right place you can reboot the system. A simple <span class=3D"CITEREFENTRY"><span class=3D"REFENTRYTITLE">fastboot</span>(8)</span> should do it.</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>fastboot</b></tt> </pre> </div> <div class=3D"SECT2"> <h2 class=3D"SECT2"><a name=3D"AEN13724">19.4.14. Finished</a></h2> <p>You should now have successfully upgraded your FreeBSD system. Congratulations.</p> <p>You may notice small problems due to things that you have missed. For example, I once deleted <tt class=3D "FILENAME">/etc/magic</tt> as part of the upgrade and merge to <tt class=3D"FILENAME">/etc</tt>, and the <tt class=3D "COMMAND">file</tt> command stopped working. A moment's thought meant that</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>cd /usr/src/usr.bin/file</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make all install</b></tt> </pre> was sufficient to fix that one.<br> <br> </div> <div class=3D"SECT2"> <h2 class=3D"SECT2"><a name=3D"AEN13736">19.4.15. Questions?</a></h2> <div class=3D"QANDASET"> <dl> <dt>19.4.15.1. <a href=3D"makeworld.html#Q19.4.15.1.">Do I need to re-make the world for every change?</a></dt> <dt>19.4.15.2. <a href=3D"makeworld.html#Q19.4.15.2.">My compile failed with lots of signal 11 (or other signal number) errors. What has happened?</a></dt> <dt>19.4.15.3. <a href=3D"makeworld.html#Q19.4.15.3.">Can I remove <tt class=3D"FILENAME">/usr/obj</tt> when I have finished?</a></dt> <dt>19.4.15.4. <a href=3D"makeworld.html#Q19.4.15.4.">Can interrupted builds be resumed?</a></dt> <dt>19.4.15.5. <a href=3D"makeworld.html#Q19.4.15.5.">Can I use one machine as a <i class=3D"EMPHASIS">master</i> to upgrade lots of machines (NFS)?</a></dt> <dt>19.4.15.6. <a href=3D"makeworld.html#Q19.4.15.6.">How can I speed up making the world?</a></dt> </dl> <div class=3D"QANDAENTRY"> <div class=3D"QUESTION"> <p><big><a name=3D"Q19.4.15.1."></a><b>19.4.15.1. Do I need to re-make the world for every change?</b></big></p> </div> <div class=3D"ANSWER"> <p><b></b>There is no easy answer to this one, as it depends on the nature of the change. For example, I have just run CVSup, and it has shown the following files as being updated since I last ran it;</p> <pre class=3D"SCREEN"> <tt class=3D"FILENAME">src/games/cribbage/instr.c</tt> <tt class=3D"FILENAME">src/games/sail/pl_main.c</tt> <tt class=3D"FILENAME">src/release/sysinstall/config.c</tt> <tt class=3D"FILENAME">src/release/sysinstall/media.c</tt> <tt class=3D"FILENAME">src/share/mk/bsd.port.mk</tt> </pre> <p>There is nothing in there that I would re-make the world for. I would go to the appropriate sub-directories and <tt class=3D"COMMAND">make all install</tt>, and that's about it. But if something major changed, for example <tt class=3D "FILENAME">src/lib/libc/stdlib</tt> then I would either re-make the world, or at least those parts of it that are statically linked (as well as anything else I might have added that is statically linked).</p> <p>At the end of the day, it is your call. You might be happy re-making the world every fortnight say, and let changes accumulate over that fortnight. Or you might want to re-make just those things that have changed, and are confident you can spot all the dependencies.</p> <p>And, of course, this all depends on how often you want to upgrade, and whether you are tracking -STABLE or -CURRENT.</p> </div> </div> <div class=3D"QANDAENTRY"> <div class=3D"QUESTION"> <p><big><a name=3D"Q19.4.15.2."></a><b>19.4.15.2. My compile failed with lots of signal 11 (or other signal number) errors. What has happened?</b></big></p> </div> <div class=3D"ANSWER"> <p><b></b>This is normally indicative of hardware problems. (Re)making the world is an effective way to stress test your hardware, and will frequently throw up memory problems. These normally manifest themselves as the compiler mysteriously dying on receipt of strange signals.</p> <p>A sure indicator of this is if you can restart the make and it dies at a different point in the process.</p> <p>In this instance there is little you can do except start swapping around the components in your machine to determine which one is failing.</p> </div> </div> <div class=3D"QANDAENTRY"> <div class=3D"QUESTION"> <p><big><a name=3D"Q19.4.15.3."></a><b>19.4.15.3. Can I remove <tt class=3D"FILENAME">/usr/obj</tt> when I have finished?</b></big></p> </div> <div class=3D"ANSWER"> <p><b></b>That depends on how you want to make the world on future occasions.</p> <p><tt class=3D"FILENAME">/usr/obj</tt> contains all the object files that were produced during the compilation phase. Normally, one of the first steps in the ``make world'' process is to remove this directory and start afresh. In this case, keeping <tt class=3D"FILENAME">/usr/obj</tt> around after you have finished makes little sense, and will free up a large chunk of disk space (currently about 150MB).</p> <p>However, if you know what you are doing you can have ``make world'' skip this step. This will make subsequent builds run much faster, since most of sources will not need to be recompiled. The flip side of this is that subtle dependency problems can creep in, causing your build to fail in odd ways. This frequently generates noise on the FreeBSD mailing lists, when one person complains that their build has failed, not realising that it is because they have tried to cut corners.</p> <p>If you want to live dangerously then make the world, passing the <tt class=3D"MAKEVAR">NOCLEAN</tt> definition to make, like this:</p> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make -DNOCLEAN world</b></tt> </pre> </div> </div> <div class=3D"QANDAENTRY"> <div class=3D"QUESTION"> <p><big><a name=3D"Q19.4.15.4."></a><b>19.4.15.4. Can interrupted builds be resumed?</b></big></p> </div> <div class=3D"ANSWER"> <p><b></b>This depends on how far through the process you got before you found a problem.</p> <p><i class=3D"EMPHASIS">In general</i> (and this is not a hard and fast rule) the ``make world'' process builds new copies of essential tools (such as <span class=3D"CITEREFENTRY"><span class=3D "REFENTRYTITLE">gcc</span>(1)</span>, and <span class=3D"CITEREFENTRY"><span class=3D "REFENTRYTITLE">make</span>(1)</span>>) and the system libraries. These tools and libraries are then installed. The new tools and libraries are then used to rebuild themselves, and are installed again. The entire system (now including regular user programs, such as <span class=3D"CITEREFENTRY"><span class=3D "REFENTRYTITLE">ls</span>(1)</span> or <span class=3D "CITEREFENTRY"><span class=3D "REFENTRYTITLE">grep</span>(1)</span>) is then rebuilt with the new system files.</p> <p>If you are at the last state, and you know it (because you have looked through the output that you were storing) then you can (fairly safely) do</p> <pre class=3D"SCREEN"> <i class=3D"EMPHASIS">... fix the problem ...</i> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>cd /usr/src</b></tt> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>make -DNOCLEAN all</b></tt> </pre> <p>This will not undo the work of the previous ``make world''.</p> <p>If you see the message</p> <pre class=3D"SCREEN"> -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- </pre> in the ``make world'' output then it is probably fairly safe to do so.<br> <br> <p>If you do not see that message, or you are not sure, then it is always better to be safe than sorry, and restart the build from scratch.</p> </div> </div> <div class=3D"QANDAENTRY"> <div class=3D"QUESTION"> <p><big><a name=3D"Q19.4.15.5."></a><b>19.4.15.5. Can I use one machine as a <i class=3D"EMPHASIS">master</i> to upgrade lots of machines (NFS)?</b></big></p> </div> <div class=3D"ANSWER"> <p><b></b>People often ask on the FreeBSD mailing lists whether they can do all the compiling on one machine, and then use the results of that compile to <tt class=3D"COMMAND">make install</tt> on to other machines around the network.</p> <p>This is not something I have done, so the suggestions below are either from other people, or deduced from the Makefiles.</p> <p>The precise approach to take depends on your version of FreeBSD</p> <p>You must still upgrade <tt class=3D "FILENAME">/etc</tt> and <tt class=3D "FILENAME">/dev</tt> on the target machines after doing this.</p> <p>For 2.1.7 and below, Antonio Bemfica suggested the following approach:</p> <pre class=3D"SCREEN"> Date: Thu, 20 Feb 1997 14:05:01 -0400 (AST) From: Antonio Bemfica <bemfica@militzer.me.tuns.ca> To: freebsd-questions@FreeBSD.org Message-ID: <Pine.BSI.3.94.970220135725.245C-100000@militzer.me.tuns= .ca> =20 Josef Karthauser asked: =20 > Has anybody got a good method for upgrading machines on a network =20 First make world, etc. on your main machine Second, mount / and /usr from the remote machine: =20 main_machine% mount remote_machine:/ /mnt main_machine% mount remote_machine:/usr /mnt/usr =20 Third, do a 'make install' with /mnt as the destination: =20 main_machine% make install DESTDIR=3D/mnt =20 Repeat for every other remote machine on your network. It works fine for me. =20 Antonio </pre> <p>This mechanism will only work (to the best of my knowledge) if you can write to <tt class=3D "FILENAME">/usr/src</tt> on the NFS server, as the <tt class=3D"MAKETARGET">install</tt> target in 2.1.7 and below needed to do this.</p> <p>Midway between 2.1.7 and 2.2.0 the ``reinstall'' target was committed. You can use the approach exactly as outlined above for 2.1.7, but use ``reinstall'' instead of ``install''.</p> <p>This approach <i class=3D"EMPHASIS">does not</i> require write access to the <tt class=3D "FILENAME">/usr/src</tt> directory on the NFS server.</p> <p>There was a bug introduced in this target between versions 1.68 and 1.107 of the Makefile, which meant that write access to the NFS server <i class=3D "EMPHASIS">was</i> required. This bug was fixed before version 2.2.0 of FreeBSD was released, but may be an issue of you have an old server still running -STABLE from this era.</p> <p>For version 2.2.5 and above, you can use the ``buildworld'' and ``installworld'' targets. Use them to build a source tree on one machine, and then NFS mount <tt class=3D"FILENAME">/usr/src</tt> and <tt class=3D"FILENAME">/usr/obj</tt> on the remote machine and install it there.</p> </div> </div> <div class=3D"QANDAENTRY"> <div class=3D"QUESTION"> <p><big><a name=3D"Q19.4.15.6."></a><b>19.4.15.6. How can I speed up making the world?</b></big></p> <ul> <li> <p>Run in single user mode.</p> </li> <li> <p>Put the <tt class=3D"FILENAME">/usr/src</tt> and <tt class=3D"FILENAME">/usr/obj</tt> directories on separate filesystems held on separate disks. If possible, put these disks on separate disk controllers.</p> </li> <li> <p>Better still, put these filesystems across separate disks using the ``ccd'' (concatenated disk driver) device.</p> </li> <li> <p>Turn off profiling (set ``NOPROFILE=3Dtrue'' in <tt class=3D"FILENAME">/etc/make.conf</tt>). You almost certainly do not need it.</p> </li> <li> <p>Also in <tt class=3D "FILENAME">/etc/make.conf</tt>, set ``CFLAGS'' to something like ``-O -pipe''. The optimization ``-O2'' is much slower, and the optimization difference between ``-O'' and ``-O2'' is normally negligible. ``-pipe'' lets the compiler use pipes rather than temporary files for communication, which saves disk access (at the expense of memory).</p> </li> <li> <p>Pass the <tt class=3D"OPTION">-j<n></tt> option to make (if you are running a sufficiently recent version of FreeBSD) to run multiple processes in parallel. This helps regardless of whether you have a single or a multi processor machine.</p> </li> <li> <p>The filesystem holding <tt class=3D "FILENAME">/usr/src</tt> can be mounted (or remounted) with the ``noatime'' option. This stops the time files in the filesystem were last accessed from being written to the disk. You probably do not need this information anyway.</p> <div class=3D"NOTE"> <blockquote class=3D"NOTE"> <p><b>Note:</b> ``noatime'' is in version 2.2.0 and above.</p> </blockquote> </div> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>mount -u -o noatime /usr/src</b></tt> </pre> <div class=3D"WARNING"> <blockquote class=3D"WARNING"> <p><b>Warning:</b> The example assumes <tt class=3D"FILENAME">/usr/src</tt> is on its own filesystem. If it is not (if it is a part of <tt class=3D"FILENAME">/usr</tt> for example) then you will need to use that filesystem mount point, and not <tt class=3D "FILENAME">/usr/src</tt>.</p> </blockquote> </div> <br> <br> </li> <li> <p>The filesystem holding <tt class=3D "FILENAME">/usr/obj</tt> can be mounted (or remounted) with the ``async'' option. This causes disk writes to happen asynchronously. In other words, the write completes immediately, and the data is written to the disk a few seconds later. This allows writes to be clustered together, and can be a dramatic performance boost.</p> <div class=3D"WARNING"> <blockquote class=3D"WARNING"> <p><b>Warning:</b> Keep in mind that this option makes your filesystem more fragile. With this option there is an increased chance that, should power fail, the filesystem will be in an unrecoverable state when the machine restarts.</p> <p>If <tt class=3D"FILENAME">/usr/obj</tt> is the only thing on this filesystem then it is not a problem. If you have other, valuable data on the same filesystem then ensure your backups are fresh before you enable this option.</p> </blockquote> </div> <pre class=3D"SCREEN"> <tt class=3D"PROMPT">#</tt> <tt class=3D "USERINPUT"><b>mount -u -o async /usr/obj</b></tt> </pre> <div class=3D"WARNING"> <blockquote class=3D"WARNING"> <p><b>Warning:</b> As above, if <tt class=3D "FILENAME">/usr/obj</tt> is not on its own filesystem, replace it in the example with the name of the appropriate mount point.</p> </blockquote> </div> </li> </ul> </div> </div> </div> </div> </div> <div class=3D"NAVFOOTER"> <hr align=3D"LEFT" width=3D"100%"> <table width=3D"100%" border=3D"0" cellpadding=3D"0" cellspacing=3D "0"> <tr> <td width=3D"33%" align=3D"left" valign=3D"top"><a href=3D "synching.html">Prev</a></td> <td width=3D"34%" align=3D"center" valign=3D"top"><a href=3D "index.html">Home</a></td> <td width=3D"33%" align=3D"right" valign=3D"top"><a href=3D "contrib.html">Next</a></td> </tr> <tr> <td width=3D"33%" align=3D"left" valign=3D"top">Synchronizing Your Source</td> <td width=3D"34%" align=3D"center" valign=3D"top"><a href=3D "cutting-edge.html">Up</a></td> <td width=3D"33%" align=3D"right" valign=3D"top">Contributing to FreeBSD</td> </tr> </table> </div> <p align=3D"center"><small>This, and other documents, can be downloaded from <a href=3D "ftp://ftp.FreeBSD.org/pub/FreeBSD/doc">ftp.FreeBSD.org/pub/FreeBSD/doc= /</a>.</small></p> <p align=3D"center"><small>For questions about FreeBSD, read the <a href=3D"http://www.freebsd.org/docs.html">documentation</a>; before contacting <<a href=3D "mailto:questions@FreeBSD.org">questions@FreeBSD.org</a>>.<br> For questions about this documentation, e-mail <<a href=3D "mailto:doc@FreeBSD.org">doc@FreeBSD.org</a>>.</small></p> </body> </html> --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mw.diff" Content-Transfer-Encoding: quoted-printable Index: chapter.sgml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/doc/en_US.ISO_8859-1/books/handbook/cutting-edge/chapt= er.sgml,v retrieving revision 1.59 diff -u -r1.59 chapter.sgml --- chapter.sgml 2001/01/03 13:23:22 1.59 +++ chapter.sgml 2001/03/04 11:53:19 @@ -596,8 +596,8 @@ </tip> </sect2> =20 - <sect2> - <title/Drop to single user mode/ + <sect2 id=3D"makeworld-singleuser"> + <title>Drop to single user mode</title> =20 <para>You may want to compile the system in single user mode. Apart from the obvious benefit of making things go slightly faster, @@ -663,7 +663,7 @@ </sect2> =20 <sect2> - <title/Recompile the source and install the new system/ + <title>Recompile the source</title> =20 <sect3> <title>All versions</title> @@ -767,6 +767,8 @@ <para>Use it like this:</para> =20 <screen>&prompt.root; <userinput>make world</userinput></screen> + + <para>This will also install the new system binaries.</para> </sect3> =20 <sect3> @@ -789,7 +791,7 @@ system will be affected. The build is <quote>self hosted</quote>. Because of this, you can safely run <maketarget>buildworld</maketarget> on a machine running in - multi-user mode with no fear of ill-effects. I still recommend you + multi-user mode with no fear of ill-effects. I still recommend you run the <maketarget>installworld</maketarget> part in single user mode though.</para> =20 @@ -801,31 +803,13 @@ and <filename>/usr/obj</filename> from A, and you can then run <command>make installworld</command> to install the results of=20 the build on B and C.</para> + + <para>Although the <maketarget>world</maketarget> target still exists, + you are strongly encouraged not to use it.</para> =20 - <para>The <maketarget>world</maketarget> target still exists, and - you can use it exactly as shown for version 2.2.2. - <command>make world</command> runs <command>make=20 - buildworld</command> followed by <command>make - installworld</command>.</para> - - <note> - <para>If you do the <command>make buildworld</command> and=20 - <command>make installworld</command> commands separately, you - must pass the same parameters to &man.make.1; each - time.</para> - - <para>If you run:</para> - - <screen>&prompt.root; <userinput>make -DNOPROFILE=3Dtrue buildworld</us= erinput></screen> - - <para>you must install the results with:</para> - - <screen>&prompt.root; <userinput>make -DNOPROFILE=3Dtrue installworld</= userinput></screen> - - <para>otherwise it would try and install profiled libraries that - had not been built during the <command>make buildworld</command> - phase.</para> - </note> + <para>Run</para> + + <screen>&prompt.root; <userinput>make buildworld</userinput></screen> </sect3> =20 <sect3> @@ -841,10 +825,10 @@ =20 <para>On a typical single-CPU machine you would run:</para> =20 - <screen>&prompt.root; <userinput>make -j4 <replaceable>target</replacea= ble></userinput></screen> + <screen>&prompt.root; <userinput>make -j4 buildworld</userinput></scree= n> =20 <para>&man.make.1; will then have up to 4 processes running at any one - time. Empirical evidence posted to the mailing lists shows this + time. Empirical evidence posted to the mailing lists shows this generally gives the best performance benefit.</para> =20 <para>If you have a multi-CPU machine and you are using an SMP @@ -853,27 +837,98 @@ =20 <para>Be aware that (at the time of writing) this is still experimental, and commits to the source tree may occasionally break - this feature. If the world fails to compile using this parameter + this feature. If the world fails to compile using this parameter try again without it before you report any problems.</para> </sect3> =20 <sect3> <title>Timings</title> =20 - <para>Assuming everything goes well you have anywhere between an hour - and a half and a day or so to wait.</para> - <para>As a general rule of thumb, a 200MHz P6 with more than 32MB of - RAM and reasonable SCSI disks will complete <command>make + RAM and reasonable SCSI disks will complete <command>make world</command> in about an hour and a half. A 32MB P133 will take 5 or 6 hours. Revise these figures down if your machines are slower…</para> </sect3> </sect2> =20 + <sect2> + <title>Compile and install a new kernel</title> + + <para>To take full advantage of your new system you should recompile= the + kernel. This is practically a necessity, as certain memory structures + may have changed, and programs like &man.ps.1; and &man.top.1; will + fail to work until the kernel and source code versions are the + same.</para> + + <para>The simplest, safest way to do this is to build and install a + kernel based on <filename>GENERIC</filename>. While + <filename>GENERIC</filename> may not have all the necessary devices + for your system, it should contain everything necessary to boot your + system back to single user mode. This is a good test that the new + system works properly. After booting from + <filename>GENERIC</filename> and verifying that your system works you + can then build a new kernel based on your normal kernel config + file.</para> + + <para>If you are upgrading to FreeBSD 4.0 or above then the standard + kernel build procedure (as described in <xref linkend=3D"kernelconfig">) + is deprecated. Instead, you should run these commands.</para> + + <screen>&prompt.root; <userinput>cd /usr/src</userinput> +&prompt.root; <userinput>make buildkernel</userinput> +&prompt.root; <userinput>make installkernel</userinput></screen> + + <para>If you are upgrading to a version of FreeBSD below 4.0 you sho= uld + use the standard kernel build procedure. However, it is recommended + that you use the new version of &man.config.8;, using a command line + like this.</para> + =20 + <screen>&prompt.root; <userinput>/usr/obj/usr/src/usr.sbin/config/co= nfig <replaceable>KERNELNAME</replaceable></userinput></screen> + </sect2> + + <sect2> + <title>Reboot in to single user mode</title> + + <para>You should reboot in to single user mode to test the new kernel + works. Do this by following the instructions in + <xref linkend=3D"makeworld-singleuser">.</para> + </sect2> + <sect2> - <title>Update files not updated by - <command>make world</command></title> + <title>Install the new system binaries</title> + + <para>If you were building a version of FreeBSD recent enough to have + used <command>make buildworld</command> then you should now use the + <maketarget>installworld</maketarget> to install the new system + binaries.</para> + + <para>Run</para> + + <screen>&prompt.root; <userinput>make installworld</userinput></scre= en> + + <note> + <para>If you specified variables on the <command>make + buildworld</command> command line, you must specify the same + variables in the <command>make installworld</command> command + line.</para> +=09 + <para>For example, if you ran:</para> + + <screen>&prompt.root; <userinput>make -DNOPROFILE=3Dtrue buildworld</user= input></screen> + + <para>you must install the results with:</para> + + <screen>&prompt.root; <userinput>make -DNOPROFILE=3Dtrue installworld</us= erinput></screen> + + <para>otherwise it would try and install profiled libraries that + had not been built during the <command>make buildworld</command> + phase.</para> + </note> + </sect2> + + <sect2> + <title>Update files not updated by <command>make world</command></ti= tle> =20 <para>Remaking the world will not update certain directories (in particular, <filename>/etc</filename>, <filename>/var</filename> and @@ -1132,65 +1187,6 @@ =20 <screen>&prompt.root; <userinput>make NOSHARED=3Dyes all install</userinp= ut></screen> </note> - </sect2> - =20 - <sect2> - <title>Compile and install a new kernel</title> - - <para>To take full advantage of your new system you should recompile= the - kernel. This is practically a necessity, as certain memory structures - may have changed, and programs like &man.ps.1; and &man.top.1; will - fail to work until the kernel and source code versions are the - same.</para> - - <para>Follow the handbook instructions for compiling a new kernel. = If - you have previously built a custom kernel then carefully examine the - <filename>LINT</filename> config file to see if there are any new - options which you should take advantage of.</para> - - <para>A previous version of this document suggested rebooting before - rebuilding the kernel. This is wrong because:</para> - - <itemizedlist> - <listitem> - <para>Commands like &man.ps.1;, &man.ifconfig.8;, and &man.sysctl.8;=20 - may fail. This could leave your machine unable to connect to the - network.</para> - </listitem> - =20 - <listitem> - <para>Basic utilities like &man.mount.8; could fail, - making it impossible to mount <filename>/</filename>, - <filename>/usr</filename> and so on. This is unlikely if you are - tracking a -STABLE candidate, but more likely if you are tracking - -CURRENT during a large merge.</para> - </listitem> - - <listitem> - <para>Loadable kernel modules (LKMs on pre-3.X systems, KLDs on 3.X - systems and above) built as part of the <quote>world</quote> may - crash an older kernel.</para> - </listitem> - </itemizedlist> - - <para>For these reasons, it is always best to rebuild and install a - new kernel before rebooting.</para> - - <para>You should build your new kernel after you have completed - <userinput>make world</userinput> (or <userinput>make - installworld</userinput>). If you do not want to do this (perhaps - you want to confirm that the kernel builds before updating your - system) you may have problems. These may be because your - &man.config.8; command is out of date with respect to your kernel - sources.</para> - - <para>In this case you could build your kernel with the new version = of &man.config.8;</para> - =20 - <screen>&prompt.root; <userinput>/usr/obj/usr/src/usr.sbin/config/co= nfig <replaceable>KERNELNAME</replaceable></userinput></screen> - - <para>This may not work in all cases. It is recommended that you - complete <userinput>make world</userinput> (or <userinput>make - installworld</userinput>) before compiling a new kernel.</para> </sect2> =20 <sect2> --ZGiS0Q5IWpPtfppv-- --PmA2V3Z32TCmWXqI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEUEARECAAYFAjqiLYAACgkQk6gHZCw343WqAgCfZHnPIZmjM7ZzWILeVgPYmjgX MbEAmPazwTyinfz2jnqZR7vFW0Gs1+8= =diIX -----END PGP SIGNATURE----- --PmA2V3Z32TCmWXqI-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010304115649.A420>