NetBSD survival guide

First published: February 01, 2007
Last updated: April 14, 2013

Introduction

This page is a collection of various tips, tricks and fixes I've discovered over years of using NetBSD which help make a user's life easier. It is under perpetual construction.

When using this page, follow the golden rule of getting Unix help off the web: Don't run commands you've never seen before without at least taking a cursory glace and their man page and convincing yourself that they do indeed do what you want! This goes double for commands that need to be run as root.

It is entirely possible that information on this page is out of date, incomplete or flat out wrong. I'm only human. If you think something here needs to be updated, expanded or corrected, please send me an email. Credit will be given for all contributions.

If you can't find the solution to a problem you are having here, I recommend you check out Mr Eriksson's NetBSD FAQ (another page similar in spirit to this one but much older and more thorough), or perhaps the NetBSD Community Wiki (which is a bit younger than this page, but will probably become a pretty solid resource over time). UPDATE: well, both those pages are gone now! If you can't find an answer to your problem here, hit Google or ask on the mailing lists.

Finally, my number one NetBSD tip: enjoy using it!

Quick links

Applications

Audio

Console / Terminal

Kernel Compilation

Package Management

Performance Tweaks

System Administration

Xen-specific matters

X Window System

Applications

Getting a working command line history when running the Python interpreter in interactive mode

If you've used the Python interpreter in interactive mode on any other Unix, you're probably used to being able to use the up and down arrows to scroll back and forward through the different lines of code you've typed so far, just like in your shell. It may come as a rude shock when this doesn't work straight away on NetBSD and you appear doomed to retype long lines of code to fix small typos!

The solution is to install the pkgsrc package devel/py-readline, which adds vastly improved editing abilities to the Python interpreter, including the expected "command line history".

Getting Macromedia/Adobe Flash to work in Firefox

NOTICE: It's been about 5 years since I tried to get the Flash-Firefox combination working in NetBSD. Everything below was correct to the best of my knowledge at the time I wrote it, but the current state of affairs could be very different.

The Flash browser plugin - originally made by Macromedia, who were subsequently bought by Adobe - is available only as compiled binaries for a small number of operating systems and browsers. NetBSD is certainly not among the OSes supported, so if you want to use Flash on your NetBSD machine you have to do a bit of tinkering. Here I discuss getting Flash to work in Mozilla Firefox:

There are a variety of different ways you can try to get Flash to work in Firefox under NetBSD. Don't get your hopes up until you've tried them, though - these methods seem to be very hit and miss. Reports around the net seem to suggest that they work perfectly for some people, only partially for others and for some not at all. I'm not sure why - I really thought computers were deterministic!

Any one of the following may work for you:

Complete Linux emulation

If you install the packages required to do Linux emulation, you can then install a Linux version of Firefox (www/firefox-bin in pkgsrc) and a Linux version of Flash (www/firefox-bin-flash) - the packages required to do Linux emulation will be automatically pulled in as dependencies to either of these two packages. Be warned that the emulation packages can be rather large. The two linux packages should work together to give you a usable Flash setup.

Partial Linux emulation

This solution also uses Linux emulation, but not as much. You can install a NetBSD-native version of Firefox and a Linux version of Flash, then use the www/nspluginwrapper package to let the Linux plugin talk to the NetBSD browser.

I have personally tested this solution on my own machine (running NetBSD 4.0) and it is definitely hit and miss. I've never experienced working audio. Video playback works sometimes and not others - sometimes if I reload a page three or four times it works eventually. The playback can be rather jerky at times. It's not really adequate for any serious Flash needs. Still, some people report the same method working just fine for them.

Windows emulation

I have read that some people have obtained flawlessly working Flash setups by installing the Wine Windows emulator (emulators/wine in pkgsrc - technically, Wine Is Not an Emulator, but you can safely think of it as one) and using it to run the Windows version of Firefox. From within Windows Firefox they can install the Windows version of Flash in the usual simple way.

