BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


Big Scary Daemons Staying Current with NetBSD

by Michael W. Lucas
04/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

Monitoring Network Traffic with Netflow

Information Security with Colin Percival

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.gz

Now 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 ssh

Once 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
Documentation from the Source
By Greg Lehey

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=GENERIC

Eventually, 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
# reboot

Now, 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

Next Pagearrow





Sponsored by: