configuration information, like /etc/passwd or /etc/group. Leave such files unchanged by pressing d.

Pressing m will take you through a file and let you merge the changes. This is a powerful option, and useful once you're comfortable with mergemaster, diff, and the contents of /etc, but beginners are almost certainly better off simply totally replacing or rejecting files.

You can learn all about /etc in Chapter 9.

Device Entries

In Chapter 3 we briefly discussed device nodes, files in the /dev directory that programs can use to send data to and from devices. Then, in Chapter 4 I defined a kernel as the interface between the hardware and the software. When you run an upgrade, these two concepts intersect: The kernel might very well rearrange how it talks to devices, and the interface for how those devices are handled might change. So far in this upgrade process, we haven't changed those special files in /dev, but if you have old device nodes talking to a new kernel, you can get unpredictable behavior. These changes might not happen with every upgrade, but you have to be aware that they're possible.

FreeBSD includes a script that creates correct device nodes, /dev/MAKEDEV. The version of /dev/MAKEDEV distributed with a given kernel is expected to create the correct device nodes for that kernel. Mergemaster compares the /dev/MAKEDEV script from the updated source code with the old script still installed in /dev/MAKEDEV, and it offers to install the new one. Do it.[2] Correct device nodes are not optional. If the /dev/MAKEDEV script has changed, mergemaster will offer to run /dev/MAKEDEV for you. Do that too. Again, correct device nodes are vital.

Last Steps

Once you have completed mergemaster, your system has every piece of the upgrade in place. Just reboot, and you will have completed a FreeBSD upgrade!

Any number of things can go wrong with a system upgrade. The make buildworld command might not finish, or the system might behave oddly afterwards. If something goes wrong, follow a similar process to what you do during a kernel−build failure. Search for the error in the FreeBSD mailing list archives. If the problem isn't discussed there, send the last five or six lines of your build output to FreeBSD−[e-mail], and include the following information:

∙The end of the output of the failed compile

∙Your FreeBSD version number

∙The contents of /var/run/dmesg/boot

∙The output of uname −a

Simplifying the CVSup Upgrade Process

Now that you understand how the upgrade process works, you can simplify it somewhat by making some changes in /etc/make.conf to reduce the CVSup portion of the upgrade process to a two−word command. While I don't prefer to go this route myself, many people do, so here's what you do.

130

First, you'll need to set several variables in /etc/make.conf.

...............................................................................................

SUP_UPDATE= yes

...............................................................................................

The preceding line enables the "make" front end to CVSup.

...............................................................................................

SUP= ./usr/local/bin/cvsup

...............................................................................................

The SUP setting is the default location for CVSup on your system. If you have a custom CVSup replacement, or if you need to specify the full path to the cvsup binary, set it here.

...............................................................................................

SUPFLAGS= −g −L 2

...............................................................................................

This SUPFLAGS setting gives standard flags for your CVSup command. To run CVSup silently, change this to −g −L 0.

...............................................................................................

SUPHOST= cvsup13.FreeBSD.org

...............................................................................................

List a reasonably close FreeBSD cvsup mirror in the SUPHOST line.

...............................................................................................

SUPFILE= /usr/share/examples/cvsup/stable−supfile

...............................................................................................

The SUPFILE value tells CVSup which configuration file to use.

...............................................................................................

PORTSSUPFILE= /usr/share/examples/cvsup/ports−supfile

...............................................................................................

PORTSSUPFILE specifies which supfile should be used to upgrade ports. Don't define this if you don't want to upgrade your ports collection.

...............................................................................................

DOCSUPFILE= /usr/share/examples/cvsup/doc−supfile

...............................................................................................

Finally, DOCSUPFILE is the supfile for the source code of the documents collection. Leave this undefined if you don't want to upgrade your documentation tree (including the Handbook, FAQ, articles, and so on).

Note DOCSUPFILE does not specify the actual documentation, but rather the source code to the documentation. If you don't have the documentation building tools, this is almost useless.

Once you have set these values, you can replace the cvsup stable−supfile command with this one:

131