Free software alternatives

There are a few pieces of free software designed to play Flash files. Reports vary on how well they work. Reverse engineering proprietary file formats is difficult work, so it is reasonable to expect these programs to not work as well as the official Flash player. You still might like to give them a try, though - they may be good enough for your needs. Even if they are not, the chances of the developers of these programs making fixes so that they do suit your needs are substantially greater than the official Flash developers releasing their source code or producing a NetBSD port.

The following free software Flash players are available in pkgsrc:

A YouTube only solution

If the only reason you're after working Flash support is to use YouTube, you may be able to get away without working Flash support at all! The package net/youtube-dl is a simple Python script which takes a YouTube video URL as its only argument and saves that video to your hard drive as a .flv file. You can then play these files with mplayer (and probably other multimedia programs). This is certainly nowhere near as convenient as streaming the video via your browser, but it always works and the video and sound quality are perfect.

Note that tools like this will break whenever YouTube decide to change their URL structure - this certainly has happened before and it very well may happen again.

Audio

Getting rid of unwanted console/terminal beeps

Like most unix-based operating systems, using NetBSD often results in a healthy amount of beeping on behalf of your computer. Sometimes you'd really rather it didn't - I have a laptop which makes absurdly loud beeps, which I don't like it doing when I'm using it on a train or in a coffee house. Fortunately, it's easy enough to turn the beeps off.

On the console

If you're working from the console or a virtual terminal, you can disable beeping by using the wsconsctl(8) command, which lets you adjust all sorts of console-related settings. In theory, to silence the beeping you should run the command:

wsconsctl -w bell.volume=0

which, as you would expect, sets the bell volume to zero. However, it seems that this will not work on all machines, probably due to variations in BIOSes. You may like to try replacing bell.volume with bell.pitch or bell.period (setting either of these to zero effectively disables the bell). Even on machines where the volume setting has no effect, sometimes the other settings do. Strange, but true. You also might like to experiment with various low but non-zero values for these parameters. You can probably find a combination of settings that makes the beep quiet and short enough to be inoffensive, without losing the useful feedback it can provide.

Once you've settled on some settings that you like, you can set them automatically at boot time using a /etc/wscons.conf file.

In X

If you're just working in X, you can type:

$ xset -b

