Author: Peter Seebach
of 4.4BSD, released by the University of California some years ago. As
with Linux, they have full releases and a live CVS tree.
This article discusses why you might want
to run the -current branch of NetBSD, how you would go about it,
and a bit of what could go wrong.
The -current branch of the NetBSD CVS tree represents, as the name
suggests, the current state of development. New hardware support
is always better in NetBSD-current than it is in the formal release
versions. New features can show up in -current a year or more
before they are in any release. Bug fixes may appear overnight.
On the down side, -current doesn’t always compile. When it compiles,
it doesn’t always run. When it runs, it doesn’t always run correctly.
In short, it’s got new code that hasn’t always been fully debugged.
I tend to run NetBSD-current on my laptop; I run it because I value
the hardware support, and I like having current versions of browsers
and other application software. If you’ve got a machine you’re
playing around on, -current makes a lot of sense for it. In the
process of trying to keep a machine up to date, you can learn a
lot. Don’t run it on a production server until you’ve been running
it for a while and you know your way around.
Getting started
Probably the best way to get started is to get a recent “snapshot”
release. A snapshot is
simply a full build from NetBSD-current; using a recent snapshot
instead of an older release may reduce the difficulty of getting
NetBSD compiled and running. This is a
good sanity test for whether you’ll have fun running -current.
Snapshots can be found at the NetBSD FTP site
in directories with names corresponding to the architecture name. For
instance, snapshots for standard PC hardware are in the i386 directory.
If there are no recent snapshots for your platform, you may be able to
cross-compile NetBSD-current from another system, or install the
last major release. Installing a snapshot is, assuming it works,
just like installing a full release. However, new installer designs
are generally tested in snapshots, so the exact details of the
instructions may be a bit off.
Getting the source
Once you’ve got your system up and running with a snapshot, it’s
time to actually build the system. That means source. The simplest
way to get the source is to grab tarballs, but these sometimes
won’t compile simply because someone was checking in changes while
tar was running. If you’re going to be actively tracking
NetBSD-current, you probably want to use anonymous CVS.
To set this up, you need to set the CVSROOT environment variable
to “:pserver:anoncvs@anoncvs.NetBSD.org:/cvsroot.” Once that’s
done, run the command “cvs login;” when it asks for a password,
enter “anoncvs.” Now, you just need to check out the source tree.
Go into the directory you want the source tree to be extracted in,
and run cvs checkout -P src. This’ll take a while,
depending on the speed of your network. That gets you your source
directory. Once you’ve got that in place, you can start building
the system from source.
When the time comes to update, the command is cvs update -d. The
-P-d flag says to add new directories;
the -P flag says to delete old files. These flags
give you the cleanest update of the tree.
Building made easy
Before you do anything else, check the file UPDATING in /usr/src.
Most often, the warnings in here are harmless enough, and following
normal build procedures will work. Occasionally, there are serious
surprises or special cases. Always check here for changes.
NetBSD ships with a script to intelligently run a build, called
build.sh. This is an elaborate process of bootstrapping. First,
the compiler toolchain and related tools are built. Then, the new
tools are used to build system libraries, which are installed in
a temporary directory, then programs are built and linked with
those libraries. The end result is a directory hierarchy which,
if it builds, should be correctly compiled and built. This is done
by simply running
# sh build.sh build
By convention, the build is done into a directory other than the
root directory. My personal habit is to use /usr/src/dest. This
is a safety measure; you don’t want new binaries installed without
corresponding new libraries. To specify a destination directory,
you can edit /etc/mk.conf, or you can just use the -D option:
# sh build.sh -D /usr/src/dest
build
This is equivalent to setting the environment variable DESTDIR, or
setting it as a variable in /etc/mk.conf.
You can even make your own snapshot. If you run a “release” build,
the result is a snapshot for your architecture.
# sh build.sh -D /usr/src/dest -R
/usr/src/release release
Once you’ve built a source tree in a destination directory, you
can install it. The simple way to do this is to execute
# sh build.sh -D /usr/src/dest
install=/
Don’t do this without backups. If something goes wrong, your system
may not be very healthy. Of course, even an unhealthy system may
be good enough to run on for a while, or rebuild, but you may find
it easier to just go back to your backups.
*** Error code 1
One of the common outcomes of a build is that make fails. Generally,
this looks like a message saying “*** Error code 1,” and then
“Stop.”
This can come from any of a number of problems. Often, your source
tree is “out of sync.” That means that a change that affected
multiple files is partially implemented in your source tree. These
problems may go away if you update your source tree. Of course,
it’s virtually guaranteed that they’ll go away eventually in an
update.
To find the cause of the error, first double-check to make sure
that /usr/src/UPDATING doesn’t already warn you about the problem
you’re having. Sometimes you need to compile something, or install
something, before starting. Sometimes, it can be worse. The good
news is, the build process isolates the new tree from the old tree
during building, so you don’t end up with a broken /lib/libc.so
before your new /bin is installed.
You may occasionally need to get a snapshot, or even just the
compiler tools from a more recent snapshot. It should be rare,
but it’s not unheard of. Normally, you can retry the build until
it works. During periods of major upheaval, that can be a week or
two.
It is rare, but certainly possible, for the system to compile just
fine, then refuse to run. There are a number of possible problems.
The most common serious problems to have involve the kernel and
the C library.
Sometimes, the new kernel doesn’t work. Keep an old one, or three,
around. If you’re doing a lot of kernel debugging, don’t just use
make install from your kernel directory. It moves
the contents of your /netbsd directory to /onetbsd to save it, then
copies /netbsd to root (/). That’s great once, but if you do it
several times, the old kernel gets wiped out entirely.
Before a run of kernel work, make a copy of the kernel under a
different name; I like /netbsd.old. That’s your emergency kernel,
in case you make a mistake. To boot to an old kernel, interrupt
the boot loader, then specify the name of the kernel at the boot
loader’s prompt. The syntax looks something like boot.
/netbsd.old
Once the kernel is booting, you may find that you have disk problems.
Disk problems that prevent booting are rare. Rare problems, of
course, are the hardest to get good advice on. In practice, fsck
should be able to fix nearly anything. However, if something went
seriously wrong (remember those backups you made?), you may find
it impractical to answer questions. A lot of problems are best
resolved by typing fsck -yf and going to get something
to drink. The -y flag tells it to assume you always
tell it to go ahead. In most cases, that’s what you want. The
exception is a filesystem with really crucial data on it; mount
that filesystem read-only and copy the data off if you can. The
-f flag tells fsck to recheck filesystems it thinks
are clean — cheap insurance.
In general, fsck will probably work. If fsck is scrolling warnings
and errors off the screen when you come back, you may want a stiffer
drink.
Fixing a busted C library is harder. NetBSD offers a very useful
/rescue directory full of valuable utility programs. Boot into
single-user mode by interrupting the boot loader and booting your
kernel with the -s flag; for instance, boot.
/netbsd -s
When you’re asked for the name of a shell, enter /rescue/sh. There
are a lot of files in /rescue; you don’t get a compiler toolchain,
but basic file manipulation stuff of the sort you’ll need to recover
a system is probably there. You’ll want to change your path to
have /rescue in front of everything else.
If you’ve got a new version of the C library installed, the chances
are you have old ones, too. For instance, if you just installed
/lib/libc.so.12.108, you may still have /lib/libc.so.12.107. Rename
the new one. (Just in case, don’t delete it.) Then fix the symbolic
links; there are two of them, one named “libc.so” and one named
“libc.so.12.” (If libc ever has a major version number bump, that
will be “libc.so.13” or later.) Remove the old links, and make
symbolic links to the C library with the same names again.
Most of the time, libraries other than libc, while annoying to do
without, aren’t quite as crucial to the functioning of a system.
Most programs only need libc to work. The same techniques apply
to debugging other libraries.
It’s possible that a given library is just corrupted. In that
case, installing it from the source tree should work. Once you
get to the point of needing to rebuild libraries, it’s time to look
at using another machine, or your backups, to try again. Note that
the /rescue utility set includes basic networking; if you build a
library on another machine, you can copy it over.
Local color
Sooner or later, if you’re playing around with -current, you will
make your own patches. Sooner or later, this will cause a conflict.
Most often, these conflicts manifest as compiler errors, in which
the compiler chokes on an unexpected stream of <s in code. That
indicates that CVS has helpfully identified a conflict between a
change you made and a change that was made in the CVS tree. This
may turn out to be a patch that you submitted getting applied
slightly differently. More often, it’s just a conflict.
One way to resolve the conflict is just to remove your source file
and run cvs update in that directory. Of course, if
you did have local changes, they’d then be gone. You can also
rename the file, run cvs update, then try to merge
your changes back in.
This is less of an issue with files in /etc, since the system is
pretty good about those. However, there is always room for surprises
in your installation. One common trick among people with small
root filesystems and large /usr partitions is to make /var be a
symbolic link to /usr/var. This sounds great, and it works great
(once you add /usr to $critical_filesystems_local in /etc/rc.conf).
Unfortunately, if you run an install from build.sh, the symlink is
removed, and /var is remade in the root filesystem. You can copy
the files back like this:
# cd /var # pax -r -w -p e . /usr/var # cd .. # mv var var.old # ln -s /usr/var /var
Packages and X11
None of the above refers to the pkgsrc and xsrc distributions — the
source code for third-party packages and for X11R6.
You can retrieve these the same way, using anoncvs.
The system assumes they’ll be loaded in /usr/pkgsrc and /usr/xsrc.
However, it turns out that if you check them out as /usr/src/pkgsrc
and /usr/src/xsrc, a cvs update run in /usr/src updates
all three trees. If you do this, a few programs may need tweaks
to build; for instance, you might need to put the statement
X11SRCDIR=/usr/src/xsrc in /etc/mk.conf.
In general, the pkgsrc tree doesn’t need to be touched, nor do
packages need to be rebuilt, for most changes. There are exceptions;
for instance, a major overhaul of the POSIX threads API in NetBSD
required threaded applications to be rebuilt.
Summary
Running NetBSD -current can be a little harrowing, but it’s the best
way to get new hardware support and try out new features. It also
gives you a chance to send feedback on new changes and designs before
they’re set in stone — and it’s a lot of fun. If you’re looking for
something a little more bleeding edge than year-old stable releases,
and you’d like a stable, well-documented, build process, NetBSD-current
may be for you.
Peter Seebach has been running NetBSD-current since
somewhere around NetBSD 0.8. He has never lost data doing so, but has
had some very exciting close calls. The moral: “always
make backups.”
Category:
- BSD
