The first version of NetBSD (0.8) dates back to 1993 and springs from the 4.3BSD Lite operating system, a version of Unix developed at the University of California, Berkeley (BSD = Berkeley Software Distribution), and from the 386BSD system, the first BSD port to the Intel 386 CPU. In the following years, modifications from the 4.4BSD Lite release (the last release from the Berkeley group) were integrated into the system. The BSD branch of Unix has had a great importance and influence on the history of Unix-like operating systems, to which it has contributed many tools, ideas and improvements which are now standard: the vi editor, the C shell, job control, the Berkeley Fast File System, reliable signals, support for virtual memory and TCP/IP, just to name a few. This tradition of research and development survives today in the BSD systems and, in particular, in NetBSD.

NetBSD operates on a vast range of hardware platforms and is very portable. The full source to the NetBSD kernel and userland is available for all the supported platforms; please see the details on the official site of the NetBSD Project.

The basic features of NetBSD are:

These characteristics also bring indirect advantages. For example, if you work on just one platform you could think that you're not interested in portability. But portability is tied to code quality; without a well-written and well-organized code base it would be impossible to support a large number of platforms. And code quality is the base of any good and solid software system, though surprisingly few people seem to understand it.

One of the key characteristics of NetBSD is that its developers are not satisfied with partial implementations. Some systems seem to have the philosophy of “If it works, it's right”. In that light, NetBSD's philosophy could be described as “It doesn't work unless it's right”. Think about how many overgrown programs are collapsing under their own weight and “features” and you'll understand why NetBSD tries to avoid this situation at all costs.

NetBSD supports many platforms, including the popular i386 and amd64, ARM, SPARC, Alpha, Amiga, Atari, and m68k- and PowerPC-based Apple Macintosh machines. Technical details for all of them can be found on the NetBSD site.

The NetBSD site states that: “The NetBSD Project provides a freely available and redistributable system that professionals, hobbyists, and researchers can use in whatever manner they wish”. It is also an ideal system if you want to learn Unix, mainly because of its adherence to standards (one of the project goals) and because it works equally well on the latest PC hardware as well as on hardware which is considered obsolete by many other operating systems. To learn and use Unix you don't need to buy expensive hardware; you can use that old PC or Mac in your attic. It is important to note that although NetBSD runs on old hardware, modern hardware is well supported and care has been taken to ensure that supporting old machines does not inhibit performance on modern hardware. In addition, if you need a Unix system which runs consistently on a variety of platforms, NetBSD is probably your best choice.

Aside from the standard Unix productivity tools, editors, formatters, C/C++ compilers and debuggers, and so on, that are included with the base system, there is a huge collection of packages (currently over 20,000) that can be installed as binary packages or built from pkgsrc, including popular cross-platform software such as Firefox, PostgreSQL, Python, and Xfce.

NetBSD is an Open Source operating system, and as such it is freely available for download from cdn.NetBSD.org and other mirrors.

This is the checklist about the things that should be clear and on-hand now:

This chapter will guide you through the installation process. The concepts presented here apply to all installation methods. The only difference is in the way the distribution sets are fetched by the installer. Some details of the installation differ depending on the NetBSD release. The examples from this chapter were created with NetBSD 8.0.

The installation process is divided logically into two parts. In the first part, you create a partition for NetBSD and write the disklabel for that partition. In the second part, you decide which distribution sets (subsets of the operating system) you want to install and then extract the files into the newly created partition(s).

The NetBSD install program sysinst allows you to change the keyboard layout during the installation. If for some reason this does not work for you, you can use the map in the following table.

To start the installation of NetBSD, insert your chosen boot medium (CD/DVD, USB drive, floppy, etc.) and reboot the computer. The kernel on the installation medium will be booted and it will start displaying a lot of messages on the screen about hardware being detected.

Figure 3.1. Selecting the language

When the kernel has booted, you will find yourself in the NetBSD installation program, sysinst, shown in Figure 3.1, “Selecting the language”. From here on, you should follow the instructions displayed on the screen, using the INSTALL document as a companion reference. You will find the INSTALL document in various formats in the root directory of the NetBSD release. The sysinst screens all have more or less the same layout: the upper part of the screen shows a short description of the current operation or a short help message, and the rest of the screen is made up of interactive menus and prompts. To make a choice, use the cursor keys, the “Ctrl+N” (next) and “Ctrl+P” (previous) keys, or press one of the letters displayed left of each choice. Confirm your choice by pressing the Return (also known as “Enter”) key.

Start by selecting the language you prefer to use for the installation process.

The next screen Figure 3.2, “Selecting a keyboard type” will allow you to select a suitable keyboard type.

Figure 3.2. Selecting a keyboard type

This will bring you to the main menu of the installation program (Figure 3.3, “The sysinst main menu”).

Figure 3.3. The sysinst main menu

Choosing the “Install NetBSD to hard disk” option brings you to the next screen (Figure 3.4, “Confirming to install NetBSD”), where you need to confirm that you want to continue the installation.

Figure 3.4. Confirming to install NetBSD

After choosing “Yes” to continue, sysinst displays a list of one or more disks and asks which one you want to install NetBSD on. In the example of Figure 3.5, “Choosing a hard disk”, two disks are listed, and NetBSD will be installed on “wd0”, the first SATA or IDE disk found. If you use SCSI or external USB disks, the first one will be named “sd0”, the second one “sd1” and so on.

Figure 3.5. Choosing a hard disk

Then the installer will ask you to confirm the detected disk geometry from the information provided by the BIOS, as shown in Figure 3.6, “Disk geometry”. It almost always gives the right values. Choose “This is the correct geometry”, unless you know that the information provided by your BIOS is reportedly incorrect.

Figure 3.6. Disk geometry

The first important step of the installation has come: the partitioning of the hard disk. First, you need to specify whether NetBSD will use a partition (suggested choice) or the whole disk. In the former case it is still possible to create a partition that uses the whole hard disk (Figure 3.7, “Choosing the partitioning scheme”), so we recommend that you select this option as it keeps the BIOS partition table in a format which is compatible with other operating systems.

Figure 3.7. Choosing the partitioning scheme

The next screen shows the current state of the MBR partition table on the hard disk before the installation of NetBSD. There are four primary partitions, and as you can see, this example disk is currently empty. If you do have other partitions you can leave them around and install NetBSD on a partition that is currently unused, or you can overwrite a partition to use it for NetBSD.

Figure 3.8. fdisk

Deleting a partition is simple: after selecting the partition, a menu with options for that partition will appear (Figure 3.9, “Partition options”). Change the partition kind to “Delete partition” to remove the partition. Of course, if you want to use the partition for NetBSD you can set the partition kind to “NetBSD”.

You can create a partition for NetBSD by selecting the partition you want to install NetBSD to. The partition names “a” to “d” correspond to the four primary partitions on other operating systems. After selecting a partition, a menu with options for that partition will appear, as shown in Figure 3.9, “Partition options”.

Figure 3.9. Partition options

To create a new partition, the following information must be supplied:

Choose the partition type “NetBSD” for the new partition (using the “type” option). The installation program will try to guess the “start” position based on the end of the preceding partition. Change this value if necessary. The same thing applies to the “size” option; the installation program will try to fill in the space that is available until the next partition or the end of the disk (depending on which comes first). You can change this value if it is incorrect, or if you do not want NetBSD to use all the suggested amount of space.

After you have chosen the partition type, start position, and size, it is a good idea to set the name that should be used in the boot menu. You can do this by selecting the “bootmenu” option and providing a label, e.g., “NetBSD”. Repeat this step for other bootable partitions, so you can boot both NetBSD and a Windows system (or other operating systems) using the NetBSD bootselector. You can also choose one of the labelled partitions as default for the boot menu. If you are satisfied with the partition options, confirm your choice by selecting “Partition OK”. Choose “Partition table OK” to leave the MBR partition table editor.

If you have made an error in partitioning (for example you have created overlapping partitions) sysinst will display a message and suggest to go back to the MBR partition editor (but you are also allowed to continue). If the data is correct but the NetBSD partition lies outside the range of sectors which is bootable by the BIOS, sysinst will warn you and ask if you want to proceed anyway. Doing so may lead to problems on older PCs.

