Running a kernel that is newer than your userland will cause problems.
Programs that rely on kernel data structures, such as top(1),
systat(1), and IPFW may not function correctly.
You need to get to a matching userland as soon as possible. Generally
speaking, attempting to build the new userland is a good kernel test.

Once you are confident that your kernel is stable enough to stay up a
while, rebuild the userland software using build.sh. You'll
need to pick a directory to hold your newly-built software distribution.
Here, we put everything in /usr/i386build/.

# ./build.sh -U -D /usr/i386build distribution

If the build does not finish, you might have grabbed source code at a
bad time. Definitely check the NetBSD autobuild status page,
which displays the results of the latest build attempts on the official
NetBSD build machine. If there's a global problem, it will be visible
there. Try again later, and see if the problem is fixed.

If the build completes successfully, you can then install it on your
system at a convenient time. Some people prefer to do this step in
single-user mode, but that's your choice.

# ./build.sh -U -D /usr/i386build install=/

Yes, you could install to a location other than the root directory.
While this might seem senseless, you could use this to install on a hard
drive that you intend to move to a different machine, or even to upgrade a
system over NFS.

You could also do the build and install in a single step. I frequently
build the updated code during production time and then install it during a
maintenance window, but if you're upgrading your personal machine you just
might want to do it all at once.

# ./build.sh -U -D /usr/i386build distribution install=/

As the last step in installing the build, NetBSD performs some basic
system checks to see if obsolete files are left in the tree. This
postinstall script generates output much like this:

First, the postinstall script runs through all of the
standard "default" NetBSD configuration files, such as those in
/etc/defaults, and compares them to the versions in the
latest build. As we see above, it will print out a list of every default
file that doesn't match. The script then churns through a list of user
IDs and group IDs that have been added to the system recently, and checks
to determine if they are in place in the new system. Finally, it will
look for files, man pages, and libraries that have been obsoleted and make
a list of them for removal. The process will end with a statement much
like this:

Of the various groups of postinstall checks, only the
ssh and wscons checks have passed. The
postinstall script has already displayed exactly what the
problems are, and will automatically fix them for you if you just type the
command given. If one of the issues shown isn't applicable on your
system--for example, if you're running a customized version of Postfix and
you don't want the postinstall script to touch anything--just
remove that one test from the command.

After completing the postinstall checks, proceed to update
the rest of /etc. While you could manually compare the
various files in /etc to their updated counterparts in
/usr/src, NetBSD uses the add-on tool
etcupdate(8) (/usr/pkgsrc/sysutils/etcupdate)
specifically for this purpose.

# cd /usr/pkgsrc/sysutils/etcupdate
# make install clean

Much like the mergemaster program used in FreeBSD and
OpenBSD, etcupdate(8) builds a temporary directory populated
by the /etc files from the latest source code.
etcupdate(8) then compares the new files to the ones
currently inhabiting /etc, and displays the differences. You'll then have
the option to keep the current version, install the new version, or merge
the old and new versions. Let's walk through one of each.

Here we see the entire difference between the old and new files is a
version number. (This particular example may be rare in the real world;
most systems have a custom aliases file! It's true for any file with
truly trivial changes, however.) If you were interested, you could use
the NetBSD CVSweb tool
to find out what changes were put in and later removed. In any event,
after displaying the differences, etcupdate(8) gives the
following options:

Please select one of the following operations:
d Don't install the new file
i Install the new file (overwrites your modifications!)
m Merge the currently installed and new files
s Show the differences between the currently installed and new files
v Show the new file
What do you want to do? [Leave it for later]

In this case, we want to install the newer version of the file. While
there is no functional difference, etcupdate(8) will complain
about this file every time you upgrade, so you may as well install the
file and shut the program up. Other files have larger differences, such
as this skeleton .cshrc file.

Previously, new users had a umask of 2. This is no longer set in the
skeleton .cshrc file. Do you want that set for new users?
In this case, I don't want to change the previous system behavior, so I
will tell etcupdate(8) to delete the new file with
d.

I need to remove the news group, add the
smmsp group, and keep mwlucas in the
wheel group. I must merge the old and new files, so I use
etcupdate(8)'s m option.
etcupdate(8) will compare the two files and display each line
that conflicts, with the old version on the left and the new version on
the right, like this.

wheel:*:0:root,mwlucas | wheel:*:0:root
%

We want the entry on the left, so type l and hit ENTER.
etcupdate(8) immediately displays the next conflicting line:

news:*:8: <
%

The group news has been removed from the base system, and
I am not using that group on this computer. Type r and then
ENTER to continue through the file. When you're finished,
etcupdate(8) will let you install the file, try again, or
view the combined file.

Similarly, you'll need to go through every file with local
modifications and compare it to the new configuration. In some cases,
such as /etc/master.passwd, you might be better off using
vipw(8) to add and remove a couple of users rather than walk
through dozens or hundreds of user accounts in etcupdate(8).

Once you have fully updated your /etc directory, reboot
your system. Once it comes up, you'll have fully updated NetBSD-current
on your computer! Over the next few articles, we'll work from that base
to get this new NetBSD onto a palmtop computer.