Index: head/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml =================================================================== --- head/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml +++ head/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml @@ -1067,1044 +1067,445 @@ - - - Using &os.stable; - - &os.stable; is the development branch from which major - releases are made. Changes go into this branch at a slower - pace and with the general assumption that they have first been - tested in &os.current;. This is still a - development branch and, at any given time, the sources for - &os.stable; may or may not be suitable for general use. It is - simply another engineering development track, not a resource - for end-users. Users who do not have the resources to perform - testing should instead run the most recent release of - &os;. - - Those interested in tracking or contributing to the &os; - development process, especially as it relates to the next - release of &os;, should consider following &os.stable;. - - While the &os.stable; branch should compile and run at all - times, this cannot be guaranteed. Since more people run - &os.stable; than &os.current;, it is inevitable that bugs and - corner cases will sometimes be found in &os.stable; that were - not apparent in &os.current;. For this reason, one should not - blindly track &os.stable;. It is particularly important - not to update any production servers to - &os.stable; without thoroughly testing the code in a - development or testing environment. - - To track &os.stable;: - - - -STABLE - using - - - - Join the &a.stable.name; list in order to stay - informed of build dependencies that may appear in - &os.stable; or any other issues requiring special - attention. Developers will also make announcements in - this mailing list when they are contemplating some - controversial fix or update, giving the users a chance to - respond if they have any issues to raise concerning the - proposed change. - - Join the relevant svn list - for the branch being tracked. For example, users - tracking the 9-STABLE branch should join the - &a.svn-src-stable-9.name; list. This list records the - commit log entry for each change as it is made, along - with any pertinent information on possible - side effects. - - To join these lists, go to &a.mailman.lists.link;, - click on the list to subscribe to, and follow the - instructions. In order to track changes for the whole - source tree, subscribe to &a.svn-src-all.name;. - - - - To install a new &os.stable; system, install the most - recent &os.stable; release from the &os; mirror sites or use a - monthly snapshot built from &os.stable;. Refer to www.freebsd.org/snapshots - for more information about snapshots. - - To compile or upgrade to an existing &os; system to - &os.stable;, use svn - - Subversion - to check out the source for the desired - branch. Branch names, such as - stable/9, are listed at www.freebsd.org/releng. - - - - Before compiling or upgrading to &os.stable; - - -STABLE - compiling - , read /usr/src/Makefile - carefully and follow the instructions in . Read &a.stable; and - /usr/src/UPDATING to keep up-to-date - on other bootstrapping procedures that sometimes become - necessary on the road to the next release. - - - - - Synchronizing Source - - There are various methods for staying up-to-date with the - &os; sources. This section describes the primary service, - Subversion. - - - While it is possible to update only parts of the source - tree, the only supported update procedure is to update the - entire tree and recompile all the programs that run in user - space, such as those in /bin and - /sbin, and kernel sources. Updating only - part of the source tree, only the kernel, or only the userland - programs will often result in problems ranging from compile - errors to kernel panics or data corruption. - - - - Subversion - + + Updating &os; from Source - Subversion uses the - pull model of updating sources. The user, - or a cron script, invokes the - svn program which updates the local version - of the source. Subversion is the - preferred method for updating local source trees as updates are - up-to-the-minute and the user controls when updates are - downloaded. It is easy to restrict updates to specific files or - directories and the requested updates are generated on the fly - by the server. How to synchronize source using - Subversion is described in . - - If a user inadvertently wipes out portions of the local - archive, Subversion will detect and - rebuild the damaged portions during an update. - - - - Rebuilding World - - - Rebuilding world - - Once the local source tree is synchronized against a - particular version of &os; such as &os.stable; or &os.current;, - the source tree can be used to rebuild the system. This process - is known as rebuilding world. - - Before rebuilding world, be sure to - perform the following tasks: - - - Perform These Tasks <emphasis>Before</emphasis> - Building World - - - Backup all important data to another system or removable - media, verify the integrity of the backup, and have a - bootable installation media at hand. It cannot be stressed - enough how important it is to make a backup of the system - before rebuilding the system. While - rebuilding world is an easy task, there will inevitably be - times when mistakes in the source tree render the system - unbootable. You will probably never have to use the backup, - but it is better to be safe than sorry! - - - - mailing list - Review the recent &a.stable.name; or &a.current.name; - entries, depending upon the branch being tracked. Be aware - of any known problems and which systems are affected. If a - known issue affects the version of synchronized code, wait - for an all clear announcement to be posted - stating that the problem has been solved. Resynchronize the - sources to ensure that the local version of source has the - needed fix. - - - - Read /usr/src/UPDATING for any - extra steps necessary for that version of the source. This - file contains important information about potential problems - and may specify the order to run certain commands. Many - upgrades require specific additional steps such as renaming - or deleting specific files prior to installing the new - world. These will be listed at the end of this file where - the currently recommended upgrade sequence is explicitly - spelled out. If UPDATING contradicts - any steps in this chapter, the instructions in - UPDATING take precedence and should be - followed. - - - - - Do Not Use <command>make world</command> - - Some older documentation recommends using make - world. However, that command skips some important - steps and should only be used by experts. For almost all - circumstances make world is the wrong thing - to do, and the procedure described here should be used - instead. - - - - Overview of Process - - The build world process assumes an upgrade from an older - &os; version using the source of a newer version that was - obtained using the instructions in . - - In &os;, the term world includes the - kernel, core system binaries, libraries, programming files, - and built-in compiler. The order in which these components - are built and installed is important. - - For example, the old compiler might have a bug and not be - able to compile the new kernel. Since the new kernel should - be built with the new compiler, the new compiler must be - built, but not necessarily installed, before the new kernel is - built. - - The new world might rely on new kernel features, so the - new kernel must be installed before the new world is - installed. The old world might not run correctly on the new - kernel, so the new world must be installed immediately upon - installing the new kernel. - - Some configuration changes must be made before the new - world is installed, but others might break the old world. - Hence, two different configuration upgrade steps are used. - For the most part, the update process only replaces or adds - files and existing old files are not deleted. Since this can - cause problems, /usr/src/UPDATING will - indicate if any files need to be manually deleted and at which - step to do so. - - These concerns have led to the recommended upgrade - sequence described in the following procedure. - - - It is a good idea to save the output from running - make to a file. If something goes wrong, - a copy of the error message can be posted to one of the &os; - mailing lists. - - The easiest way to do this is to use - script with a parameter that specifies - the name of the file to save all output to. Do not save the - output to /tmp as this directory may be - cleared at next reboot. A better place to save the file is - /var/tmp. Run this command immediately - before rebuilding the world, and then type - exit when the process has - finished: - - &prompt.root; script /var/tmp/mw.out -Script started, output file is /var/tmp/mw.out - + Updating &os; by compiling from source offers several + advantages over binary updates. Code can be built with options + to take advantage of specific hardware. Parts of the base + system can be built with non-default settings, or left out + entirely where they are not needed or desired. The build + process takes longer to update a system than binary updates, but + allows complete customization to produce a tailored version of + &os;. + + + Quick Start + + This is a quick reference for the typical steps used to + update &os; by building from source. Later sections describe + the process in more detail. - Overview of Build World Process + + Preparing - The commands used in the build world process should be - run in the order specified here. This section summarizes - the function of each command. + The very first time a computer is updated from source, + run - - If the build world process has previously been run on - this system, a copy of the previous build may still exist - in /usr/obj. To - speed up the new build world process, and possibly save - some dependency headaches, remove this directory if it - already exists: + &prompt.root; etcupdate extract - &prompt.root; chflags -R noschg /usr/obj/* -&prompt.root; rm -rf /usr/obj - + This creates a checkpoint for later comparison and + merging of system settings. - - Compile the new compiler and a few related tools, then - use the new compiler to compile the rest of the new world. - The result is saved to /usr/obj. - - &prompt.root; cd /usr/src -&prompt.root; make buildworld - - - - Use the new compiler residing in /usr/obj to build the new - kernel, in order to protect against compiler-kernel - mismatches. This is necessary, as certain memory - structures may have changed, and programs like - ps and top will fail - to work if the kernel and source code versions are not the - same. - - &prompt.root; make buildkernel - - - - Install the new kernel and kernel modules, making it - possible to boot with the newly updated kernel. If - kern.securelevel has been raised above - 1 and - noschg or similar flags have been set - on the kernel binary, drop the system into single-user - mode first. Otherwise, this command can be run from - multi-user mode without problems. See &man.init.8; for - details about kern.securelevel and - &man.chflags.1; for details about the various file - flags. - - &prompt.root; make installkernel - - - - Drop the system into single-user mode in order to - minimize problems from updating any binaries that are - already running. It also minimizes any problems from - running the old world on a new kernel. - - &prompt.root; shutdown now - - Once in single-user mode, run these commands if the - system is formatted with UFS: - - &prompt.root; mount -u / -&prompt.root; mount -a -t ufs -&prompt.root; swapon -a - - If the system is instead formatted with ZFS, run these - two commands. This example assumes a zpool name of - zroot: - - &prompt.root; zfs set readonly=off zroot -&prompt.root; zfs mount -a - - - - Optional: If a keyboard mapping other than the default - US English is desired, it can be changed with - &man.kbdmap.1;: - - &prompt.root; kbdmap - - - - Then, for either file system, if the - CMOS clock is set to local time (this - is true if the output of &man.date.1; does not show the - correct time and zone), run: - - &prompt.root; adjkerntz -i + This step is only done once on a particular + computer. &man.etcupdate.8; does not need any + additional updates after the first + extract. - Remaking the world will not update certain - directories, such as /etc, - /var and /usr, - with new or changed configuration files. The next step is - to perform some initial configuration file updates - to /etc in - preparation for the new world. The following command - compares only those files that are essential for the - success of installworld. For - instance, this step may add new groups, system accounts, - or startup scripts which have been added to &os; since the - last update. This is necessary so that the - installworld step will be able - to use any new system accounts, groups, and scripts. - Refer to for more detailed - instructions about this command: + Update and Build - &prompt.root; mergemaster -p - - - - Install the new world and system binaries from - /usr/obj. - - &prompt.root; cd /usr/src -&prompt.root; make installworld - - - - Update any remaining configuration files. - - &prompt.root; mergemaster -iF - - - - Delete any obsolete files. This is important as they - may cause problems if left on the disk. - - &prompt.root; make delete-old - - - - A full reboot is now needed to load the new kernel and - new world with the new configuration files. - - &prompt.root; reboot - - - - Make sure that all installed ports have first been - rebuilt before old libraries are removed using the - instructions in . When - finished, remove any obsolete libraries to avoid conflicts - with newer ones. For a more detailed description of this - step, refer to . - - &prompt.root; make delete-old-libs + &prompt.root; svn update /usr/src +check /usr/src/UPDATING +&prompt.root; cd /usr/src +&prompt.root; make -j4 buildworld +&prompt.root; make -j4 kernel +&prompt.root; make installworld +&prompt.root; etcupdate +&prompt.root; shutdown -r now + + + + Get the latest version of the source. See + for + more information on obtaining and updating + source. + + + + Any manual steps required before or after building + from source are shown in + /usr/src/UPDATING. + + + + Go to the source directory. + + + + Compile the world, everything except the + kernel. + + + + Compile and install the kernel. This is + equivalent to + buildkernel + installkernel. + + + + Install the world. + + + + Update and merge configuration files in + /etc/. + + + + Restart the system to use the newly-built world + and kernel. + + + - single-user mode + + Preparing for a Source Update - If the system can have a window of down-time, consider - compiling the system in single-user mode instead of compiling - the system in multi-user mode, and then dropping into - single-user mode for the installation. Reinstalling the - system touches a lot of important system files, all the - standard system binaries, libraries, and include files. - Changing these on a running system, particularly one with - active users, is asking for trouble. + If this is the first time that a source update has + ever been done on this computer, run + etcupdate extract to create a record of + system settings for later update and merging. This step only + needs to be done once on a particular computer. + + Read /usr/src/UPDATING. Any manual + steps that must be performed before or after an update are + described in this file. - - Configuration Files + + Updating the Source - - make.conf - + &os; source code is located in + /usr/src/. The preferred method of + updating this source is through the + Subversion version control system. + Verify that the source code is under version control: + + &prompt.root; svn info /usr/src +Path: /usr/src +Working Copy Root Path: /usr/src +... + + This indicates that /usr/src/ + is under version control and can be updated with + &man.svn.1;: + + &prompt.root; svn update /usr/src + + The update process can take some time if the directory has + not been updated recently. After it finishes, the source code + is up to date and the build process described in the next + section can begin. + + + Obtaining the Source + + If the output says + '/usr/src' is not a working copy, the + files there are missing or were installed with a different + method. A new checkout of the source is required. + + + &os; Versions and Repository Paths + + + + + uname -r Output + Repository Path + Description + + + + + + X.Y-RELEASE + base/releng/X + The Release version plus only critical security + and bug fix patches. This branch is recommended + for most users. + + + + X.Y-STABLE + base/stable/X + + The Release version plus all additional + development on that branch. + STABLE refers to the + Applications Binary Interface + (ABI) not changing, so software + compiled for earlier versions still runs. For + example, software compiled to run on &os; 10.1 + will still run on &os; 10-STABLE compiled + later. + + STABLE branches occasionally have bugs or + incompatibilities which might affect users, + although these are typically fixed quickly. + + + + + X-CURRENT + base/head/ + The latest unreleased development version of + &os;. The CURRENT branch can have major bugs or + incompatibilities and is recommended only for + advanced users. + + + +
+ + Determine which version of &os; is being used with + &man.uname.1;: + + &prompt.root; uname -r +10.3-RELEASE + + Based on + , the + source used to update 10.3-RELEASE has a + repository path of base/releng/10. That + path is used when checking out the source: + + &prompt.root; mv /usr/src /usr/src.bak +&prompt.root; svn checkout https://svn.freebsd.org/base/releng/10 /usr/src + + + + Move the old directory out of the way. If there are + no local modifications in this directory, it can be + deleted. + + + + The path from + is + added to the repository URL. The + third parameter is the destination directory for the + source code on the local system. + + + + - This build world process uses several configuration - files. + + Building from Source - The Makefile located in - /usr/src describes how the programs that - comprise &os; should be built and the order in which they - should be built. - - The options available to make are - described in &man.make.conf.5; and some common examples are - included in - /usr/share/examples/etc/make.conf. Any - options which are added to /etc/make.conf - will control the how make runs and builds - programs. These options take effect every time - make is used, including compiling - applications from the Ports Collection, compiling custom C - programs, or building the &os; operating system. Changes to - some settings can have far-reaching and potentially surprising - effects. Read the comments in both locations and keep in mind - that the defaults have been chosen for a combination of - performance and safety. + The world, or all + of the operating system except the kernel, is compiled. This + is done first to provide up-to-date tools to build the kernel. + Then the kernel itself is built: - - src.conf - + &prompt.root; cd /usr/src +&prompt.root; make buildworld +&prompt.root; make buildkernel - How the operating system is built from source code is - controlled by /etc/src.conf. Unlike - /etc/make.conf, the contents of - /etc/src.conf only take effect when the - &os; operating system itself is being built. Descriptions of - the many options available for this file are shown in - &man.src.conf.5;. Be cautious about disabling seemingly - unneeded kernel modules and build options. Sometimes there - are unexpected or subtle interactions. - + The compiled code is written to + /usr/obj. - - Variables and Targets + These are the basic steps. Additional options to control + the build are described below. - The general format for using make is as - follows: + + Performing a Clean Build + + Some versions of the &os; build system leave + previously-compiled code in the temporary object directory, + /usr/obj. This can speed up later + builds by avoiding recompiling code that has not changed. + To force a clean rebuild of everything, remove + /usr/obj before starting a build. + This is roughly equivalent to performing a + make clean, but much faster: - &prompt.root; make -x -DVARIABLE target + &prompt.root; rm -rf /usr/obj/* + - In this example, - is an option - passed to make. Refer to &man.make.1; for - examples of the available options. - - To pass a variable, specify the variable name with - . The - behavior of the Makefile is controlled by - variables. These can either be set in - /etc/make.conf or they can be specified - when using make. For example, this - variable specifies that profiled libraries should not be - built: - - &prompt.root; make -DNO_PROFILE target - - It corresponds with this setting in - /etc/make.conf: - - NO_PROFILE= true # Avoid compiling profiled libraries - - The target tells - make what to do and the - Makefile defines the available targets. - Some targets are used by the build process to break out the - steps necessary to rebuild the system into a number of - sub-steps. - - Having separate options is useful for two reasons. First, - it allows for a build that does not affect any components of a - running system. Because of this, - buildworld can be safely run on a - machine running in multi-user mode. It is still recommended - that installworld be run in part in - single-user mode, though. - - Secondly, it allows NFS mounts to be - used to upgrade multiple machines on a network, as described - in . - - It is possible to specify which will - cause make to spawn several simultaneous - processes. Since much of the compiling process is - I/O-bound rather than - CPU-bound, this is useful on both single - CPU and multi-CPU - machines. - - On a single-CPU machine, run the - following command to 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. - - &prompt.root; make -j4 buildworld - - On a multi-CPU machine, try values - between 6 and 10 to see - how they speed things up. + + Setting the Number of Jobs - - rebuilding world - timings - + Increasing the number of build jobs on multi-core + processors can improve build speed. Determine the number of + cores with sysctl hw.ncpu. Processors + vary, as do the build systems used with different versions + of &os;, so testing is the only sure method to tell how a + different number of jobs affects the build speed. For a + starting point, consider values between half and double the + number of cores. The number of jobs is specified with + . - - If any variables were specified to make - buildworld, specify the same variables to - make installworld. However, - must never be used - with installworld. + + Increasing the Number of Build Jobs - For example, if this command was used: + Building the world and kernel with four jobs: - &prompt.root; make -DNO_PROFILE buildworld + &prompt.root; make -j4 buildworld buildkernel + + - Install the results with: + + go-fast - &prompt.root; make -DNO_PROFILE installworld + Go-fast: Describe other go-fast options like NO_CLEAN + here. Preferably avoid having different sections for + different versions of &os;. + - Otherwise, the second command will try to install - profiled libraries that were not built during the - make buildworld phase. - - + + Building Only the Kernel - - - Merging Configuration Files + A buildworld must be + completed if the source code has changed. After that, a + buildkernel to build a kernel can + be run at any time. To build just the kernel: - - - - Tom - Rhodes - - Contributed by - - - - - - - mergemaster - - + &prompt.root; cd /usr/src +&prompt.root; make buildkernel + - &os; provides the &man.mergemaster.8; Bourne script to aid - in determining the differences between the configuration files - in /etc, and the configuration files in - /usr/src/etc. This is the recommended - solution for keeping the system configuration files up to date - with those located in the source tree. - - Before using mergemaster, it is - recommended to first copy the existing - /etc somewhere safe. Include - which does a recursive copy and - which preserves times and the ownerships - on files: - - &prompt.root; cp -Rp /etc /etc.old - - When run, mergemaster builds a - temporary root environment, from / down, - and populates it with various system configuration files. - Those files are then compared to the ones currently installed - in the system. Files that differ will be shown in - &man.diff.1; format, with the sign - representing added or modified lines, and - representing lines that will be either removed completely or - replaced with a new file. Refer to &man.diff.1; for more - information about how file differences are shown. - - Next, mergemaster will display each - file that differs, and present options to: delete the new - file, referred to as the temporary file, install the temporary - file in its unmodified state, merge the temporary file with - the currently installed file, or view the results - again. - - Choosing to delete the temporary file will tell - mergemaster to keep the current file - unchanged and to delete the new version. This option is not - recommended. To get help at any time, type - ? at the mergemaster - prompt. If the user chooses to skip a file, it will be - presented again after all other files have been dealt - with. - - Choosing to install the unmodified temporary file will - replace the current file with the new one. For most - unmodified files, this is the best option. - - Choosing to merge the file will present a text editor with - the contents of both files open. The files can be merged by - reviewing both files side by side on the screen and choosing - parts from both to create a finished product. When the files - are compared side by side, l selects the left - contents and r selects contents from the - right. The final output will be a file consisting of both - parts, which can then be installed. This option is - customarily used for files where settings have been modified - by the user. - - Choosing to view the results again will redisplay the file - differences. - - After mergemaster is done with the - system files, it will prompt for other options. It may prompt - to rebuild the password file and will finish up with an option - to remove left-over temporary files. - + &prompt.root; make buildkernel KERNCONF=STORAGESERVER + - - - Deleting Obsolete Files and Libraries + + Installing the Compiled Code - - - - Anton - Shterenlikht - - Based on notes provided by - - - + After the buildworld and + buildkernel steps have been + completed, the new kernel and world are installed: - - Deleting obsolete files and directories - + &prompt.root; cd /usr/src +&prompt.root; make installkernel installworld - As a part of the &os; development lifecycle, files and - their contents occasionally become obsolete. This may be - because functionality is implemented elsewhere, the version - number of the library has changed, or it was removed from the - system entirely. These obsoleted files, libraries, and - directories should be removed when updating the system. - This ensures that the system is not cluttered with old files - which take up unnecessary space on the storage and backup - media. Additionally, if the old library has a security or - stability issue, the system should be updated to the newer - library to keep it safe and to prevent crashes caused by the - old library. Files, directories, and libraries which are - considered obsolete are listed in - /usr/src/ObsoleteFiles.inc. The - following instructions should be used to remove obsolete files - during the system upgrade process. - - After the make installworld and the - subsequent mergemaster have finished - successfully, check for obsolete files and libraries: + If a custom kernel was built, KERNCONF + must also be set to use the new custom kernel: &prompt.root; cd /usr/src -&prompt.root; make check-old +&prompt.root; make installkernel installworld KERNCONF=STORAGESERVER + - If any obsolete files are found, they can be deleted using - the following command: + + Completing the Update - &prompt.root; make delete-old + A few final tasks complete the update. Any modified + configuration files are merged with the new versions, outdated + libraries are located and removed, then the system is + restarted. + + + Merging Configuration Files with + <application>etcupdate</application> + + etcupdate provides an easy + way to merge changes that have been made to system + configuration files with new versions of those files. - A prompt is displayed before deleting each obsolete file. - To skip the prompt and let the system remove these files - automatically, use - BATCH_DELETE_OLD_FILES: + etcupdate + - &prompt.root; make -DBATCH_DELETE_OLD_FILES delete-old + + Merging Configuration Files with + <application>mergemaster</application> - The same goal can be achieved by piping these commands - through yes: + mergemaster -Ui + - &prompt.root; yes|make delete-old + + Checking for Outdated Files and Libraries - - Warning + Some obsolete files or directories can remain after an + update. These files can be located: - Deleting obsolete files will break applications that - still depend on those obsolete files. This is especially - true for old libraries. In most cases, the programs, ports, - or libraries that used the old library need to be recompiled - before make delete-old-libs is - executed. - - - Utilities for checking shared library dependencies include - sysutils/libchk and - sysutils/bsdadminscripts. - - Obsolete shared libraries can conflict with newer - libraries, causing messages like these: - - /usr/bin/ld: warning: libz.so.4, needed by /usr/local/lib/libtiff.so, may conflict with libz.so.5 -/usr/bin/ld: warning: librpcsvc.so.4, needed by /usr/local/lib/libXext.so, may conflict with librpcsvc.so.5 - - To solve these problems, determine which port installed - the library: - - &prompt.root; pkg which /usr/local/lib/libtiff.so - /usr/local/lib/libtiff.so was installed by package tiff-3.9.4 -&prompt.root; pkg which /usr/local/lib/libXext.so - /usr/local/lib/libXext.so was installed by package libXext-1.1.1,1 - - Then deinstall, rebuild, and reinstall the port. To - automate this process, - ports-mgmt/portmaster can be used. After - all ports are rebuilt and no longer use the old libraries, - delete the old libraries using the following command: - - &prompt.root; make delete-old-libs - - If something goes wrong, it is easy to rebuild a - particular piece of the system. For example, if - /etc/magic was accidentally deleted as - part of the upgrade or merge of /etc, - file will stop working. To fix this, - run: + &prompt.root; make check-old - &prompt.root; cd /usr/src/usr.bin/file -&prompt.root; make all install - + and deleted: - - Common Questions + &prompt.root; make delete-old - - - Do I need to re-make the world for every - change? - - - It depends upon the nature of the change. For - example, if svn only shows - the following files as being updated: - - src/games/factor/factor.c -src/games/fortune/fortune/fortune.c -src/usr.sbin/bsdinstall/distextract/distextract.c -src/usr.sbin/bsdinstall/partedit/diskeditor.c -src/share/man/man7/intro.7 - - it probably is not worth rebuilding the entire - world. Instead, go into the appropriate sub-directories - and run make all install. But if - something major changes, such as - src/lib/libc/stdlib, a complete rebuild of - world is highly recommended. - - Some users rebuild world every fortnight and let - changes accumulate over that fortnight. Others only - re-make those things that have changed and are careful - to spot all the dependencies. It all depends on how - often a user wants to upgrade and whether they are - tracking &os.stable; or &os.current;. - - - - - What would cause a compile to fail with lots of - signal 11 - signal 11 - - (or other signal number) errors? - - - This normally indicates a hardware problem. - Building world is an effective way to stress test - hardware, especially memory. A sure indicator of a - hardware issue is when make - is restarted and it dies at a different point in the - process. - - To resolve this error, swap out the components in - the machine, starting with RAM, to determine which - component is failing. - - + Some obsolete libraries can also remain. These can be + detected with: - - Can /usr/obj - be removed when finished? + &prompt.root; make check-old-libs - - This directory contains all the object files that - were produced during the compilation phase. Normally, - one of the first steps in the make - buildworld process is to remove this - directory and start afresh. Keeping - /usr/obj around when finished makes - little sense, and its removal frees up a approximately - 2GB of disk space. - - + and deleted with - - Can interrupted builds be resumed? + &prompt.root; make delete-old-libs - - This depends on how far into the process the - problem occurs. In general, make - buildworld builds new copies of essential - tools and the system libraries. These tools and - libraries are then installed, used to rebuild - themselves, and are installed again. The rest of the - system is then rebuilt with the new system - tools. - - During the last stage, it is fairly safe to run - these commands as they will not undo the work of the - previous make buildworld: - - &prompt.root; cd /usr/src -&prompt.root; make -DNO_CLEAN all - - If this message appears: - - -------------------------------------------------------------- -Building everything.. --------------------------------------------------------------- - - in the make buildworld output, - it is probably fairly safe to do so. - - If that message is not displayed, it is always - better to be safe than sorry and to restart the build - from scratch. - - + Programs which were still using those old libraries will + stop working when the library has been deleted. These + programs must be rebuilt or replaced after deleting the old + libraries. - - Is it possible to speed up making the world? + + When all the old files or directories are known to be + safe to delete, pressing y and + Enter to delete each file can be avoided + by setting BATCH_DELETE_OLD_FILES in + the command. For example: - - Several actions can speed up the build world - process. For example, the entire process can be run - from single-user mode. However, this will prevent users - from having access to the system until the process is - complete. - - Careful file system design or the use of ZFS - datasets can make a difference. Consider putting - /usr/src and - /usr/obj on - separate file systems. If possible, place the file - systems on separate disks on separate disk controllers. - When mounting /usr/src, use - which prevents the file system - from recording the file access time. If /usr/src is not on its - own file system, consider remounting /usr with - . - - The file system holding /usr/obj can be mounted - or remounted with so that disk - writes happen asynchronously. 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 provide a dramatic performance - boost. - - - Keep in mind that this option makes the file - system more fragile. With this option, there is an - increased chance that, should power fail, the file - system will be in an unrecoverable state when the - machine restarts. - - If /usr/obj is the only - directory on this file system, this is not a problem. - If you have other, valuable data on the same file - system, ensure that there are verified backups before - enabling this option. - - - Turn off profiling by setting - NO_PROFILE=true in - /etc/make.conf. - - Pass - to &man.make.1; to run multiple processes in parallel. - This usually helps on both single- and multi-processor - machines. - - + &prompt.root; make BATCH_DELETE_OLD_FILES=yes delete-old-libs + + - - What if something goes wrong? + + Restarting After the Update - - First, make absolutely sure that the environment has - no extraneous cruft from earlier builds: + The last step after updating is to restart the computer + so all the changes take effect: - &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 - - Yes, make cleandir really should - be run twice. - - Then, restart the whole process, starting with - make buildworld. - - If problems persist, send the error and the output - of uname -a to &a.questions;. Be - prepared to answer other questions about the - setup! - - - + &prompt.root; shutdown -r now +