Next, sysinst will offer to install a boot selector on the hard disk. This screen is shown in Figure 3.10, “Installing the boot selector”.

Figure 3.10. Installing the boot selector

At this point, the BIOS partitions (called slices on BSD systems) have been created. They are also called PC BIOS partitions, MBR partitions or fdisk partitions.

Some platforms, like PC systems (amd64 and i386), use DOS-style MBR partitions to separate file systems. The MBR partition you created earlier in the installation process is necessary to make sure that other operating systems do not overwrite the diskspace that you allocated to NetBSD.

NetBSD uses its own partition scheme, called a disklabel, which is stored at the start of the MBR partition: for more information, refer to Section 2.2.2, “Partitions”. In the next few steps you will create a disklabel(5) and set the sizes of the NetBSD partitions, or use existing partition sizes, as shown in Figure 3.11, “Edit partitions?”.

Figure 3.11. Edit partitions?

When you choose to set the sizes of the NetBSD partitions you can define the partitions you would like to create. The installation program will generate a disklabel based on these settings. This installation screen is shown in Figure 3.12, “Setting partition sizes”.

Figure 3.12. Setting partition sizes

As specified in Figure 3.3, “The sysinst main menu”, the items of the installation menus can be selected pressing the letter displayed left of them. Be careful that, in these menus, they do not always correspond to the BSD disklabel partition letters. For example, third line (letter “c”) of Figure 3.12, “Setting partition sizes” does not refer to the whole NetBSD partition, as well as the fourth line (letter “d”) does not correspond to BSD disklabel partition “d”.

The default partition scheme of just using a big / (root) file system (plus swap) works fine with NetBSD, and there is little need to change this. Figure 3.12, “Setting partition sizes” shows how to change the size of the swap partition to 4096 MB. Note also that partition / is marked with a “+”, so it will occupy all the remaining free space (not located for any other partition). Changing /tmp to reside on a RAM disk (mount_tmpfs(8) or mfs(8)) for extra speed may be a good idea. Other partition schemes may use separate partitions for /var, /usr and/or /home, but you should use your own experience to decide if you need this. When you completed the definition of all the desired partitions, choose “Accept partition sizes”.

The next step is to create the disklabel and edit its partitions, if necessary, using the disklabel editor (Figure 3.13, “The disklabel editor”). If you predefined the partition sizes in the previous step, the resulting disklabel will probably fit your wishes. In that case you can complete the process immediately by selecting “Partition sizes ok”.

Figure 3.13. The disklabel editor

Letters in Figure 3.13, “The disklabel editor” are used for line selection and to represent the corresponding BSD disklabel partitions, with the meaning specified in Section 2.2.2, “Partitions”. In the amd64 port, there are two reserved partitions: “c”, representing the NetBSD partition, and “d”, representing the whole disk. You can edit all the other partitions by using the cursor keys and pressing the Return key, or using their corresponding letters. You can add a partition by selecting an unused slot and setting parameters for that partition. The partition editing screen is shown in Figure 3.14, “Disklabel partition editing”. When you are satisfied with all the values, choose “Partition sizes ok”.

Figure 3.14. Disklabel partition editing

After defining the partitions in the new disklabel, the last item is to enter a name for the NetBSD disk as shown in Figure 3.15, “Naming the NetBSD disk”. This can be used later to distinguish between disklabels of otherwise identical disks.

Figure 3.15. Naming the NetBSD disk

The installer now has all the data it needs to prepare the disk. Nothing has been written to the disk at this point but, and now is your last chance to abort the installation process before actually writing data to the disk. Choose “no” to abort the installation process and return to the main menu, or continue by selecting “yes”.

Figure 3.16. Last chance to abort

After confirming that sysinst should prepare the disk, it will run disklabel(8) to create the NetBSD partition layout and newfs(8) to create the file systems on the disk.

After preparing the NetBSD partitions and their filesystems, the next question (shown in Figure 3.17, “Selecting bootblocks”) is which bootblocks to install. Usually you will choose the default of BIOS console, i.e., show boot messages on your computer's display.

If you run a farm of machines without monitor, it may be more convenient to use a serial console running on one of the serial ports. The menu also allows changing the serial port's baud rate from the default of 9600 baud, 8 data bits, no parity and one stopbit.

Figure 3.17. Selecting bootblocks

The installer will then ask whether you want to do a full, minimal or custom installation. NetBSD is broken into a collection of distributions sets. “Full installation” is the default and will install all sets; “Minimal installation” will only install a small core set, the minimum of what is needed for a working system. If you select “Custom installation” you can select which sets you would like to have installed. This step is shown in Figure 3.18, “Full or custom installation”.

Figure 3.18. Full or custom installation

If you choose to do a custom installation, sysinst will allow you to choose which distribution sets to install, as shown in Figure 3.19, “Selecting distribution sets”. At a minimum, you must select a kernel and the “Base” and “Configuration files (/etc)” sets.

Figure 3.19. Selecting distribution sets

At this point, you have finished the first and most difficult part of the installation!

The second half of the installation process consists in populating the file systems by extracting the distribution sets that you selected earlier (“Base”, “Compiler tools”, “Games”, etc.). Now sysinst needs to find the NetBSD sets and you must tell it where to find them: it can be the same medium where sysinst resides, or a different one, according to your preferences. The menu offers several choices, as shown in Figure 3.20, “Installation media”. The options are explained in detail in the INSTALL documents.

Figure 3.20. Installation media

3.11.2. Installing from an unmounted file system

Figure 3.21, “Mounting a file system” shows the menu to install NetBSD from an unmounted file system. It is necessary to specify the device (“Device”), its file system type (“File system”) and a root directory inside it (“Base directory”). The binary installation sets and the source sets are .tgz files. The default mountpoint is “mnt” in amd64. The path is formed as follows:

/<default mountpoint>/<Base directory>/<Binary set directory> or <Source set directory>/set.tgz

Choose a combination of “Base directory” and “Binary set directory” (or “Source set directory”) that generates a valid path in your unmounted filesystem. If more than one consecutive / appear, only the first / will actually be considered. You need to specify a “Source set directory” only if you previously chose to install some sources. Source sets are usually not included in the installation images.

In the following example the install sets are stored on a MSDOS file system, on partition “e” on the device “sd0”.

Figure 3.21. Mounting a file system

Specify the device name and the partition. Figure 3.22, “Mounting a partition ” shows how to specify device "sd0" with partition "e".

Figure 3.22. Mounting a partition

In Figure 3.23, “Accessing a MSDOS file system” the file system type specified is “msdos”. This value is used to form the command mount_<File system> to mount the volume. Any string (representing a “File system” type) which forms a valid command is accepted: for example, the NetBSD file system “ffs” or “ext2fs”, a Linux file system. In this example, the “Base directory” item is left blank and the binary sets are stored under /sets, so that the path becomes:

/mnt///sets

Ignoring the multiple /, this is equivalent to /mnt/sets and it is a valid one. Choosing “Continue” will start the extraction of the sets.

Figure 3.23. Accessing a MSDOS file system

3.11.3. Installing via FTP and Network configuration

If you choose to install from a local network or the Internet via FTP, sysinst must be instructed to properly get the distribution sets, as shown in Figure 3.24, “Defining the FTP settings”.

Figure 3.24. Defining the FTP settings

The defaults work most of the time. You also need to configure your network connection, before proceeding: go to the corresponding menu item, pressing letter “j”.

NetBSD currently supports installation via ethernet, USB ethernet or wireless, and wireless LAN. Installation via DSL (PPP over Ethernet) is not supported during installation.

In the first step, shown in Figure 3.25, “Which network interface to configure”, the network card to be configured must be selected. sysinst will determine a list of available network interfaces, present them and ask which one to use.

Figure 3.25. Which network interface to configure

Note