at a terminal emulator to disable beeping for everything you run in that X session (i.e. you don't have to do it once per terminal emulator). Just type:

$ xset b

to bring it back once nobody else is around.

Getting two programs to play audio at the same time

Some operating systems, like Windows and FreeBSD, provide support for kernel sound mixing. What this means is that if two programs try to make sounds at the same time (e.g. your mail client wants to audibly notify you of new mail while your mp3 player is playing your favourite music), the kernel mixes the two sounds together and plays the result so you can hear them both. NetBSD doesn't provide this - the first program which tries to make a sound gets exclusive access to your sound card and no other programs can make sound until the first one has finished. However, there are a number of userland programs to provide sound mixing on NetBSD. It's a little more work to set up, but in my opinion it's the way things really should be - something like sound mixing doesn't belong in the kernel.

There are a number of programs you can use to achieve this, but one of the oldest and most widely supported is the Enlightened Sound Daemon, better known as ESD, which is available from pkgsrc in audio/esound.

Once you've installed ESD, you should start it up (with the command esd) whenever your machine boots (put it in /etc/rc.local). ESD will make a warbling, beeping sort of noise when it starts up unless you give it the -no-beep option, so you should use this. Now it's just a matter of telling your audio producing programs to send their audio to the ESD daemon which is running. Here's how to do that for a few common programs:

It's handy to set up aliases so that the above options are always passed automatically and you don't have to remember them each time. You can set XMMS and BMP up to use ESD without any difficulty, just search through the likely sounding menus. Note that with ESD installed you'll also be able to use the esdplay command to play certain kinds of audio files through ESD. This is a useful command to have called by, e.g., a mail client to inform you of new mail.

Console / Terminal

Enabling console scrolling

If you've come to NetBSD from just about any other open source Unix, you're probably used to being able to "scroll back up" at the console using either Shift and Page Up (Linux, OpenBSD), or Scroll Lock and the arrow keys (FreeBSD). For reasons that I don't entirely understand, NetBSD does not support this console scrolling out of the box. You need to recompile your kernel with support for this turned on. I know, it's bizarre. I believe that this option will be enabled in the default GENERIC kernels after a certain release, perhaps 4.0?

The option in question is WSDISPLAY_SCROLLSUPPORT. You can find instructions for recompiling your kernel in The NetBSD Guide.

Enabling command history scrolling in ksh

If you've come to NetBSD from a Linux or FreeBSD background, the default shell (ksh) will not always act the way you are probably used to after using bash or tcsh. In particular, you're likely to try to scroll back through the history of commands you've entered using the up and down arrows on your keyboard, only to find it doesn't work. A lot of people assume at this point that ksh does not support command histories and install bash from pkgsrc. This not the case at all, so don't run back to the bloat of bash just yet!

ksh actually has two modes - "emacs mode" and "vi mode" - which are designed to act the same way as the two major Unix text editors. By default, ksh uses vi mode. In vi mode, to scroll through your previous commands you first hit Escape (just like you would in vi to exit the editing mode and enter the command mode) and then use the "k" and "j" keys to move up and down (respectively) through previous commands (just like you would use these keys to move up and down through the lines of a text open in vi). Try it! If you are a vi user, you will be pleasantly surprised to learn that everything else you can do in vi will work the same way in vi mode ksh! You can use "b" and "w" to jump back and forward one word at a time, use "0" and "$" "o jump to the beginning and end of the line, etc. Don't forget that once you are done navigating the command history or editing a command, you'll need to press "i" to get back into editing mode before you can type in new characters - just like vi!

If you're an emacs user (or have no idea what I'm talking about and just want simple history scrolling, dammit), you need to use emacs mode. In this mode you will be able to just move up and down through the history with your arrow keys (just like you would use them to move through lines of text in emacs). You can make the switch with:

set -o emacs

To get back into vi mode, simply issue:

set -o vi

If you decide that you like emacs mode better, then you can make it the default by putting the set -o emacs line into your ksh profile.

Getting your command history to persist across logins

By default, your ksh command history is forgotten each time you log out. If you try to scroll back through your commands when you next log in, you'll find nothing there, which can be frustrating if you want to reuse a long or complex command you used last time you logged in (I find this happens a lot with machines that I ssh into a lot).

You can add a line like this one to either your .profile or .ksh file to make your history persist across logins:

HISTFILE=~/.ksh-history

This stores your command history in a dot file called .ksh-history in your home directory (of course, you can call your file whatever you like and put it wherever you like). The number of commands that are saved before new commands start replacing hold ones is controlled by the environment variable $HISTSIZE. The default is 128, which is probably fine, but if disk space isn't a concern you can crank it up a bit.

Setting up more virtual terminals

By default, NetBSD provides a total of 4 virtual terminals you can work at, which are accessed using Ctrl-Alt-F1 through Ctrl-Alt-F4. Some people may like, or be used to, more - e.g., FreeBSD provides 7 by default and most linux distributions provide 6. Fortunately, it's easy to set NetBSD up to give this many as well. There are two steps involved in this.

The first step is to edit your /etc/wscons.conf file. On a default NetBSD system, the part of this file you need to change (it starts at around line 15) initially looks something like this:

# screens to create
#       idx     screen  emul
# Screen 0 is already configured as console in most cases.
#  Uncomment if a serial console is used.
#screen 0       -       vt100
screen  1       -       vt100
screen  2       -       vt100
screen  3       -       vt100
screen  4       -       - 

The changes you need to make to this file are fairly obvious: add extra screen lines similar to those already present until there are as many as you desire.

