Updating the system software

In the previous chapter, we looked at how to get an up-to-date FreeBSD source tree. Once you have the sources, you can build various components of the system. The main tool we use for this purpose is make, which we looked at on page 168. The best way to think of upgrading the system is that everything is a matter of changing files. For the purposes of this discussion, you can divide the files on your system into the following categories:

• The userland, that part of the system software that is not the kernel. Unlike some other operating systems, FreeBSD expects to keep userland and kernel at the same release level. We'll look at the interaction between kernel and userland below.
• The kernel. You may build a new kernel without updating the sources, of course, if you want to add functionality to the kernel. In this chapter we'll look at upgrading the kernel in the context of a complete system upgrade. We'll consider building a custom kernel in the next chapter, "Chapter 33" , Custom kernels.
• Support for booting the machine, which is currently performed as a separate step.
• Configuration files relating to your system. Some of them, such as etc/fstab and etc/rc.conf, overlap with the previous category.
• The Ports Collection. This doesn't have to be done at the same time as userland and kernel, though if you upgrade to a significant new version of FreeBSD, it's a good idea to upgrade the ports as well. We looked at upgrading ports on page 178.
• Your own files. They have nothing to do with a software upgrade.

You can make upgrading less onerous by planning in advance. Here are some suggestions:

• Keep system files and user files on different file systems.
• Keep careful records of which configuration files you change, for example with RCS, the Revision Control System. This proves to be the most complicated part of the entire upgrade process.

The only files that are upgraded are on the traditional root file system and /usr. No others are affected by an upgrade. Table 32-1 , an abridged version of Table 10-2 on page 188, gives an overview of where the system files come from.

Upgrading kernel and userland

The core part of a system upgrade consists of a synchronized update of both kernel and userland. It's relatively simple to do, but depending on the speed of the machine, it may keep the computer busy for several hours. In general, you build and install the userland first, then you build and install the kernel.

The traditional way to build the userland is:

# cd /usr/src
# make world

This operation performs a number of functions, which can be influenced by variables you pass to make. Without any variables, make world performs the following steps:

• It removes the old build directories and creates new ones. You can skip this step by setting the NOCLEAN variable. Don't set NOCLEAN unless you know exactly why you are doing so, since it can cause inconsistencies that come back to bite you later. In particular, if you do have problcodes after building the world in this manner, you should first go back and perform a complete rebuild without NOCLEAN.
• It rebuilds and installs build tools, including make, the C compiler and the libraries.
• It builds the rest of the system, with the exception of the kernel and the boot tools.
• It installs everything. You can omit this stage by building the buildworld target instead of world.

It does this by building a number of subtargets. Occasionally, you might find it useful to build them individually: make world can pose a chicken-and-egg problem. It creates the userland, and make kernel makes the kernel. Userland and kernel belong together, and if you upgrade the userland first, you may find that the new userland takes advantage of differences in the newer version of the kernel. A typical situation is when a new system call is added to the kernel. In this case, you may find processes exiting with a signal 12 (invalid system call). If this happens, you may have to perform the upgrade with the sequence:

make buildworld
make kernel
(reboot)
make installworld

You'll find information about such requirements in the file /usr/src/UPDATING. Table 32-2 gives an overview of the more useful targets to the top-level Makefile.

# make buildkernel KERNCONF=MYKERNEL

Another issue is that the system configuration might have changed. For example, in early 2002 the default configuration for sendmail changed. The process added a daemon user and group, both called smmsp. To install the userland, this user already needed to be present.

The solution to this issue is called mergemaster, a script that helps you to upgrade the configuration files. We'll look at it in more detail below, but at this point you should know that you need to run it with the -p (pre-build) option:

# mergemaster -p

As we've seen in table 32-1 , the installworld target changes a number of directories. Sometimes, though, it leaves old binaries behind: it doesn't remove anything that it doesn't replace. The result can be that you end up using old programs that have long passed their use-by date. One solution to this problem is to look at the last modification date of each program in the directories.

For example, if you see:

$ ls -lrt /usr/sbin
-r-xr-xr-x  1  root  wheel     397  Jul  14  11:36  svr4
-r-xr-xr-x  1  root  wheel     422  Jul  14  11:29  linux
-r-xr-xr-x  1  root  wheel  142080  Jul  13  17:20  sshd
…
-r-xr-xr-x  1  root  wheel   68148  Jul  13  17:16  uuchk
-r-xr-xr-x  1  root  wheel    6840  Jan   5   2002  ispppcontrol
-r-xr-xr-x  1  root  wheel   27996  Apr  21   2001  k5stash
-r-xr-xr-x  1  root  wheel   45356  Apr  21   2001  ktutil
-r-xr-xr-x  1  root  wheel   11124  Apr  21   2001  kdb_util
-r-xr-xr-x  1  root  wheel   6768   Apr  21   2001  kdb init

It's fairly clear that the files dated April 2001 have not just been installed, so they must be out of date. You can use a number of techniques to delete them; one might be:

# find . -mtime +10 | xargs rm

This command removes all files in the current directory (.) that are older than 10 days (+10). Of course, this method will only work if you haven't installed anything in these directories yourself. You shouldn't have done so; that's the purpose of the directory hierarchy /usr/local, to ensure that you keep system files apart from ports and private files.

Be careful with /usr/lib: a number of ports refer to libraries in this directory hierarchy, and if you delete them, the ports will no longer work. In general there's no problem with old libraries in /usr/lib, unless they take up too much space, so you're safer if you don't clean out this directory hierarchy.

Note that you need to specify the KERNCONF parameter to all the targets relating to kernel builds.