The exact names of your network interfaces depend on the hardware you use. Example interfaces are “wm” for Intel Gigabit interfaces, “ne” for NE2000 and compatible ethernet cards, and “ath” for Atheros based wireless cards. This list is by no means complete, and NetBSD supports many more network devices.

If your network device is not listed in Figure 3.25, “Which network interface to configure”, maybe it has not been properly detected. To get a list of network interfaces available on your system, interrupt the installation process by pressing “Ctrl+Z”, then enter

# ifconfig -a
wm0: flags=0x8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        capabilities=2bf80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
        capabilities=2bf80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Tx>
        capabilities=2bf80<UDP6CSUM_Tx>
        enabled=0
        ec_capabilities=7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
        ec_enabled=0
        address: 08:00:27:7e:85:d7
        media: Ethernet autoselect (1000baseT full-duplex)
        status: active
lo0: flags=0x8048<LOOPBACK,RUNNING,MULTICAST> mtu 33624

If the desired interface has not been shown, get more information about all the devices found during system boot. Type:

# dmesg | more

As instructed, you can return to the NetBSD installation by typing either “exit” or “^D” (“Ctrl+D”).

Next, you have a chance to set your network medium. Press “Enter” to choose the default.

Note

It is unlikely that you will need anything other than the default here. If you experience problems like very slow transfers or timeouts, you may, for example, force different duplex settings for ethernet cards. To get a list of supported media and media options for a given network device (“wm0”, for example), escape from sysinst by pressing “Ctrl+Z”, then enter:

# ifconfig -m wm0
wm0: flags=0x8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        capabilities=2bf80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
        capabilities=2bf80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Tx>
        capabilities=2bf80<UDP6CSUM_Tx>
        enabled=0
        ec_capabilities=7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
        ec_enabled=0
        address: 08:00:27:7e:85:d7
        media: Ethernet autoselect (1000baseT full-duplex)
        status: active
        supported Ethernet media:
                media none
                media 10baseT
                media 10baseT mediaopt full-duplex
                media 100baseTX
                media 100baseTX mediaopt full-duplex
                media autoselect

The several values printed after “media” may be of interest here, including keywords like “autoselect” but also including any “mediaopt” settings.

Return to the installation by typing “exit” or “^D” (“Ctrl+D”).

The next question, shown in Figure 3.26, “Using autoconfiguration”, is whether you want to perform autoconfiguration. This procedure uses DHCP (Dynamic Host Configuration Protocol). sysinst will fetch a number of defaults from it, giving most likely the correct settings. This procedure is recommended, unless you want to set a static IP address, and/or specify some custom parameters.

Figure 3.26. Using autoconfiguration

You will then be asked for your “DNS domain”; if the machine is not in a registered public domain, it can be left blank.

At the end of this procedure, a list of all the settings is shown, as in Figure 3.27, “Confirm autoconfiguration”. If they are correct, choose “Yes”. Otherwise, choosing “No”, the network configuration will restart from the beginning, giving the opportunity to perform again all the steps (and also to perform a manual configuration).

Figure 3.27. Confirm autoconfiguration

If you chose “No” in Figure 3.26, “Using autoconfiguration”, you will be asked several questions to manually configure the network. All the parameters are presented in the form “Parameter_name [default_value]:”. Press “Enter” to use the default value. If no default value is provided, the parameter will be left blank.

Your host name:

The name by which other machines can usually address your computer. Not used during installation.

Your DNS Domain:

This is the name of the domain you are in. You may leave it blank if you are not in a public domain.

Your IPv4 address:

Enter your numerical Internet Protocol address in “dotted quad” notation here, for example, 192.168.1.3. It will be used as a static IP for your network card.

IPv4 Netmask:

The netmask for your network, either given as a hex value (“0xffffff00”) or in dotted-quad notation (“255.255.255.0”).

IPv4 gateway:

Your router's (or default gateway's) IP address. Do not use a hostname here!

Your name server:

Your (first) DNS server's IP address. Again, don't use a hostname.

After answering all of your network configuration info, their list is shown as in Figure 3.27, “Confirm autoconfiguration”. You will have a chance to go back and make changes. If you are satisfied with your settings, choose “Yes”.

sysinst will now run a few commands (not displayed in detail here) to configure the network: flushing the routing table, setting the default route, and testing if the network connection is operational.

Now that you have a functional network connection, the menu in Figure 3.24, “Defining the FTP settings” will be shown again. Choose “Get Distribution” to continue: sysinst will download the selected set files to a temporary directory, and then extract them.

3.11.4. Installing via NFS

If you want to install NetBSD from a server in your local network, NFS is an alternative to FTP.

Note

Using this installation method requires the ability to set up an NFS server, a topic which is not discussed here.

As shown in Figure 3.28, “NFS install screen”, you must specify: the IP address of the NFS server as “Host”; the directory exported by the NFS server as “Base directory”; the directory containing the install sets as “Set directory”.

Figure 3.28. NFS install screen

Figure 3.29, “NFS example” shows an example: Host “192.168.1.50” is the NFS server which exports the directory /home/username/Downloads. The NetBSD install sets are stored in /home/username/Downloads/sets on the NFS server. Choose “Continue” to start the installation of the distribution sets.

Figure 3.29. NFS example

After the method to obtain the distribution sets has been chosen, and (if applicable) after those sets have been transferred, they will be extracted into the new NetBSD file system.

A message (see Figure 3.30, “Extraction of sets completed”) will let you know that the set extraction is now completed and that you have the opportunity to perform some essential configuration before finishing the NetBSD installation.

Figure 3.30. Extraction of sets completed

A menu with all the available configuration options is shown like in Figure 3.31, “Configuration menu”. After the configuration of each item, you will get back to this menu, having the chance to select another one.

Figure 3.31. Configuration menu

If you have not yet configured Network, you can do it now, following the same procedure already presented in Section 3.11.3, “Installing via FTP and Network configuration”.

The timezone can also be configured. It is Universal Time Coordinated (UTC) by default. Use the two-level menu of Continents/Countries and cities shown in Figure 3.32, “Selecting the system's time zone” to select your local timezone with the Return key. After a valid selection, the cursor will automatically be moved to an “Exit” item. Then, simply press Return to exit the timezone selection.

Figure 3.32. Selecting the system's time zone

The next item in Figure 3.31, “Configuration menu” allows you to choose which command-line interpreter - also known as “shell” - will be used for the root account. The default is the Bourne-compatible Almquist shell, sh(1). Other choices are the Korn shell (ksh(1)) and the C shell (csh(1)). If, upon reading this, you don't have some idea on which shell you prefer, simply use the default, as this is a highly subjective decision. Should you later change your mind, root's shell can always be changed.

Figure 3.33. Choosing a shell

The root account still does not have a password. It is recommended to set it at this point for security reasons, choosing the related item in Figure 3.31, “Configuration menu”.

Figure 3.34. Set a root password?

When you agree to set a root password, sysinst will run the passwd(1) utility for you. Please note that the password is not echoed.

Figure 3.35. Setting root password

To ease the future installation of binary packages, it is possible to make a preliminary configuration of pkgin: choose “Enable installation of binary packages” in Figure 3.31, “Configuration menu”. pkgin will be fetched and installed from an FTP server, so be sure that the network configuration has already been done. Specify the “Host” name, its “Base directory” (where the packages for all the NetBSD ports are stored), and the “Package directory”, related to your port and your NetBSD version. Usually, the defaults are correct.

Figure 3.36. Enabling installation of binary packages

Choosing “ftp” as “User”, no password will be required. As shown in Figure 3.36, “Enabling installation of binary packages”, you can also choose to install one or more additional packages, typing their names using a space as separator, pressing “Enter” at the end. To proceed to the installation, type “x” and press “Enter”. A “pkgin update” will be run after the installation of pkgin, to let the repository be immediately up to date.

Figure 3.37. Additional packages

After the procedure is completed, sysinst will show the command to install further packages. Hit “Enter” to go back to the configuration menu.

