Staying Current with NetBSD
by Michael W. Lucas04/10/2003
NetBSD is famous for its multi-platform architecture; it runs on everything from ancient VAXes to modern i386 and Sun servers. In this article we're going to upgrade a NetBSD system from the 1.6 release to the latest NetBSD-current, so I can eventually cross-build an hpcarm release and install it on my new palmtop. (If a UNIX-like palmtop won't ensure my reputation as local "alpha geek," nothing will...)
I've written about NetBSD on a couple of previous occasions, and I still have that same Alpha Multia running NetBSD in my home network providing DNS, filesharing, and other assorted small services. Most of what I touched on in those articles hasn't changed much--the installer is prettier, hardware support is updated, but NetBSD is still a basic, reliable BSD-based system. Cross-building releases on something as old as that Multia isn't such a grand idea, however, so I started over on a modern Athlon system.
The NetBSD Project provides comprehensive documentation on how to
upgrade the operating system. As with many such comprehensive documents,
it's frequently difficult to know which steps you should follow in your
particular situation. This article isn't a comprehensive tutorial that
covers every possible situation; rather, it covers the most common
situation: updating your source with CVS, building that source code, and
installing it on the build machine. While you could have your own source
code repository, or tunnel the whole process through sup(1),
most users just use this method. As the upgrade process is already
sufficiently complicated, we'll cover the ways that are most likely to
succeed. You may find, through further research, ways to optimize your
particular case, but this way will work. We'll consider each of the
following steps in turn:
- Back up your data
- Get the system and package source code
- Update the system and package source code
- Check
/usr/src/UPDATING - Build the new kernel and reboot onto it
- Build the operating system
- Install the system
- Update your configuration
As with any major system change, an upgrade can possibly damage your
system or your data. Be certain that you have backed up all vital data.
I define "vital data" very simply: if the data vanishes, how long will I
spend worrying about it? If it's more than thirty seconds, the data is
vital and might as well be included in the backups. In this particular
case, I'm upgrading a new machine so I don't need to make backups. Never
skip this step on a production system, however. While you may get away
without backups on most occasions, their absence will cause you grief
eventually. If nothing else, be sure you have a backup of your existing
/etc directory. It's very easy during an update to, say,
accidentally overwrite your password file. A convenient backup of
/etc will let you recover easily.
# tar -czvf /etc.tgz /etc|
Also in Big Scary Daemons: Running Commercial Linux Software on FreeBSD Building Detailed Network Reports with Netflow Visualizing Network Traffic with Netflow and FlowScan |
A standard NetBSD install doesn't install the source code or the
pkgsrc tree that allows easy compilation of add-on software.
You could just download all of the code via anonymous CVS, but that's not
an efficient use of network resources or of the anonymous CVS servers.
Instead, start with recent source code and use anonymous CVS to update
that. Grab recent source code from a NetBSD FTP mirror, in the
NetBSD-current/tar_files/ subdirectory. These tarballs are
updated weekly, so you should only require minor updates to get the very
latest source code. You'll see a single tarball for the package source
tree, and subdirectories for the source code and the XFree86 source code.
For now, just grab the system source code and, if desired, the package
source code. All of these need to be extracted under /usr,
i.e.:
# cd /usr
# tar -xzf $HOME/bin.tar.gzNow that you have a recent source code collection, you can update it with anonymous CVS. NetBSD provides a list of anonymous CVS mirrors. Choose one close to you that supports the SSH protocol. While you can also use anonymous CVS in clear-text, in my opinion anything that can be tunneled over an encrypted connection should be. The privacy of CVS updates may not be an issue, but the integrity of the data could be.
Using anonymous CVS over SSH requires two environment variables,
$CVSROOT and $CVS_RSH. With NetBSD's default
csh(1), set them like this.
# setenv CVSROOT anoncvs@anoncvs.netbsd.org:/cvsroot
# setenv CVS_RSH sshOnce you have these in your environment, updating both the system and the package source code is simplicity itself.
# cd /usr/pkgsrc
# cvs -d $CVSROOT update -dPA
# cd /usr/src
# cvs -d $CVSROOT update -dPA|
Related Reading 
The Complete FreeBSD |
These commands will take some time to run; cvs(1)
compares the version of every file in your existing source code tree to
those on the anonymous CVS server. When they finish, however, you'll have
the freshest source code available to anyone. (On subsequent updates from
the same server, you could delete the -d $CVSROOT portion of
the command. It doesn't hurt anything to keep it.)
Now that you have the latest source code, you can check for special
instructions for using the latest -current. The NetBSD team
keeps special notes in the file /usr/src/UPDATING, in reverse
chronological order. Notes in here may only apply to certain
architectures or to certain types of programs. For example, when the new
threading support was merged into the mainline -current,
every threaded add-on program had to be rebuilt to eliminate the reliance
on the old pthreads package. (Some people made extra sure
they won't have problems by rebuilding all the packages on their system
after an upgrade, but that may be overkill for you.)
The NetBSD team makes heavy use of cross-building to support all of
their platforms. Obviously, building the operating system on a VAX or a
Dreamcast would take quite a while; it's much simpler to build on a faster
system and install the resulting binaries on older platforms. While this
is a great idea, the actual cross-building process became quite
complicated very quickly. The NetBSD build process now hides all of this
complexity behind the build.sh shell script. We'll look at
cross-building in a future article, but for now we'll just focus on
building the software natively.
To build the operating system, you first need to build the tools to
build the operating system. We want to start by building the latest
compiler and associated components, and using those to build the latest
NetBSD kernel. Much of this work will take place under
/usr/obj/, so make sure that directory exists first. (If you
don't have that directory, build.sh will die complaining.)
When running an upgrade such as this, it's best to run the GENERIC kernel
for maximum reliability. You can always build a new, customized kernel
once you're sure that the generic kernel works.
# mkdir /usr/obj
# cd /usr/src
# ./build.sh tools kernel=GENERICEventually, the build will finish. Before proceeding, install the new kernel and reboot to it. If you grabbed the source code at the wrong time, the kernel might have problems. It's best to know about those problems as soon as possible, preferably before installing the userland programs that require that version of the kernel. Also, the new userland programs might require system calls that are only available in the new kernel. Here, we install the latest i386 kernel. You'll want to use the proper directory for your architecture.
# cd /usr/src/sys/arch/i386/compile/GENERIC
# make install
# rebootNow, wait to see if your machine ever boots again. If there's a problem with the new kernel, reboot to the old kernel. If your system crashes on the new kernel, or refuses to boot to multiuser mode, you should check the NetBSD-current mailing list archives and see if other people are experiencing the same problem with recent builds. If not, start debugging the problem. (Isn't the latest open source fun?) Often, simply waiting a day and re-upgrading your source code can resolve these issues.
Pages: 1, 2 |
