Testing FreeBSD-Current

04/18/2002

I've heard of a few people that install -current on their systems only to discover a filesystem bug that destroys their data, or that networking isn't working that day. -current has always come with large warnings that say "For developer use only." If the FreeBSD team could get away with it, they would probably use warnings like "Contains live plague bacteria. Beware the Rabid Hippopotami. May cause nausea and vomiting." FreeBSD-current is not for everyone, period.

With the release of FreeBSD 5.0 Developer Preview 1, that's changed somewhat. DP1 is still rough and might very well cause trouble, but a competent systems administrator will find it quite usable. If you've ever wanted to help out the FreeBSD Project, and wanted to experiment with -current, this is a good time to start. With a few simple steps, you can help make 5.0-release the best FreeBSD yet.

If you're new to FreeBSD, -current's DP1 is not the best starting place. If you're new to Unix, don't even think of running DP1. DP1 is not for people who want to run -current to be cool. You should definitely be running a release or, at most, -stable.

DP1 is an excellent choice for those who are interested in developing software for FreeBSD version 5, or those who are interested in helping debug problems.

DP1 is no more supported than any other version of FreeBSD-current. The development team is too busy responding to bug reports and other system issues to help debug problems such as Netscape not running. You can request help from the FreeBSD-questions mailing list, but you'll need a nimble mind to sort out some of the issues that are certain to crop up.

This means that you should install DP1 on a system that you can afford to have down. You can run DP1 on a backup server, or on a server with a hot spare ready to go, or on a desktop. Personally, I run -current on a dual-boot -stable / -current laptop. (We'll look at how that's done in my next article.)

Once you have it installed, though, what do you do with it?

First, run with the various kernel debugging options on. The -currentGENERIC kernel includes the following debugging options.

The INVARIANTS options tells your kernel to double-check its internal data structures. The WITNESS lock carefully evaluates in-kernel locks at all times. WITNESS alone can use up huge amounts of CPU time. The WITNESS_SKIPSPIN option tells the kernel to not monitor the very common, and most probably correct, spin locks. If you really want to help debug -current, you can remove the WITNESS_SKIPSPIN option, but expect your system performance to drop. (Even if you're doing this to help the Project, you might learn that using WITNESS without WITNESS_SKIPSPIN causes too great a performance hit.)

The FreeBSD bug-killers want you to do your best to crash your system through normal use so that bugs can be found and fixed before 5.0-release. To find these problems, however, you must have your system ready to take a crash dump. A report of a DP1 or -current panic without a dump is largely useless.

If you do crash your system, file a problem report. Include the output of your crash dump debugging session, your /var/run/dmesg.boot file, your kernel configuration, and what you were doing at the time. In an ideal world, you would include the precise steps necessary to recreate the crash, but this is quite frequently impossible. ("It was up for an hour, serving some Web pages, and then it crashed" is not an uncommon cause.)

If you're a programmer, feel free to take a stab at a fix. The FreeBSD folks would be delighted to get a suggested patch for a problem. If you're not a programmer, that's OK; just be certain to include your dump debugging session.

Once you have DP1 up and running, you might find that you wish to track -current. All the caveats about running DP1 apply doubly to -current. Remember that -current might not even build on any given day and that upgrades are a much higher risk than the comparatively
tame -stable. Keeping that in mind, there are some things you can do to minimize potential problems.

First, you absolutely must read the FreeBSD-current mailing list hosted at FreeBSD.org. This list discusses the changes that take place in -current and how they impact the system. Note that I said
"read," not "post to." If you're just getting started with -current, you need to listen far more than you talk. Be sure to check the mailing list archives for discussions of your problems, as -current has a lot of new features.

I also recommend reading FreeBSD's cvs-all mailing list, which receives a copy of the log for every change made in the system, ports, documentation, and Web site. Some basic filters will help you get rid of any cvs-all mail you're not interested in. (For example, while I run -current, I don't bother reading the messages for all the ports tree changes.)

My best bit of advice for running -current safely is to run a day old -current. CVSup one day. Watch the -current mailing list for messages of people having problems. If the code seems to be fairly stable and safe, run make buildworld the next day. This will give you an extremely fresh -current, while minimizing your risk of discovering new and exciting system-destroying bugs. You don't want to catch the obvious bugs; any number of people can do that, and they'll quickly fill the mailing list with complaints. The greatest benefit you can provide is to find the bugs that will only affect someone with your particular setup or performing the tasks unique to your operation.

Finally, have patience. -current will very quickly teach you a lot about Unix. It's not for the weak, and it's not for people who want it all immediately. The rewards are vast, but the headaches are larger still.

Next time, we'll discuss a multi-boot -stable / -current laptop, and how you can use this to safely test FreeBSD in an almost-production environment.