If you need or want to build packages from their source code via pkgsrc, choose “Fetch and unpack pkgsrc for building from source” in Figure 3.31, “Configuration menu”. As before, specify the “Host” name; “pkgsrc directory” is the sources base directory. Defaults are usually the best values. A single archive file will be downloaded, for example pkgsrc.tgz: if you want to automatically remove it after the pkgsrc installation, move the cursor on “Delete after install” and press “Enter”. To proceed with the download, type “x” and then press “Enter”.

Figure 3.38. Fetch and unpack pkgsrc

In the initial configuration menu (Figure 3.31, “Configuration menu”), it is also possible to enable some useful services such as the daemon listening for ssh. For information about ntpd and ntpdate, refer to Section 29.2, “The Network Time Protocol (NTP)”. xdm handles the authentication and the session of users through an X display. Usage of the Cryptographic Device Driver (cgd) is shown in Chapter 14, The cryptographic device driver (CGD). Logical Volume Manager (lvm) is documented in Chapter 17, NetBSD Logical Volume Manager (LVM) configuration, raidframe in Chapter 16, NetBSD RAIDframe. mdnsd provides a Multicast DNS service, and also DNS Service Discovery on NetBSD: check mdnsd(8) for more details.

Finally, the menu in Figure 3.31, “Configuration menu” lets you add a regular user to the system. For all the base information about users and root accounts, as well as the wheel group, refer to Section 5.6, “Adding users”.

When you completed the configuration of all the desired items, choose “Finished configuring” in Figure 3.31, “Configuration menu”.

At this point the installation is finished.

Figure 3.39. Installation completed

After passing the dialog that confirms the installation, sysinst will return to the main menu. Remove any installation media (CD, floppy, etc.) and choose “Reboot the computer” to boot your new NetBSD installation.

Figure 3.40. Reboot to finish installation

The sysupgrade utility (currently found in pkgsrc/sysutils/sysupgrade) allows you to upgrade a running system to a newer binary release.

One of the benefits of sysupgrade is that it is an integrated and almost-unattended solution: the tool fetches the new kernel and distribution sets from remote sites if you desire and performs the upgrade without user intervention until new changes to the configuration files need to be merged.

Let's assume you are running NetBSD/amd64 9.1 and you wish to upgrade to NetBSD 9.2. The procedure to do so would be to run the following command:

# sysupgrade auto https://cdn.NetBSD.org/pub/NetBSD/NetBSD-9.2/amd64
  

And that's all that it takes. This will proceed to download the kernel and sets appropriate for your machine, unpack them and assist you in merging new configuration changes. Do not forget to reboot afterwards.

When upgrading between major releases (e.g. between NetBSD 8.2 and 9.2), take care to first upgrade the kernel and modules:

# sysupgrade fetch https://cdn.NetBSD.org/pub/NetBSD/NetBSD-9.2/amd64
# sysupgrade kernel
# sysupgrade modules
# reboot
# sysupgrade sets
# sysupgrade etcupdate
# sysupgrade postinstall
# sysupgrade clean
# reboot
  

For more details, please see the included sysupgrade(8) manual page and the /usr/pkg/etc/sysupgrade.conf configuration file.

If you have never used a Unix(-like) operating system before, your best friend is now the man command, which displays a manual page. The NetBSD manual pages are among the best and most detailed you can find, although they are very technical.

A good manual to read after booting a new NetBSD system is afterboot(8). It contains information about various necessary and useful configuration settings.

man name shows the man page of the “name” command and man -k name shows a list of man pages dealing with “name” (you can also use the apropos command).

To learn the basics of the man command, type:

# man man

Manual pages contain not only information about commands but also descriptions of some NetBSD features and structures. For example, take a look at the hier(7) man page, which describes in detail the layout of the filesystem used by NetBSD.

# man hier

Other similar pages are release(7) and pkgsrc(7).

# man 8 intro

Manual pages are divided in several sections, depending on what they document:

A subject may appear in more than one section of the manual; to view a specific page, supply the section number as an argument to the man command. For example, time appears in section 1 (the time user command) and in section 3 (the time function of the C library). To see the man page for the time C function, write:

# man 3 time

To see all the available pages:

# man -w time
# man -a time

Other than a shell, a text editor is the most essential tool for NetBSD system administration.

There are two provided in the base system

For the first login you will use the root user, which is the only user defined at the end of the installation. At the password prompt type the password for root that you set during the installation. If you didn't set a password, just press Enter.

NetBSD/i386 (Amnesiac) (ttyE0)
login: root
password:
We recommend creating a non-root account and using su(1) for 
root access.
#

If you did not set a password for root during the installation, you should use the /usr/bin/passwd command to do so now.

# /usr/bin/passwd
Changing local password for root.
New password:
Retype new password:

Passwords are not displayed on the screen while you type.

Choose a password that has numbers, digits, and special characters (not space) as well as from the upper and lower case alphabet. Do not choose any word in any language. It is common for an intruder to use dictionary attacks.

For security reasons, it is bad practice to login as root during regular use and maintenance of the system. Instead, administrators are encouraged to add a regular user, add the user to the wheel group, then use the su(1) command when root privileges are required. NetBSD offers the useradd(8) utility to create user accounts. For example, to create a new user:

# useradd -m joe

The defaults for the useradd command can be changed; see the useradd(8) man page.

User accounts that can su to root are required to be in the "wheel" group. This can be done when the account is created by specifying a secondary group:

# useradd -m -G wheel joe

As an alternative, the usermod(8) command can be used to add a user to an existing group:

# usermod -G wheel joe

In case you just created a user but forgot to set a password, you can still do that later using the passwd(1) command.

# passwd joe

Shadow passwords are enabled by default. What this means is that all the passwords in /etc/passwd are simply “*”; the encrypted passwords are stored in a file that can only be read by root, /etc/master.passwd. When you start vipw(8) to edit the password file, the program opens a copy of /etc/master.passwd; when you exit, vipw checks the validity of the copy, creates a new /etc/passwd and installs the new /etc/master.passwd file. Finally, vipw launches pwd_mkdb(8), which creates the files /etc/pwd.db and /etc/spwd.db, two databases which are equivalent to /etc/passwd and /etc/master.passwd but faster to process.

It is very important to always use vipw and the other tools for account administration (chfn(1), chsh(1), chpass(1), passwd(1)) and to never directly modify /etc/master.passwd or /etc/passwd.

If you do not have a US layout keyboard, you will probably want to change keymaps. For example, to use an italian keyboard, enter the following command:

# wsconsctl -k -w encoding=it
encoding -> it

To save the keyboard layout permanently, add the following line to the /etc/wscons.conf file:

encoding it

See Section 8.1.2.1, “Keyboard mappings” for a list of available keymaps.

NetBSD, like all Unix systems, uses a system clock based on UTC (Coordinated Universal Time) and this is what you should set your system clock to. If you want to keep the system clock set to the local time (because, for example, you have a dual boot system with Windows installed), you must notify NetBSD, adding rtclocaltime=YES to /etc/rc.conf:

# echo rtclocaltime=YES >> /etc/rc.conf
# service rtclocaltime restart

The number of minutes west of GMT is calculated automatically and is set in the kern.rtc_offset sysctl variable.

To display the current setting of the kern.rtc_offset variable:

# sysctl kern.rtc_offset
kern.rtc_offset = -60

This automatic configuration only works if you have set the proper time zone with a symbolic link to /etc/localtime. Normally this is done as part of the install procedure, but if for some reason it wasn't, you can set it by creating a symbolic link from a file in the /usr/share/zoneinfo directory to /etc/localtime.

The following example sets the time zone to Eastern Europe Summer Time:

# ln -fs /usr/share/zoneinfo/Europe/Helsinki /etc/localtime

By default, all services are disabled in a fresh NetBSD installation, and ssh(1) is no exception. You may wish to enable it so you can log in to your system remotely. Set sshd=YES in /etc/rc.conf and then start the server with the command

# service sshd start

The first time the server is started, it will generate a new keypair, which will be stored inside the directory /etc/ssh.

NetBSD uses /etc/rc.conf to determine what will be executed when the system boots. Understanding this file is important. The rc.conf(5) manual page contains a detailed description of all available options.