The second step is to edit your /etc/ttys file, to attach terminals to the new screens you just created. On a default NetBSD system, the uncommented part of this file looks something like this:

console "/usr/libexec/getty Pc"         vt100   on secure
ttyE0   "/usr/libexec/getty Pc"         vt220   off secure
ttyE1   "/usr/libexec/getty Pc"         vt220   on secure
ttyE2   "/usr/libexec/getty Pc"         vt220   on secure
ttyE3   "/usr/libexec/getty Pc"         vt220   on secure
tty00   "/usr/libexec/getty std.9600"   unknown off secure
tty01   "/usr/libexec/getty std.9600"   unknown off secure
tty02   "/usr/libexec/getty std.9600"   unknown off secure
tty03   "/usr/libexec/getty std.9600"   unknown off secure
tty04   "/usr/libexec/getty std.9600"   unknown off secure
tty05   "/usr/libexec/getty std.9600"   unknown off secure
tty06   "/usr/libexec/getty std.9600"   unknown off secure
tty07   "/usr/libexec/getty std.9600"   unknown off secure 

The change needed here is once again fairly clear - simply duplicate the ttyE* lines as many times as necessary, incrementing the number each time.

Making sure your ksh profile applies to terminal emulators in X

Any NetBSD user who makes regular use of the ksh shell is almost certainly going to eventually put favourite settings into their ~/.profile file. These users may at first be surprised to discover that their profile settings work fine from the console or a virtual terminal, but do not seem to work at all from terminal emulators in X.