The /etc/defaults/rc.conf file contains the default values for most settings. To override a default value, the new value must be put into /etc/rc.conf. The definitions there override the ones in /etc/defaults/rc.conf (which you should leave unchanged).

# man rc.conf

The first modifications are:

To resolve the names and IP addresses of remote hosts, the system needs access to a (remote or local) DNS nameserver. Tell the system which nameserver(s) to use by adding the IP address of one or more nameservers to the /etc/resolv.conf file, using the following as an example:

nameserver 145.253.2.75

To set the names of local hosts that are not available through DNS, edit the /etc/hosts file, which has the form:

IP-address  hostname  host

For example:

192.168.1.3 vigor3.your.domain vigor3

New users are often surprised by the fact that although the installation program recognized and mounted their CD-ROM perfectly, the installed system seems to have “forgotten” how to use the CD-ROM. There is no special magic for using a CD-ROM; you can mount it like any other file system. All you need to know is the device name and some options to the mount(8) command. You can find the device name with the aforementioned dmesg(8) command. For example, if dmesg displays:

# dmesg | grep ^cd
cd0 at atapibus0 drive 1: <ASUS CD-S400/A, , V2.1H> type 5 cdrom removable

the device name is cd0, and you can mount the CD-ROM with the following commands:

# mkdir /cdrom
# mount -t cd9660 -o ro /dev/cd0a /cdrom

To make things easier, you can add a line to the /etc/fstab file:

/dev/cd0a /cdrom cd9660 ro,noauto 0 0

Without the need to reboot, you can now mount the CD-ROM with:

# mount /cdrom

When the CD-ROM is mounted you can't eject it manually; you will have to unmount it before you can do that:

# umount /cdrom

There is also a software command which unmounts the CD-ROM and ejects it:

# eject /dev/cd0a

To mount a floppy you must know the name of the floppy device and the file system type of the floppy. Read the fdc(4) manpage for more information about device naming, as this will differ depending on the exact size and kind of your floppy disk. For example, to read and write a floppy in MS-DOS format you use the following command:

# mount -t msdos /dev/fd0a /mnt

Instead of /mnt, you can use another directory of your choice; you could, for example, create a /floppy directory like you did for the CD-ROM. If you do a lot of work with MS-DOS floppies, you will want to install the mtools package, which enables you to access a MS-DOS floppy (or hard disk partition) without the need to mount it. It is very handy for quickly copying a file to or from a floppy:

# mcopy foo bar a:
# mcopy a:baz.txt baz
# mcopy a:\*.jpg .

By the time that you have installed your system, it is quite likely that bugs in the release have been found. All significant and easily fixed problems will be reported at http://www.NetBSD.org/support/security/. It is recommended that you check this page regularly.

Use one of the following two shutdown commands to halt or reboot the system:

# shutdown -h now
# shutdown -r now

Two other commands to perform the same tasks are:

# halt
# reboot

halt, reboot and shutdown are not synonyms: the latter is more sophisticated. On a multiuser system you should really use shutdown, which allows you to schedule a shutdown time and notify users. It will also take care to stop processes properly. For more information, see the shutdown(8), halt(8) and reboot(8) manpages.

It is not like the vi editor needs introducing to seasoned UNIX users. The vi editor, originally developed by Bill Joy of Sun Microsystems, is an endlessly extensible, easy to use light ASCII editor and the bane of the newbie existence. This section will introduce the vi editor to the newbie and perhaps toss in a few ideas for the seasoned user as well.

The first half of this section will overview editing, saving, yanking/putting and navigating a file within a vi session. The second half will be a step by step sample vi session to help get started.

This is intended as a primer for using the vi editor, it is not by any means a thorough guide. It is meant to get the first time user up and using vi with enough skills to make changes to and create files.

$ vi filename

# vi foo.txt

This is some text

there we skipped a line
~
~
~
~

The standard editor supplied with NetBSD is, needless to say, vi, the most loved and hated editor in the world. If you don't use vi, skip this section, otherwise read it before installing other versions of vi. NetBSD's vi (nvi) was written by Keith Bostic of UCB to have a freely redistributable version of this editor and has many powerful extensions worth learning while being still very compatible with the original vi. Nvi has become the standard version of vi for BSD.

Amongst the most interesting extensions are:

set showmode ruler
set filec=^[
set cedit=^[

This topic is not directly related to NetBSD but it can be useful, for example, for examining the kernel sources.

When you examine a set of sources in a tree of directories and subdirectories you can simplify your work using the tag feature of vi. The method is the following:

The system startup files reside in the /etc directory. They are:

First, an overview of the control and support scripts (also documented in rc(8)).

Additional scripts outside of the rc.d directory:

rc.d scripts are controlled by a central configuration file, /etc/rc.conf, which loads its default settings from /etc/defaults/rc.conf. If you want to change a default setting, do not edit /etc/defaults/rc.conf; instead, apply the setting in /etc/rc.conf. This will override the default.

It is a good idea to read the rc.conf(5) man page to learn about the services that are available to you.

The following example shows how to enable the SSH daemon, which is disabled by default:

# cd /etc; grep ssh defaults/rc.conf
sshd=NO                 sshd_flags=""
# echo "sshd=YES" >> rc.conf

Now sshd(8) will be started automatically at system startup. The next section describes how to start and stop services at any time.

Last but not least, files can be created in the /etc/rc.conf.d/ directory to override the behavior of a given rc.d script without editing the script itself.

The actual scripts that control services are in /etc/rc.d. These scripts are automatically run at boot time, but they can be called manually if necessary, either through the service(8) alias or directly. The following example shows how to start the SSH daemon that we enabled in the previous section:

# service sshd start
Starting sshd.

Later, if you wish to stop the SSH daemon, run the following command:

# service sshd stop
Stopping sshd.
Waiting for PIDS: 123.

The rc.d scripts take one of the following arguments:

Some scripts may support other arguments (e.g., “reload”), but every script will support at least the above commands.

As an example, after adding a new record to a named(8) database, the daemon can be told to reload its configuration files with the following command:

# service named reload
Reloading named config files.

Note that all of the commands discussed above will only take action if the particular service is enabled in /etc/rc.conf. It is possible to bypass this requirement by prepending “one” to the command, as in:

# service httpd onestart
Starting httpd.

The above command will allow you to start the httpd(8) service one time. To stop a service that has been started in this manner, pass “onestop” to the script.

The startup system of every Unix system determines, in one way or another, the order in which services are started. On some Unix systems this is done by numbering the files and/or putting them in separate run level directories. Solaris relies on wildcards like /etc/rc[23].d/S* being sorted numerically when expanded. Some simply put all the commands that should be started into a single monolithic script (this is the traditional BSD method, and is what NetBSD did before the rc.d system). On modern NetBSD this is done by the rc.d scripts and their contents. Please note that NetBSD does not use multiple runlevels.

At the beginning of each rc.d script there is a series of commented out lines that have one of the following items in them:

These describe the dependencies of that particular script and allow rcorder to easily work either “up” or “down” as the situation requires. As an example, here is the ordering information contained in /etc/rc.d/nfsd:

...
 PROVIDE: nfsd
 REQUIRE: rpcbind mountd
...

Here we can see that this script provides the “nfsd” service and that it requires “rpcbind” and “mountd” to be running first. The rcorder(8) utility is used at system startup time to read through all the rc.d scripts and determine the order in which they should be run.

Luke Mewburn, one of the principal designers of the rc.d system, gave a presentation on the system at USENIX 2001. It is available in PDF format.

Wscons is NetBSD's platform-independent workstation console driver. It handles complete abstraction of keyboards and mice. This means that you can plug in several keyboards or mice and they will be multiplexed onto a single terminal, but also that it can multiplex several virtual terminals onto one physical terminal.

Wscons support is enabled by default on most architectures. This can be done manually by adding wscons=YES to your /etc/rc.conf. Then configure the desired number of virtual consoles as described in Section 8.1.1.1, “Virtual consoles” and start wscons by entering service wscons start followed by service ttys restart. You can now switch virtual consoles by pressing Ctrl+Alt+Fn or similar, depending on the platform.

Wscons comprises three subsystems: wsdisplay, wskbd and wsmouse. These subsystems handle abstraction for all display, keyboard and mouse devices respectively. The following sections discuss the configuration of wscons per subsystem.

options     WSDISPLAY_DEFAULTSCREENS=4

# screens to create
#       idx     screen  emul
#screen 0       -       vt100
screen  1       -       vt100
screen  2       -       vt100
screen  3       -       vt100
screen  4       -       -
#screen 4       80x25bf vt100
#screen 5       80x50   vt100

screen 3       -       vt100

wsconscfg -e vt100 3

wsconscfg: WSDISPLAYIO_ADDSCREEN: Device busy

console "/usr/libexec/getty Pc"         pc3     off secure
ttyE0   "/usr/libexec/getty Pc"         vt220   on secure
ttyE1   "/usr/libexec/getty Pc"         vt220   on secure
ttyE2   "/usr/libexec/getty Pc"         vt220   on secure
ttyE3   "/usr/libexec/getty Pc"         vt220   off secure
...

ttyE3   "/usr/libexec/getty Pc"         vt220   off secure

:0 local /usr/X11R7/bin/X +kb dpms -bpp 16 dpms vt8

font ibm  -  8  ibm  /usr/share/pcvt/fonts/vt220l.808

#screen 0       80x50   vt100
screen  1       80x50   vt100
screen  2       80x50   vt100
screen  3       80x50   vt100
screen  4       80x50   vt100
screen  5       80x50   vt100
screen  6       80x50   vt100
screen  7       80x50   vt100

ttyE0   "/usr/libexec/getty Pc"         vt220   on 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
ttyE4   "/usr/libexec/getty Pc"         vt220   on secure
ttyE5   "/usr/libexec/getty Pc"         vt220   on secure
ttyE6   "/usr/libexec/getty Pc"         vt220   on secure
ttyE7   "/usr/libexec/getty Pc"         vt220   on secure

options VGA_CONSOLE_SCREENTYPE="\"80x50\""
options VGA_CONSOLE_ATI_BROKEN_FONTSEL
options FONT_VT220L8x8

options WS_KERNEL_FG=WSCOL_xxx
options WS_KERNEL_BG=WSCOL_xxx

wsconsctl -d -w border=blue msg.default.bg=blue msg.default.fg=white msg.default.attrs=hilit

wsconsctl -d -w msg.kernel.fg=red

setenv TERM wsvt25

export TERM=wsvt25

# wsconsctl -k -w encoding=it
encoding -> it

# cp /etc/wscons.conf /etc/wscons.conf.orig
# echo encoding it >>/etc/wscons.conf

wsconsctl -w "map += keycode 51=comma question semicolon colon"

wsconsctl -w repeat.del1=300
wsconsctl -w repeat.deln=40

setvar repeat.del1=300
setvar repeat.deln=40

# echo wsmoused=yes >>/etc/rc.conf
# service wsmoused start 

NetBSD uses the X Window System to provide a graphical interface.

Please note that the X Window System is a rather bare bones framework. It acts as a base for modern desktop environments like MATE, or Xfce, but they are not part of the X Window System. NetBSD ships with the X Window System, but it does not include these desktop environments; they must be added via pkgsrc.

When you start using X you'll find many new terms which you may find confusing at first. The basic elements are:

The X Window System is included with NetBSD as separate distribution sets, see Section 3.10, “Installation type”. It can be added to an installed system with sysinst(8).

On NetBSD, X11 lives under the filesystem hierarchy /usr/X11R7. Therefore, to use X, /usr/X11R7/bin must be in your shell's PATH. See ~/.profile.

In most cases, you will be able to start using X without any configuration at all, and startx will work just fine.

In rare cases, however, configuration of the X server is required. This configuration file is located at /etc/X11/xorg.conf. The structure of the configuration file is described formally in xorg.conf(5).

To generate an initial configuration file for your X server, run the command

# X -configure

This command should create a configuration file and place it in your home directory. To test the generated configuration file, run, e.g.,

# X -config ~/xorg.conf.new

If this succeeds, you should see a crosshatched background and a cursor in the shape of an X. Try moving the cursor around to verify that the mouse is functional. You can then switch to another virtual terminal (Ctrl-Alt-F#) or log in remotely and kill the X process.

If the above test was successful, move the file into place as /etc/X11/xorg.conf and you are ready to go.

Even if you have already configured your keyboard for wscons (see Section 8.1, “wscons”), you need to configure it for X as well, at least if you want to use a non-US layout.

An easy solution is to use setxkbmap(1) .

Here is an example that shows how to use a Hebrew keyboard, with Ctrl-Alt used to switch layouts, and with the position of the Escape and Caps Lock keys swapped as an additional option:

setxkbmap -option grp:alt_shift_toggle us,il \
 -option caps:swapescape -option terminate:ctrl_alt_bksp

If you wish to change the repeat rate of your keyboard, you can set it with the xset(1) command, which takes two arguments: delay and rate, respectively. The following example sets the initial delay to 200 milliseconds and the repeat rate to 30 per second:

$ xset r 200 30

You can also run this command in your .xinitrc or .xsession file. See below (Section 9.6, “Customizing X”) for more information.

If X does not run at the resolution you think it should, first run xrandr and see if the resolution you want is listed. If your preferred resolution is listed in that command's output, you can change resolutions with, e.g.,

$ xrandr -s 1680x1050

xrandr can also be used to enable output to hot-plugged monitors.

Managing outputs can be done graphically with the pkgsrc package x11/arandr.

You can start X with the following command:

$ startx

If your basic X server configuration is correct, you are left in the X environment with the default window manager (ctwm). If you want a more advanced window manager or desktop environment, many are available in pkgsrc. See Section 9.7, “Other window managers or desktop environments” for information about adding and changing window managers.

One of the first things you will want to do is to change the programs that run when X is first started. The easiest way to do this is to copy the default .xinitrc file to your home directory and modify it, or create a simple new one from scratch. For example:

$ cp /etc/X11/xinit/xinitrc ~/.xinitrc
$ chmod u+w ~/.xinitrc
$ vi ~/.xinitrc

If you use xdm(1), ~/.xsession is used in place of ~/.xinitrc.

The following example shows how to start the window manager (ctwm) and open an instance of the xterm and xterm programs. The screen background color is set to “bisque4”, which is defined in /usr/X11R7/lib/X11/rgb.txt.

...
# start some programs - a basic clcok
xclock -geometry 50x50-1-1 &
# change the color of the "root window" ("desktop background")
xsetroot -solid bisque4 &
# spawn a terminal
uxterm -geometry 80x34-1+1 -bg OldLace &
exec ctwm -W   # no '&' here

With this type of setup, to quit X you must exit the window manager, which is usually done by selecting "exit" from its menu.

The above example is very simple, but illustrates the basics of controlling the clients that are run when X is started. You can run any number of commands from your .xinitrc, including basic X configuration commands like xset b off to turn off the bell.

If you don't like ctwm, which is a very simple window manager, you can install another window manager or a desktop environment from pkgsrc. The following example uses the Openbox window manager, but there are many others available in pkgsrc/wm.

Openbox can be installed via binary packages or compiled with pkgsrc. As always, assuming a properly set PKG_PATH, the binary package method is:

# pkgin in openbox

To build it with pkgsrc, run:

# cd /usr/pkgsrc/wm/openbox
# make install

Openbox is now installed; to start it you must modify your .xinitrc file: substitute the line which calls ctwm with a line which calls openbox. For example:

# start some useful programs
xclock -geometry 50x50-1-1 &
# start window manager:
exec openbox   # no '&' here

The startx command will start the X11 session with Openbox. As configured in the example .xinitrc file above, choosing “Log Out” from Openbox's menu will end the X11 session.

Installing a desktop environment is almost as easy. The following example shows how to use the Xfce desktop environment.

# pkgin in xfce4

Depending on your requirements, you may wish to enable dbus as a system-wide service. The following example demonstates how. (If you don't enable dbus to run as a system-wide service, startxfce4 will start dbus under your user account during initialization.)

# cp /usr/pkg/share/examples/rc.d/dbus /etc/rc.d
# echo dbus=YES >> /etc/rc.conf
# service dbus start

If you wish to be able to control your system's power state from within the desktop, the account you intend to run X under must also be a member of the “operator” group (see Section 5.6, “Adding users”).

After running the above commands, edit your .xinitrc as above and change “openbox” (or “ctwm”) to “startxfce4”. The next time you run startx the Xfce desktop environment will be started.

If you always use X and the first thing you do after you log in is run startx, you can set up a graphical login to do this automatically. It is very easy:

The configuration files for xdm are in the /etc/X11/xdm directory. The Xservers file specifies the virtual console that X is started on. It defaults to “vt05”, which is the console you reach via “Ctrl+Alt+F5”. If you want to use a different virtual console, change vt05 as desired. In order to avoid keyboard contention between getty and xdm, be sure to start xdm on a virtual terminal where getty is disabled. For example, if in Xservers you have:

:0 local /usr/X11R7/bin/X :0 vt04

then in /etc/ttys you should have

ttyE3   "/usr/libexec/getty Pc"         wsvt25   off secure

(Please note that vt04 corresponds to ttyE3; in /etc/X11/xdm/Xservers, numbering starts at 1, but in /etc/ttys, numbering starts at 0.)

If you are using xdm to start various modern desktop environments, such as Xfce or MATE, you will need to override its default permitted authorization mechanisms, by adding the following to /etc/X11/xdm/xdm-config:

DisplayManager*authName:    MIT-MAGIC-COOKIE-1

If you want to change the look of your xdm login screen, you can modify the xdm configuration file. For example, to change the background color you can add the following line to the Xsetup_0 file:

xsetroot -solid SeaGreen

This is intended as a simple example of how to use multiple X servers. For illustration purposes, we'll simply use Xnest(1), which creates a new X server :1 as a window on the existing server :0:

$ Xnest :1 &

It's then possible to run programs on the second server, or even a different window manager:

$ DISPLAY=:1 uxterm &
$ DISPLAY=:1 ctwm &

Using X11 forwarding, programs can run on a remote machine while displaying on the local machine. This must typically be enabled in /etc/ssh/sshd_config:

X11Forwarding yes

Log in with ssh(1) and run X programs the normal way:

$ ssh -X remote.machine.example.com
$ uxterm &

On a completely headless system (with no monitor), Xvfb(1) (X virtual framebuffer) can be used in a similar manner. The fully virtual screen of the X server can be exported over the network with x11/x11vnc:

$ Xvfb :1 &
$ DISPLAY=:1 ctwm &
$ x11vnc -display :1 -localhost -passwdfile /path/to/password &

Notice we use the -localhost option. In theory this stops remote connections, however, in practice we're using a SSH tunnel to forward the VNC port, adding an extra layer of security. To connect to the headless machine:

$ ssh -L 5900:hostname:5900 hostname
$ vncviewer localhost &

audiocfg(1) can be used to list, test and set default audio devices.

All available audio devices can be listed with audiocfg list:

$ audiocfg list
0: [*] audio0 @ hdafg0: Realtek ALC292
       playback: 2ch, 48000Hz
       record:   2ch, 48000Hz
       (PR) slinear_le 16/16, 2ch, { 32000, 44100, 48000, 88200, 96000, 192000 }
       (PR) slinear_le 20/32, 2ch, { 32000, 44100, 48000, 88200, 96000, 192000 }
       (PR) slinear_le 24/32, 2ch, { 32000, 44100, 48000, 88200, 96000, 192000 }
       (  ) ac3 16/16, 2ch, { 32000, 44100, 48000, 88200, 96000, 192000 }
1: [ ] audio1 @ uaudio0: USB audio
       playback: 2ch, 48000Hz
       record:   1ch, 48000Hz
       (P-) slinear_le 16/16, 2ch, { 48000, 44100 }
       (-R) slinear_le 16/16, 1ch, { 48000, 44100 }

The asterisk next to the Realtek ALC292 device indicates it is currently the default device, so if any application writes or reads to /dev/audio it will play or record from it. It is also available as /dev/audio0, and for mixer commands, /dev/mixer0.

The other device, USB audio, is a secondary device that has been plugged in. Since it isn't the default, it is only used if specifically selected in an application. It is available as /dev/audio1, and for mixer commands, /dev/mixer1.

The playback: and record: rows indicate the currently selected hardware audio format. Below this, the other supported formats are listed. Some devices set the playback and recording formats separately, while others set both at the same time. This is indicated by PR.

audiocfg test index can be used to test playback, and plays a tone of 2 seconds for each channel of the index device:

$ audiocfg test 0
0: [*] audio0 @ hdafg0: Realtek ALC292
  testing channel 0... done
  testing channel 1... done

If more than one audio device is available, audiocfg default index can be used to change the default one. This persists between reboots. Please note that unlike other audiocfg(1) commands, audiocfg default needs to be run as root.

In NetBSD, mixerctl(1) is used to adjust audio mixing, e.g. volume for recording and playback, and the sources and sinks currently in use.

Set the current playback volume:

$ mixerctl -w outputs.master=50

List the available controls and settings:

$ mixerctl -av
outputs.master=255,255 volume
inputs.dac=255,255 volume
outputs.auto=255,255 volume delta=13
outputs.headphones=0,0 volume delta=13
outputs.hdmi=255,255 volume delta=13
outputs.select=headphones  [ auto headphones hdmi ]

Secondary devices can also be configured using mixerctl(1). For example, if you've just plugged in an USB audio device, it may have attached as /dev/audio1 and /dev/mixer1 - this is visible using audiocfg(1). You would therefore configure it with mixerctl -d /dev/mixer1.

outputs.master=120,120
outputs.select=headphones

mixerctl=YES
mixerctl_mixers="mixer0 mixer1"

NetBSD's pad(4) device allows feeding back data from an application using a virtual audio device. It can be used to redirect playback elsewhere, or record an application's playback.

/dev/padN devices produce a raw stream of audio in a fixed format when opened for reading. At the time of opening, they also create a /dev/audioN device for an application to use for output. You can observe the device creation happening with dmesg(8).

The following example records the output of a game, games/jumpnbump, using the program multimedia/ffmpeg4 for encoding the data from the pad device to a file and writing it back to the real audio device simultaneously. Both are available from the NetBSD Packages Collection.

$ ffmpeg4 -f s16le -ar 44100 -ac 2 -i /dev/pad0 \
    -f wav output.wav -f oss /dev/audio
$ SDL_PATH_DSP=/dev/audio1 jumpnbump

NetBSD comes with a number of commands that allow users to play and record audio from scripts or the command-line interface.

$ audiorecord -d /dev/audio -F wav -e linear -c 2 -P 16 -s 44100 recording.wav

$ audioplay recording.wav

NetBSD includes built-in MIDI support through the machine-independent midi(4) system. This includes support for USB MIDI devices.

Access to MIDI devices is supported through raw access to the /dev/rmidiX devices, or through the sequencer device, /dev/music.

Digital Audio Workstations and other software with support for NetBSD MIDI in the Packages Collection include audio/lmms and audio/fluidsynth. Several MIDI programs are also included with NetBSD:

Since the 2010s, most x86 machines have hardware compliant with the Intel HD Audio specification. These use NetBSD's hdaudio(4) driver and require some special consideration.

hdafg0 at hdaudio1: Realtek ALC292
hdafg0: DAC00 2ch: Speaker [Built-In], HP Out [Jack]
hdafg0: ADC01 2ch: Mic In [Jack]
hdafg0: ADC02 2ch: Mic In [Built-In]

$ mixerctl -w record.source=ADC02

$ mixerctl -w record.source=ADC01,ADC02

The primary command-line frontend to NetBSD's sensor monitoring framework is envstat(8). Here is a typical example of envstat output:

$ envstat
                      Current  CritMax  WarnMax  WarnMin  CritMin  Unit
[acpiacad0]
         connected:     FALSE
[acpibat0]
           present:      TRUE
    design voltage:    11.100                                         V
           voltage:    12.270                                         V
        design cap:    23.200                                        Wh
     last full cap:    16.940                                        Wh
            charge:    16.770                      5.000%   1.181%   Wh (99.00%)
       charge rate:       N/A
    discharge rate:       N/A
          charging:     FALSE
      charge state:    NORMAL
[acpitz0]
       temperature:    48.000  128.000
    

acpiacad0 is the machine's AC adapter. It is not currently connected.

acpibat0 is the machine's battery, currently 99% full. At 5%, a warning will be printed to the console and an event sent to powerd(8). At 1%, the system will shut down to prevent data loss from loss of power.

A CPU temperature sensor is also detected, acpitz0. It indicates that the CPU's current temperature is 48 degrees Celsius, and the critical temperature is 128 degrees Celsius. If the critical temperature is reached, the system will shut down to prevent damage to hardware. powerd(8) can be notified of changes in temperature.

powerd(8) is a daemon that allows the system to respond to power management events, such as the AC adapter being unplugged, battery state changing, a laptop's lid being closed, or a "sleep" button being pressed.

As with other services, powerd can be enabled by editing /etc/rc.conf:

      powerd=YES
    

And started with service(8):

# service powerd start

powerd works by executing a named sh(1) script from the directory /etc/powerd/scripts whenever a power event occurs. We can use commands we learned in previous sections of this chapter to our advantage in the scripts.

#!/bin/sh -
#
# Generic script for lid switch events.
#
# Arguments passed by powerd(8):
#
#	device event

case "${2}" in
pressed)
	# Lock the X11 display to prevent tampering
	DISPLAY=:0 /usr/pkg/bin/xlock -mode blank &
	# Wait for 1 second
	sleep 1
	# Suspend
	/sbin/sysctl -w hw.acpi.sleep.state=3
	exit 0
	;;

released)
	exit 0
	;;

*)
	logger -p warning "${0}: unsupported event ${2} on device ${1}" >&1
	exit 1
esac

#!/bin/sh -
#
# Generic script for acadapter events.
#
# Arguments passed by powerd(8):
#
#	device event

case "${2}" in
pressed)
	logger -p info "${0}: Full performance mode" >&1

	# Disable power saving mode on all network interfaces.
	for intf in $(/sbin/ifconfig -l); do
		/sbin/ifconfig $intf -powersave >/dev/null 2>&1
	done

	# Increase CPU frequency
	/sbin/sysctl -w machdep.cpu.frequency.target=2300

	exit 0
	;;