If you use xterm as your terminal emulator, you can solve this problem by launching it with the -ls option (i.e. by running xterm -ls.

Kernel Compilation

My kernel builds die suddenly with an uninformative error

If you are trying to compile a NetBSD kernel and you find that the process suddenly dies with something very terse and uninformative like this:

cc: Internal error: Killed (program cc1)
Please submit a full bug report.
See <URL:http://www.NetBSD.org/Misc/send-pr.html> for instructions.

Then in my experience the problem is usually memory exhaustion (e.g. if you're building a kernel on a low end VPS or a very old machine). Try adding some swap.

Package Management

Automatically tracking security vulnerabilities in packages

One of the really cool (and I think unique) things about pkgsrc is that it makes it really easy to automatically track when security vulnerabilities are found in third party packages that you have installed. There are two things you need to do to make this happen.

First, you need to add an entry to the root user's cron table to automatically download the file of vulnerability information on a regular basis. This line downloads the file every 24 hours at 3am:

# download vulnerabilities file
0 3 * * * /usr/sbin/pkg_admin fetch-pkg-vulnerabilities >/dev/null 2>&1

The other thing you need to do is run the /usr/sbin/pkg_admin audit command regularly to compare the information in the vulnerabilities file with the packages you have installed. A good way to do this is to add the following line to /etc/security.local

/usr/sbin/pkg_admin audit

This way the package audit will automatically happen as part of the daily security check, and if vulnerabilities are found in any of your packages this will show up in the "daily insecurity output" emails that should be getting sent to your root user's local mail account (or, better yet, to your own local mail account because you set up an alias in /etc/mail/aliases.

Updating all installed packages

I have a lot of nice things to say about pkgsrc, and think it's a good package management system overall. However, there is one quite unfortunate thing that no NetBSD use can deny: pkgsrc is terrible at updating packages. There is no easy and reliable way to bring your entire system up to date with a single command; no equivalent of Debian GNU/Linux's celebrated "apt-get update" or Gentoo Linux's "emerge -u world". This is a real shame, and something of a source of bafflement for me - hasn't pkgsrc been around long enough for this serious problem to be solved?

Anyway, there are a number of third-party programs in pkgsrc that attempt to address this shortcoming, each with their own advantages and disadvantages. Check out the following:

At the moment, my favourite is pkgin. It works with binary packages and is quite similar to apt-get. You can do a pkgin update and then pkgin upgrade (or pkgin full-upgrade) and everything seems to Just Work. But I haven't used it extensively, so maybe it does break things sometimes, and I haven't tried some of the alternatives in a long time so maybe they work just as well these days too. It seems like things are getting better in this department.

Performance Tweaks

Improving disk performance

You can increase general disk performance on NetBSD 5.0 and above by activating WAPBL. Just use the log option when mounting your filesystem. An entry in /etc/fstab might look like this:

/dev/wd0a              /       ffs     rw,log           1 1

This will not make much difference for writing a single large file, but can be a huge improvement if you write a large number of small files. For example, I found that activating WAPBL made unzipping a pkgsrc tarball about ten times faster!

On NetBSD 5.0 and below, you can get some improved performance by mounting with the softdeps option instead of log. WAPBL is not available in releases earlier than NetBSD 5.0, so mounting with log will not work. You can still use softdepts in 5.0, but it has been removed from 6.0 onward.

Improving TCP/IP performance

As described in somewhat more detail at this NetBSD Wiki page, you can improve your networking performance by changing a few sysctl parameters to allocate more memory to some buffers used in sending and receiving from the network.

net.inet.tcp.recvbuf_auto=1
net.inet.tcp.sendbuf_auto=1
net.inet.tcp.sendbuf_max=16777216 
net.inet.tcp.recvbuf_max=16777216

These settings tell NetBSD to automatically increase the size of the network buffers as necessary for performance, up to a maximum of 16MB (32MB total for send and receive). Depending on how much memory you have and how large the files you are transferring are, you may want to set the maxima lower or higher. Note that the default maxima are just 256 kB, and that buffers are not automatically resized. On my lighttpd webserver, this change alone almost doubled the speed with which I could download a ~200MB .zip file.

System Administration

Must-read man pages

NetBSD has great man pages. Here are a few I think every NetBSD administrator should read at least once:

Adding swap space to a running system

If you find that you need to add extra swap space to a system that is already up and running, and you don't have room to add a new swap partition and you don't want to reinstall NetBSD, you can add a swap file which lives somewhere on an ordinary filesystem. I bought a NetBSD VPS from Evorack and found that their systems come with no swap at all by default (which caused memory exhaustion issues when I tried compiling a kernel), and this solution (which I found on the NetBSD site) worked well for me.

The commands below add 128 MB of swap:

# dd if=/dev/zero bs=1m count=128 of=/somefilesystem/swap
# chmod 600 /somefilesystem/swap
# swapctl -a -p 1 /somefilesystem/swap

The first command creates the swapfile at /somefilesystem/swap, the second command changes the permissions so that only root can read or write it, and the third command tells NetBSD to use the file as swap space. The -p 1 option indicates that the file should be used with priority 1. The default priority is 0, which is higher: swap space with priority 1 will only be used when all space with priority 0 is full (and space with priority 2 would only be used if all the priority 0 and 1 space was full, etc). File-based swap is slower than a swap partition, so if you have a partition then give your swapfile priority 1 so that the faster partition is used preferentially. If you do not have a swap partition and the swap file is all you have, you could just as well use priority 0.

To mount the new space space automatically each time you boot up, just add a line to /etc/fstab like this:

/somefilesystem/swap   none    swap    sw,priority=1 0

Checking memory usage

Linux distros usually have a free command which you can run to quickly and easily check how much of your RAM is in use or available. Here's the output of free -m, which displays the information in units of megabytes:

         total       used       free     shared    buffers     cached
Mem:          2513       1923        589          0         71        515
-/+ buffers/cache:       1337       1176
Swap:         1953        142       1810

You might wonder if NetBSD has an equivalent of Linux's free command. As far as I know, it does not. However, it's still possible to get at the same kind of information without too much difficulty.

One way is to have a look at the file /proc/meminfo. Using cat to display this file yields output like this:

    total:    used:    free:  shared: buffers: cached:
Mem:  126648320 111009792 15638528        0 23449600 70270976
Swap: 134217728 65236992 68980736
MemTotal:    123680 kB
MemFree:      15272 kB
MemShared:        0 kB
Buffers:      22900 kB
Cached:       68624 kB
SwapTotal:   131072 kB
SwapFree:     67364 kB

This certainly tells us everything we want to know, but the information is in kilobytes, which is probably not as nice on modern systems as megabytes. As far as I know, you can't change the units used in /proc/meminfo.

A better solution, in my opinion, is to use the top command and use head and tail to pull out just the relevant parts of its output. On the same system that produced the /proc/meminfo output above, if I run the command:

top -n 1 | head -n 5 | tail -n 2

then I get the output:

Memory: 40M Act, 26M Inact, 7056K Wired, 15M Exec, 23M File, 15M Free
Swap: 128M Total, 62M Used, 66M Free

which gives the same information as /proc/meminfo, but is more concise (2 lines rather than 10) and uses megabytes for larger memory amounts. Of course, remembering and typing top -n 1 | head -n 5 | tail -n 2 every time you want to check your memory is a bit of a hassle: if you do this often, you may want to set up free as an alias for this pipeline:

alias free='top -n 1 | head -n 5 | tail -n 2'

Once you've done that, checking memory usage in NetBSD is basically exactly the same as in Linux.

Karsten Kruse wrote to tell me that he wrote a small version of free for NetBSD, and it is available via pkgsrc. It produces output like this:

total         used       free    buffers
Mem:           119         94         25         39
Swap:          128         85         42

The above output was produced with free -m, which gives the output in megabytes. You can also get the output in kilobytes by specifying -k (or just by running free, as kilobytes is the default).

Getting rid of "Nvi saved the file" emails

After a while, if you're not the most careful of people, you may find your NetBSD system sending you a large number of "Nvi saved the file XXX" emails every time you boot it, because you've done reboots while having vi running in background jobs or whatever. Quite often these emails refer to very old files that you may not even have around any more. You can make all of these go away by deleting all the files in /var/tmp/vi.recover/.

Installing extra sets after initial installation

If you don't select all the installation sets during your initial installation of NetBSD, and then change your mind later, it seems like there is no special trick to installing additional ones. Just download the extra sets you want from the /pub/NetBSD/NetBSD-<version>/<arch>/binary/sets/ directory of your favourite NetBSD mirror and unzip and untar them like you would any other tarball. Just note that all the files in the sets have their locations specified with relative, not absolute paths. This means if you untar them in your home directory you'll end up with /home/username/bin/gcc instead of /bin/gcc, so make sure you cd to / first.

Using pkgsrc to set up an Apache webserver with PHP and Postgresql

I found setting up Apache and PHP a little bit confusing, due to the way the relevant pkgsrc packages are named. The relevant packages in this set up are:

The ap-php package dynamically determines which versions of Apache and PHP to use. If you already have Apache and PHP installed when you try to install ap-php, it will install a module appropriate for those two versions. If Apache and PHP are not installed, the latest versions available will be used by default. This means that if you want to use Apache 1.3.x instead of Apache 2 (and you should - the Apache 2 license contains an insidious clause which essentially requires you to consent to the Apache project's use of any patents you may own. I am amazed that they got away with this) you need to install Apache 1.3.x before installing ap-php.

Xen-specific matters

Generating entropy for /dev/random

Like in most Unix systems, the /dev/random device on NetBSD supplies a source of genuinely random (i.e. not pseudorandom) bytes. This random data is generated using various hardware events, like keystrokes, disk interrupts, packets arriving on a network interface, etc, all of which have some degree of randomness associated with them. However, when NetBSD is running on Xen (i.e. as domU), all these techniques of "generating entropy" are disabled by default. The result is that reads from /dev/random will block forever, and the program trying to read the random bytes will appear to hang. Chances are this will be a program involving cryptography somehow, like GnuPG or NetBSD's cgdconfig.

If you think this has happened to you on your NetBSD domU system, run rndctl -l to check (you must be root). If you see something like this:

Source                 Bits Type      Flags
xennet0                   0 net  
xbd0                      0 disk

(i.e. zero bits of entropy free from the network and disk) then you are having this problem.

In order to use the Xen virtual disk and network interface to collect entropy so your crypto programs can keep running, issue the following commands:

rndctl -c -t net
rndctl -c -t disk

If you run entropy-needing programs all the time, you may want to do this automatically at boot time by adding the following to /etc/rc.conf:

rndctl=YES
rndctl_flags="-c -t net; -c -t disk"

Note that the entropy pool will not necessarily fill up quickly as soon as you activate these sources, especially if your disk and network are quiet. Once you've enabled your entropy sources, do something that will generate a lot of disk activity (e.g. find /, ls -R /, du / or anything like that). This should get you producing entropy at a good speed. You also may want to check out the security/bitstir package in pkgsrc: this runs as a daemon in the background and monitors the available entropy, automatically stepping in and using disk activity to regenerate it when it gets low (note that I haven't personally used bitstir so I don't know how well it works).

X Window System

Using X.org instead of XFree86

UPDATE: most of the popular NetBSD ports moved to X.org with the 5.0 release, so you should not need to follow these steps if you are using a modern NetBSD. This information is left here for historical interest, people using a port that still uses XFree86 (although I suspect that the reason some ports still use XFree86 is that X.org is hard to get working, so these instructions may not run smoothly) or folks stuck using very old releases for some reason.

As of NetBSD 3.1 (and this will probably still be the case in NetBSD 4.0, but don't quote me), NetBSD is still in the process of moving away from using the XFree implementation of the X Window System in the default installation to the newer X.org implementation. I believe they're the only major Unix OS not to have done this yet.

You can use X.org right now, though, by installing it through pkgsrc. The meta-package metepackages/xorg will install all of the individual packages required. If you are planning on installing X.org through pkgsrc, it's a good idea to not install any X sets when you install your system, as otherwise you'll have two X installations sitting around, and there's no point in that.

Getting X.org man pages to work

UPDATE: most of the popular NetBSD ports moved to X.org with the 5.0 release, so you should not need to follow these steps if you are using a modern NetBSD. This information is left here for historical interest, people using a port that still uses XFree86 (although I suspect that the reason some ports still use XFree86 is that X.org is hard to get working, so these instructions may not run smoothly) or folks stuck using very old releases for some reason.

If you install X.org from pkgsrc as described above, you will soon find that you can't see any X-related man pages, which can be frustrating. Fortunately, the fix is quite straightforward.

The relevant file here is /etc/man.conf. There is a section of that file which, by default, should look something like this:

# Sections and their directories.
# All paths ending in '/' are the equivalent of entries specifying that
# directory with all of the subdirectories listed for the keyword _subdir.

# default
_default        /usr/{share,X11R6,pkg,local}/man/

# Other sections that represent complete man subdirectories.
X11R6           /usr/X11R6/man/
packages        /usr/pkg/man/
local           /usr/local/man/
doc             /usr/{pkg,share}/doc/{sendmail/op,sendmail/intro} 

It's clear from these lines that the man command does not know that there are man pages stored in /usr/pkg/xorg/man/, which is why it can't find any X-related manual pages. The fix is quite straightforward: remove references to /usr/X11R6/man/, which is empty in our case, and put in references to /usr/pkg/xorg/man/. The section should end up looking something like this:

# Sections and their directories.
# All paths ending in '/' are the equivalent of entries specifying that
# directory with all of the subdirectories listed for the keyword _subdir.

# default
_default        /usr/{share,pkg,pkg/xorg/,local}/man/

# Other sections that represent complete man subdirectories.
packages        /usr/pkg/man/
local           /usr/local/man/
Xorg            /usr/pkg/xorg/man/
doc             /usr/{pkg,share}/doc/{sendmail/op,sendmail/intro}