released)
	logger -p info "${0}: Power saving mode" >&1

	# Enable power saving mode on all network interfaces.
	for intf in $(/sbin/ifconfig -l); do
		/sbin/ifconfig $intf powersave >/dev/null 2>&1
	done

	# Reduce CPU frequency
	/sbin/sysctl -w machdep.cpu.frequency.target=1400

	exit 0
	;;

*)
	logger -p warning "${0}: unsupported event ${2} on device ${1}" >&1
	exit 1
	;;
esac

After installation it is not yet possible to print, because the lpd printer spooler daemon is not enabled. To enable lpd, one line in the /etc/rc.conf file must be changed from:

lpd=NO

to

lpd=YES

The change will come into effect at the next boot, but the daemon can be started manually now:

# service lpd start

To check if lpd is active, type the following command:

# service lpd status

If you don't see an entry for lpd in the output of the previous command, the daemon is not active.

The lpd system is configured via /etc/printcap. Before configuring /etc/printcap it is a good idea to make a printer test, to check if the physical connection between your computer and the printer is working. The test sends out some data directly to the printer device. Assuming you use a printer connected to the parallel port, this is /dev/lpt0; if you use an USB printer try /dev/ulpt0. Please check the manpages of these devices (lpt(4), ulpt(4)) for more information!

In our example we have a printer attached to the parallel port, so we run this:

# lptest 70 5 > /dev/lpt0

To see what the output should look like, try the same command without redirecting the output to the printer:

# lptest 70 5
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdef
"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefg
#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefgh
$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghi
%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghij 

A frequent problem is that the output on the printer is not correctly aligned in columns but has a “staircase” configuration. This usually means that the printer is configured to begin a new line at the left margin after receiving both a <CR> (carriage return, ASCII 13) character and a <LF> (line feed, ASCII 10) character. NetBSD only sends a <LF> character. You can fix this problem in two ways:

This section explains how to configure the example printer to print text documents.

The printer must have an entry in the /etc/printcap file; the entry contains the printer id (the name of the printer) and the printer description. The lp id is the default used by many programs. Here is an example entry:

lp|local printer|HP DeskJet 690C:\
        :lp=/dev/lpa0:sd=/var/spool/lpd/lp:lf=/var/log/lpd-errs:\
        :sh:pl#66:pw#80:if=/usr/local/libexec/lpfilter:

The file format and options are described in detail in the printcap(5) manpage. Please note that an input filter has been specified (with the if option) which will take care of eliminating the staircase problem:

if=/usr/local/libexec/lpfilter

The printcap entry for the printer also specifies a spool directory, which must be created; this directory will be used by the lpd daemon to accumulate the data to be printed:

# cd /var/spool/lpd
# mkdir lp
# chown daemon:daemon lp
# chmod 770 lp

The only missing part is the lpfilter input filter, which must be written. The only task performed by this filter is to configure the printer for the elimination of the staircase problem before sending the text to be printed. The printer used in this example requires the following initialization string: “<ESC>&k2G”.

#!/bin/sh
# Treat LF as CR+LF
printf "\033&k2G" && cat && exit 0
exit 2

After saving this script into the name you used in /etc/printcap, you need to make sure it's executable:

# chmod 755 /usr/local/libexec/lpfilter*

if=/usr/libexec/lpr/lpf:

After everything is in place now, the lptest command can be run again now, this time using the lpr command, which will first send the data to the lpd spooler, then runs the filter and sends the data off to the printer:

# lptest 70 5 | lpr -h

The lpr program prints text using the spooler to send data to the printer; the -h option turns off the printing of a banner page (not really necessary, because of the sh option in /etc/printcap). Users more familiar with the System V printing system can also use the lp(1) command that comes as an alternative to lpr(1).

Now that basic printing works, the functionality for printing PostScript files can be added. The simple printer used in this example does not support native printing of PostScript files; a program must be used which is capable of converting a PostScript document in a sequence of commands that the printer understands. The Ghostscript program, which can be found in packages collection, can be used to this purpose. This section explains how to configure lpd to use Ghostscript to print PostScript files on the HP Deskjet 690C.

A second id for the printer will be created in /etc/printcap: this new id will use a different input filter, which will call Ghostscript to perform the actual print of the PostScript document. Therefore, text documents will be printed on the lp printer and PostScript documents on the ps printer: both entries use the same physical printer but have different printing filters.

The same result can be achieved using different configurations. For example, a single entry with only one filter could be used. For this, the filter should be able to automatically determine the format of the document being printed, and use the appropriate printing program. This approach is simpler but leads to a more complex filter; if you like it you should consider installing the magicfilter program from the packages collection: it does this and many other things automatically.

For our approach, the new /etc/printcap file looks like this:

lp|local printer|HP DeskJet 690C:\
        :lp=/dev/lpa0:sd=/var/spool/lpd/lp:lf=/var/log/lpd-errs:\
        :sh:pl#66:pw#80:if=/usr/local/libexec/lpfilter:

ps|Ghostscript driver:\
        :lp=/dev/lpa0:sd=/var/spool/lpd/ps:lf=/var/log/lpd-errs:\
        :mx#0:sh:if=/usr/local/libexec/lpfilter-ps:

Option mx#0 is very important for printing PostScript files because it eliminates size restrictions on the input file; PostScript documents tend to be very big. The if option points to the new filter. There is also a new spool directory.

The next steps are the creation of the new spool directory and of the filter program. The procedure for the spool directory is the same as above:

# cd /var/spool/lpd
# mkdir ps
# chown daemon:daemon ps
# chmod 770 ps