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.

A detailed list of NetBSD features can be found at: http://www.NetBSD.org/about/features.html.

The basic features of NetBSD are:

These characteristics bring also 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 PC platform (i386 and amd64), SPARC and UltraSPARC, 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 8,000) that can be installed both from source and in pre-compiled form. All the packages that you expect to find on a well configured system are available for NetBSD for free. The framework that makes this possible, pkgsrc, also includes a number of commercial applications. In addition, NetBSD provides binary emulation for various other *nix operating systems, allowing you to run non-native applications. Linux emulation is probably the most relevant example. You can run the Linux versions of

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

There is no “official” supplier of NetBSD CD-ROMs but there are various resellers. You can find the most up to date list on the relevant page on the NetBSD site.

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

The installation process is divided logically in 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 media (CD/DVD, USB drive, floppy, etc.) and reboot the computer. The kernel on the installation medium will be booted and 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 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 given in Figure 3.5, “Choosing a hard disk”, there are two disks, and NetBSD will be installed on “wd0”, the first IDE disk found. If you use SCSI or external USB disks, the first will be named “sd0”, the second “sd1” and so on.

Figure 3.5. Choosing a hard disk

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.6, “Full or custom installation”.

Figure 3.6. 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.7, “Selecting distribution sets”. At a minimum, you must select a kernel and the “Base” and “System (/etc)” sets.

Figure 3.7. Selecting distribution sets

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.8, “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.8. 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.9. fdisk

Deleting a partition is simple: after selecting the partition, a menu with options for that partition will appear (Figure 3.10, “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.10, “Partition options”.

Figure 3.10. 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 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”. It is a good idea to 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. 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 that you 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.11, “Installing the boot selector”.

Figure 3.11. 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. 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.12, “Edit partitions?”.

Figure 3.12. 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.13, “Setting partition sizes”.

Figure 3.13. Setting partition sizes

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.13, “Setting partition sizes” shows how to change the size of the swap partition to 600 MB. Changing /tmp to reside on a RAM disk (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.

The next step is to create the disklabel and edit its partitions, if necessary, using the disklabel editor (Figure 3.14, “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.14. The disklabel editor

There are two reserved partitions, “c”, representing the NetBSD partition, and “d”, representing the whole disk. You can edit all other partitions by using the cursor keys and pressing the return key. 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.15, “Disklabel partition editing”.

Figure 3.15. 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.16, “Naming the NetBSD disk”. This can be used later to distinguish between disklabels of otherwise identical disks.

Figure 3.16. 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.17. 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.18, “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.18. Selecting bootblocks

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

The second half of the installation process consists of populating the file systems by extracting the distribution sets that you selected earlier (base, compiler tools, games, etc). Before unpacking the sets, sysinst asks what information you would like to see during that process, as shown in Figure 3.19, “Choosing the verbosity of the extraction process”. You can choose between a progress bar, a display of the name of each extracted file, or nothing.

Figure 3.19. Choosing the verbosity of the extraction process

Now sysinst needs to find the NetBSD sets and you must tell it where to find them. 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.10.1. Installing from CD-ROM or DVD

When selecting “CD-ROM / DVD”, sysinst asks the name of the CD-ROM or DVD device and the directory in which the set files are stored, see Figure 3.21, “CD-ROM/DVD installation”. The device is usually cd0 for the first CD-ROM or DVD drive, regardless of whether it is IDE or SCSI (or even USB or FireWire).

Figure 3.21. CD-ROM/DVD installation

The CD-ROM/DVD device name

If you don't know the name of the CD-ROM/DVD device, you can find by doing the following:

1. Press Ctrl-Z to pause sysinst and go to the shell prompt.

2. Type the command:

   # dmesg

   This will show the kernel startup messages, including the name of the CD-ROM device, for example cd0.

3. If the display scrolls too quickly, you can also use more:

   # dmesg | more

4. Go back to the installation program with the command:

   # fg

3.10.2. Installing from an unmounted file system

Figure 3.22, “Mounting a file system” shows the menu to install NetBSD from an unmounted file system. It is necessary to specify the device ("Device"), the file system of the device ("File system") and the path to the install sets ("Set directory"). The setting for the "Base directory" is optional and can be kept blank.

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

Figure 3.22. Mounting a file system

It is usually necessary to specify the device name and the partition. Figure 3.23, “Mounting a partition ” shows how to specify device "sd0" with partition "e".

Figure 3.23. Mounting a partition

In Figure 3.24, “Accessing a MSDOS file system” the file system type is specified. It is “msdos” but it could also be the NetBSD file system “ffs” or “ext2fs”, a Linux file system. The “Base directory” item is left blank and the binary sets are stored under “/sets”. Choosing “Continue” will start the extraction of the sets.

Figure 3.24. Accessing a MSDOS file system

3.10.3. Installing via FTP

If you choose to install from a local network or the Internet via FTP, sysinst will configure the system's network connection, download the selected set files to a temporary directory, and then extract them.

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

The first step shown in Figure 3.25, “Which network interface to configure” consists of selecting which network card to configure. sysinst will determine a list of available network interfaces, present them and ask which one to use.

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.

To get a list of network interfaces available on your system, interrupt the installation process by pressing “Ctrl+Z”, then enter

# ifconfig -a
ne2: flags=8822<UP,BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500
        address: 00:06:0d:c6:73:d5
        media: Ethernet autoselect 10baseT full-duplex
        status: active
        inet 0.0.0.0 netmask 0xffffff00 broadcast 0.0.0.0
        inet6 fe80::206:dff:fec6:73d5%ne2 prefixlen 64 scopeid 0x1
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33196
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
ppp1: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296
sl1: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296
strip0: flags=0 mtu 1100
strip1: flags=0 mtu 1100 

To get more information about all the devices found during system startup, including network devices, type

# dmesg | more

You can return to the NetBSD installation by typing

# fg

Figure 3.25. Which network interface to configure

Next, you have a chance to set your network medium.

Note

It is unlikely that you will need to enter 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 (ne2, for example), escape from sysinst by pressing “Ctrl+Z”, then enter:

# ifconfig -m ne2
ne2: flags=8822<UP,BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500
        address: 00:03:0d:c6:73:d5
        media: Ethernet 10baseT full-duplex
        status: active
        supported Ethernet media:
                media 10baseT
                media 10baseT mediaopt full-duplex
                media 10base2
                media autoselect

The various 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:

# fg

The next question will be whether you want to perform DHCP autoconfiguration as shown in Figure 3.26, “Using DHCP for network configuration”. Answer “Yes” if you have a DHCP Dynamic Host Configuration Protocol (DHCP) running somewhere on your network, and sysinst will fetch a number of defaults from it. Answer “No” to enter all the values manually.

We will assume you answered “No” and go into all the questions asked in detail.

Figure 3.26. Using DHCP for network configuration

Figure 3.27, “Entering and configuring network data” shows the questions asked for the network configuration. The values to be entered are:

Your DNS Domain:

This is the name of the domain you are in.

Your hostname:

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

Your IPv4 number:

Enter your numerical Internet Protocol address in “dotted quad” notation here, for example, 192.168.1.3

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!

IPv4 name server:

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

Figure 3.27. Entering and configuring network data

After answering all of your network configuration info, it will be displayed, and you will have a chance to go back and make changes (Figure 3.28, “Confirming network parameters”).

Figure 3.28. Confirming network parameters

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, you must tell the installer how to get the distribution sets, as shown in Figure 3.29, “Defining the FTP settings”.

When you are satisfied with your settings (the defaults work most of the time), choose “Get Distribution” to continue.

Figure 3.29. Defining the FTP settings

3.10.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.30, “NFS install screen”, you must specify the IP address of the NFS server with "Host", the "Base directory" that is exported by the NFS server, and the "Set directory", which contains the install sets.

Figure 3.30. NFS install screen

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

Figure 3.31. NFS example

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

After extracting all selected sets, sysinst will create device nodes in the /dev directory and then display a message saying that everything went well.

Another message (see Figure 3.32, “Extraction of sets completed”) will let you know that the set extraction is now completed, and that you will have an opportunity to configure some essential things before finishing the NetBSD installation.

Figure 3.32. Extraction of sets completed

The first thing you can configure is your timezone. It is Universal Time Coordinated (UTC) by default, and you can use the two-level menu of continents/countries and cities shown in Figure 3.33, “Selecting the system's time zone” to select your timezone with the Return key. Next, press “x” followed by Return to exit timezone selection.

Figure 3.33. Selecting the system's time zone

At this point, you are given the option to choose a password encryption scheme. While “DES” is the standard algorithm used on most Unix systems, “MD5”, “Blowfish”, and “SHA1” allow longer passwords than DES, which only uses the first eight characters of the password that is entered. DES is still useful for interoperability with other operating systems.

Figure 3.34. Selecting a password encryption scheme

After choosing the password cipher you are asked if you want to set the root password. It is recommended to set a root password at this point for security reasons.

Figure 3.35. 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.36. Setting root password

The next menu allows you to choose which command line interpreter - also known as a “shell” - will be used for the root account. The default is the classic Bourne 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 of 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.37. Choosing a shell

At this point the installation is finished.

Figure 3.38. 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.39. Reboot to finish installation

This chapter describes the binary upgrade of a NetBSD system. To do the upgrade, you must have some form of bootable media (CD-ROM, USB drive, floppy, etc.) available and at least the base and kern distribution sets. Since files already installed on the system are overwritten in place, you only need additional free space for files which weren't previously installed or to account for growth of the sets between releases. Usually this is not more than a few megabytes.

The upgrade procedure is similar to an installation, but without the hard disk partitioning. sysinst will attempt to merge the settings stored in your /etc directory with the new version of NetBSD. Also, file systems are checked before unpacking the sets. Fetching the binary sets is done in the same manner as in the installation procedure.

Before doing an upgrade it is essential to read the release information and upgrading notes in one of the INSTALL files: this is the official description of the upgrade procedure, with platform specific information and important details. It can be found in the root directory of the NetBSD release (on the install CD or on the FTP server)

It is advisable to print the INSTALL document out. It is available in four formats: .txt, .ps, .more, and .html

The following section provides an overview of the binary upgrade process. Most of the following sysinst dialogs are similar to those of the installation process. More verbose descriptions and explanations of the dialogs are available in Chapter 3, Example installation.

After selecting the installation language and the keyboard type, the main menu appears. Choosing option “b: Upgrade NetBSD on a hard disk” will start the the upgrade process.

Figure 4.1. Starting the upgrade

The dialog in Figure 4.2, “Continuing the upgrade” will request permission to continue with the upgrade. At this point nothing has been changed yet and the upgrade can still be cancelled. This is a good time to ask yourself whether you have made a backup, and if you know for certain that you will be able to restore from it.

Figure 4.2. Continuing the upgrade

After choosing to continue with “Yes”, the next dialog will ask you to specify the hard disk with the NetBSD system that shall be upgraded. If more than one disk is available a list of the disks will be displayed.

Figure 4.3. Choosing the hard drive

The system used for the example has only one hard disk available: “wd0”.

The following dialog provides a menu to choose the installation type. The choices are “Full installation”, “Minimal installation”, or “Custom installation”.

Figure 4.4. Choosing the distribution filesets

At this point, sysinst will perform a check of the file system to ensure its integrity.

Figure 4.5. File system check

The next step is to choose which type of bootblocks to install.

Figure 4.6. Choosing bootblocks

The next dialog will ask how much information should be displayed during the extraction of the distribution sets.

Figure 4.7. Upgrade process - verbosity level

The following dialog asks for the install method of choice and provides a list of possible options. The install medium contains the new NetBSD distribution sets. You will be prompted for different information depending on which option you choose. For example, a CD-ROM or DVD install requires you to specify which device to use and which directory the sets are in, while an FTP install requires you to configure your network and specify the hostname of an FTP server. More details can be found in Section 3.10, “Choosing the installation media”.

Figure 4.8. Install medium

sysinst will now unpack the distribution sets, replacing your old binaries. After unpacking these sets, it runs the postinstall script to clean up various things. If no problems occur, you are done. If postinstall produces errors, you will have to manually resolve the issues it brings up. See postinstall's man page for more information. You should also read the remarks in INSTALL about upgrading, as specific compatibility issues are documented there.

Figure 4.9. Upgrade complete

When you are back at the main menu, remove the boot medium (if applicable) and reboot. Have fun with your new version of NetBSD!

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 Greenwich time (GMT) 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
# sh /etc/rc.d/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

# /etc/rc.d/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, a look at controlling and supporting 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, override the setting in /etc/rc.conf.

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. The following example shows how to start the SSH daemon that we enabled in the previous section:

# /etc/rc.d/sshd start
Starting sshd.

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

# /etc/rc.d/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:

# /etc/rc.d/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:

# /etc/rc.d/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 have multiple runlevels as found in SysV-style systems like Solaris and Linux.

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.

The capabilities of wscons can vary depending on the port. Starting with NetBSD 4.0, almost all ports have full support for most capabilities wscons has to offer. If you are using a non-mainstream architecture, please see the port-specific FAQ if wscons seems to lack features.

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 sh /etc/rc.d/wscons start followed by sh /etc/rc.d/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/X11R6/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

# VESA framebuffer console
options 	KVM86			# required for vesabios
vesabios*	at vesabiosbus?
vesafb* 	at vesabios?
options 	VESAFB_WIDTH=640
options 	VESAFB_HEIGHT=480
options 	VESAFB_DEPTH=8
options 	VESAFB_PM		# power management support
wsdisplay*	at vesafb? console ?

# VIA Unichrome framebuffer console
unichromefb* 	at pci? dev ? function ?
wsdisplay* 	at unichromefb?

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
# sh /etc/rc.d/wsmoused start 

This console driver doesn't offer virtual consoles and utility programs for configuration but takes up very little space. Due to this, it can be found on the i386 install floppy. It is only available for a handful of architectures, mostly i386 derivatives.

To enable it, put the following line in your kernel config file:

pc0 at isa? port 0x60 irq 1 # pccons generic PC console driver

You can also set one of several options to compile in a non-english keymap:

# Keyboard layout configuration for pccons
#options        FRENCH_KBD
#options        FINNISH_KBD
#options        GERMAN_KBD
#options        NORWEGIAN_KBD

Remove the comment character in front of one of this to enable the corresponding keymap, then follow the instructions in Chapter 32, Compiling the kernel to rebuild your kernel.

In general, you shouldn't need pccons though, and wscons should fit all your needs.

NetBSD uses the X Window System to provide a graphical interface. In NetBSD 5.0, the amd64, i386, macppc, shark, sgimips, and sparc64 ports use X.Org and the rest use XFree86.

Please note that the X Window System is a rather bare bones framework. It acts as a base for modern desktop environments like GNOME or KDE, 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:

In some cases, you may be able to start using X without any configuration at all, and startx will work just fine. In many cases, however, some configuration of the X server is required. Depending on the port you use, this configuration file will be either /etc/X11/xorg.conf or /etc/X11/XF86Config. The structure of the configuration file is described formally in xorg.conf(5) or XF86Config(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. To quit, press Ctrl-Alt-Backspace.

If the above test was successful, move the file into place (as either /etc/X11/xorg.conf or /etc/X11/XF86Config) and you are ready to go. The following sections may be of interest or use, but are not required reading.

PS/2 and USB mice will normally be autodetected, and a configuration entry like the following will be generated:

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "wsmouse"
        Option      "Device" "/dev/wsmouse"
        Option      "ZAxisMapping" "4 5 6 7"
EndSection

For a serial mouse on the first serial port, try something like:

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "auto"
        Option      "Device" "/dev/tty00"
EndSection

In this example. /dev/tty00 is the first serial port. Use /dev/tty01 for the second, and so on. Protocol "auto" will try to automatically detect the protocol of your serial mouse. If this doesn't work, try values like "Microsoft", "IntelliMouse" or "Logitech". See mousedrv(4) for more information.

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 the XKB protocol to specify the keyboard type and layout.

Here is an example that shows how to use a German keyboard:

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
        Option      "XkbRules" "xorg"
        Option      "XkbModel" "pc105"
        Option      "XkbLayout" "de"
        Option      "XkbOptions" "ctrl:nocaps"
EndSection

If you wish to change the repeat rate of your keyboard, you can set it with the “AutoRepeat” option, 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:

Option      "AutoRepeat"    "200 30"

If X is already running, the keyboard repeat rate can be changed with the xset(1) command:

$ xset r 200 30

You can also run this command in your .xinitrc file. See below (Section 9.8, “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

If your preferred resolution is not listed, or you have issues with flickering, you may need to manually specify your monitor's horizontal and vertical frequencies. These can be set with the “HorizSync” and “VertRefresh” directives in the “Monitor” section. An example is provided below.

Section "Monitor"
        Identifier   "Monitor0"
        VendorName   "Monitor Vendor"
        ModelName    "Monitor Model"
        HorizSync    30-83
        VertRefresh  56-75
EndSection

Normally, your video card will be automatically detected. In the event that this autodetection fails, all available drivers can be found in /usr/X11R7/lib/modules/drivers. (Replace “X11R7” with “X11R6” if you use a port that has not yet switched to X.Org.) The driver can be set with the “Driver” directive in the “Device” section, as shown below.

Section "Device"
        Identifier  "Card0"
        Driver      "intel"
EndSection

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 (twm). If you want a more advanced window manager or desktop environment, many are available in pkgsrc. See Section 9.9, “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
$ vi ~/.xinitrc

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

...
# start some nice programs
xclock -geometry 50x50-1-1 &
xsetroot -solid bisque4 &
xterm -geometry 80x34-1+1 -bg OldLace &

exec twm    # 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 twm, 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:

# pkg_add -v 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 twm 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 “Exit” or similar from the window manager's menu will quit the window manager and end the X11 session.

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

# pkg_add -v xfce4
# cp /usr/pkg/share/examples/rc.d/famd /etc/rc.d
# cp /usr/pkg/share/examples/rc.d/dbus /etc/rc.d
# cp /usr/pkg/share/examples/rc.d/hal /etc/rc.d
# echo rpcbind=YES >> /etc/rc.conf
# echo famd=YES >> /etc/rc.conf
# echo dbus=YES >> /etc/rc.conf
# echo hal=YES >> /etc/rc.conf
# /etc/rc.d/rpcbind start
# /etc/rc.d/famd start
# /etc/rc.d/dbus start
# /etc/rc.d/hal start

After running the above commands, edit your .xinitrc as above and change “openbox” (or “twm”) to “xfce4-session”. 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/X11R6/bin/X :0 vt04

then in /etc/ttys you should have

ttyE3   "/usr/libexec/getty Pc"         vt220   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 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

The installation of the Linux emulation is described in the compat_linux(8) man page; using the package system only two steps are needed.

option COMPAT_LINUX
option EXEC_ELF32

option COMPAT_LINUX
option EXEC_ELF64

# pkg_info -a | grep suse
suse_base-10.0nb3   Linux compatibility package
suse_compat-10.0nb1 Linux compatibility package with old shared libraries
suse_x11-10.0nb2    Linux compatibility package for X11 binaries
      

# make
# make install

If we examine the outcome of the installation of the Linux libraries and programs we find that /emul/linux is a symbolic link pointing to /usr/pkg/emul/linux, where the following directories have been created:

How much space is required for the Linux emulation software? On one system we got the following figure:

# cd /usr/pkg/emul
# du -k /emul/linux/
...
127804  /emul/linux/

Acrobat Reader, the program, has been installed in the usual directory for package binaries: /usr/pkg/bin. It can be run just as any other program:

$ acroread netbsd.pdf 

Some Linux programs rely on a Linux-like /proc filesystem. The NetBSD procfs filesystem can emulate a /proc filesystem that contains Linux-specific pseudo-files. To accomplish this you can mount the procfs with the “linux”-option:

# mount_procfs -o linux procfs /emul/linux/proc

In this example a Linux-like proc filesystem will be mounted to the /emul/linux/proc directory. You can also let NetBSD mount it automatically during the booting process of NetBSD, by adding the following line to /etc/fstab:

procfs /emul/linux/proc procfs ro,linux

Linux plugins for Mozilla-based browsers can be used on native NetBSD Firefox builds through nspluginwrapper, a wrapper that translates between the native browser and a foreign plugin. At the moment, nspluginwrapper only works reliably on Mozilla-based browsers that link against GTK2+ (GTK1+ is not supported). nspluginwrapper can be installed through pkgsrc:

# cd /usr/pkgsrc/www/nspluginwrapper
# make install
    

Plugins can then be installed in two steps: first, the plugin has to be installed on the system (e.g. through pkgsrc). After that the plugin should be registered with the nspluginwrapper by the users who want to use that plugin.

In this short example we will have a look at installing the Macromedia Flash plugin. We can fullfill the first step by installing the Flash plugin through pkgsrc:

# cd /usr/pkgsrc/multimedia/ns-flash
# make install
    

After that an unprivileged user can register the Flash plugin:

$ nspluginwrapper -i /usr/pkg/lib/netscape/plugins/libflashplayer.so
    

The plugin should then be registered correctly. You can check this by using the -l option of nspluginwrapper (nspluginwrapper -l). If the plugin is listed, you can restart Firefox, and verify that the plugin was installed by entering about:plugins in the location bar.

The following articles may be of interest for further understanding Linux (and other) emulation:

In order to make audio work on your system you must know what audio card is installed. Sadly it is often not enough to know the brand and model of the card, because many cards use chipsets manufactured from third parties. Therefore knowing the chipset installed on the audio card can sometimes be useful. The NetBSD kernel can recognize many chipsets and a quick look at dmesg is enough most of the time.

Therefore, type the following command:

# dmesg | more

and look for the audio card and chipset. If you're lucky you won't need to do anything because NetBSD automatically detects and configures many audio cards.

Sometimes audio doesn't work because the card is not supported or because you need to do some work in order for the card to be detected by NetBSD. Many audio cards are nowadays very cheap, and it is worth considering buying a different card, but before doing this you can try some simple steps to make the card work with NetBSD.

This section is useful only to the owners of i386 PCs; on other architectures (e.g. Amiga) there are no such features. The most important thing to determine in order to use the audio card with NetBSD is the type of bus supported by the card.

The most common interfaces are ISA and PCI.

ISA Plug and Play cards are usually more tricky to configure mostly because of the interaction with the BIOS of the computer.

On the newer machines (those produced after 1997) there is a BIOS option which causes many headaches for the configuration of ISA Plug and Play audio cards (but not only audio cards): this option is usually named “PNP OS Installed” and is commonly found in the “PNP/PCI Configuration” (the names can be different in your BIOS.) As a general rule it is usually better to disable (i.e. set it to “NO”) this option for NetBSD.

During the installation of NetBSD the devices are created in the /dev directory. We are primarily interested in:

If they are not present they can be created like this:

# cd /dev
# ./MAKEDEV all

This command creates all the devices, including the audio devices.

The audio card is now probably ready to be used without further work.

You can make a quick test and send an audio file to the device (audio files usually have the .au extension), but if you don't have an audio file you can just send a text or binary file (of course you won't hear anything useful...). Use /dev/audio or /dev/sound:

# cat filename > /dev/audio

or

# cat filename > /dev/sound

If you hear something it means that the card is supported by NetBSD and was recognized and configured by the kernel at boot; otherwise you must configure the kernel settings for the audio device installed on the system (assuming the card/chipset is supported.)

NetBSD supports a wide range of audio cards and the GENERIC kernel already enables and configures most of them. Sometimes it is necessary to manually set up the IRQ and DMA for non-PnP ISA cards.

If you still have problems you can try enabling all the devices, because some audio cards can be made to work only by emulating another card.

Many chipset make use of the SoundBlaster and OPL compatibility, but a great number of them work with the WSS emulation.

OPL is a MIDI synthesizer produced by Yamaha; there are many OPL variants (e.g. OPL2, OPL3SA, OPL3SA2, etc.). Many audio cards rely on this component or on a compatible one. For example, the chips produced by Crystal (and amongst them the very common CS423x) all have this chipset, and that's why they work with NetBSD.

WSS is not a microchip; it is the acronym of Windows Sound System. WSS is the name of the NetBSD kernel driver which supports the audio system of Microsoft Windows. Many audio cards work with Windows because they adhere to this standard (WSS) and the same holds for NetBSD.

Of the many audio cards that I tested with NetBSD, a good number work only if opl* and wss* are enabled in the kernel.

You should have no problem to get the Creative SoundBlaster cards to work with NetBSD: almost all of them are supported, including the Sound Blaster Live 1024!

When everything works you can disable in the kernel configuration file the devices that you don't need.

NetBSD comes with a number of commands that deal with audio devices. They are:

# audioctl -a | more

# audioctl -w play=44100,2,16,slinear_le

# audioctl encodings

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:

# sh /etc/rc.d/lpd start

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

# ps ax | grep lpd
  179 ??  Is     0:00.01 lpd 

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

The filter program for PostScript output is more complex than the text base one: the file to be printed is fed to the interpreter which converts it into a sequence of commands in the printer's control language, and then sends that off to the printer. We have achieved to transform a cheap color printer in a device suitable for PostScript output, by virtue of the NetBSD operating system and some powerful freeware packages. The options used to configure Ghostscript are described in the Ghostscript documentation: cdj550 is the device used to drive the HP printer.

#!/bin/sh
# Treat LF as CR+LF
printf "\033&k2G" || exit 2
# Print the postscript file
/usr/pkg/bin/gs -dSAFER -dBATCH -dQUIET -dNOPAUSE -q -sDEVICE=cdj550 \
-sOutputFile=- -sPAPERSIZE=a4 - && exit 0
exit 2

To summarize: two different printer names have been created on the system, which point to the same physical printer but use different options, different filters and different spool directories. Text files and PostScript files can be printed. To print PostScript files the Ghostscript package must be installed on the system.

This section lists some useful BSD commands for printer and print jobs administration. Besides the already mentioned lpr and lpd commands, we have:

It is possible to configure the printing system in order to print on a printer connected to a remote host. Let's say that, for example, you work on the wotan host and you want to print on the printer connected to the loge host. The /etc/printcap file of loge is the one of Example 12.3, “/etc/printcap”. From wotan it will be possible to print Postscript files using Ghostscript on loge.

The first step is to accept the print jobs submitted from the wotan host to the loge host. To accomplish this, a line with the wotan host name must be added to the /etc/hosts.lpd file on loge:

# hostname
loge
# cat /etc/hosts.lpd
wotan 

The format of this file is very simple: each line contains the name of a host which is permitted to print on the local system. By default the lpd daemon only listens on UNIX domain sockets for local connections, it won't accept any network connects. To ensure the daemon also accepts incoming network traffic, the following will need to be added to /etc/rc.conf:

lpd_flags=""

Next, the /etc/printcap file on wotan must be configured in order to send print jobs to loge. For example:

lp|line printer on loge:\
	:lp=:sd=/var/spool/lpd/lp:lf=/var/log/lp-errs:\
	:rm=loge:rp=lp

ps|Ghostscript driver on loge:\
	:lp=:sd=/var/spool/lpd/ps:lf=/var/log/lp-errs:\
	:mx#0:\
	:rm=loge:rp=ps

There are four main differences between this configuration and the one of Example 12.3, “/etc/printcap”.

Now the print jobs for the “lp” and “ps” queues on wotan will be sent automatically to the printer connected to loge.

PC-style floppy disks work mostly like other disk devices like hard disks, except that you need to low-level format them first. To use an common 1440 KB floppy in the first floppy drive, first (as root) format it:

# fdformat -f /dev/rfd0a

Then create a single partition on the disk using disklabel(8):

# disklabel -rw /dev/rfd0a floppy3

Creating a small filesystem optimized for space:

# newfs -m 0 -o space -i 16384 -c 80 /dev/rfd0a

Now the floppy disk can be mounted like any other disk. Or if you already have a floppy disk with an MS-DOS filesystem on it that you just want to access from NetBSD, you can just do something like this:

# mount -t msdos /dev/fd0a /mnt

However, rather than using floppies like normal (bigger) disks, it is often more convenient to bypass the filesystem altogether and just splat an archive of files directly to the raw device. E.g.:

# tar cvfz /dev/rfd0a file1 file2 ...

A variation of this can also be done with MS-DOS floppies using the sysutils/mtools package which has the benefit of not going through the kernel buffer cache and thus not being exposed to the danger of the floppy being removed while a filesystem is mounted on it.

Data CDs can contain anything from programs, sound files (MP3, wav), movies (MP3, QuickTime) to source code, text files, etc. Before accessing these files, a CD must be mounted on a directory, much like hard disks are. Just as hard disks can use different filesystems (ffs, lfs, ext2fs, ...), CDs have their own filesystem, "cd9660". The NetBSD cd9660 filesystem can handle filesystems without and with Rockridge and Joliet extensions.

CD devices are named /dev/cd0a for both SCSI and IDE (ATAPI).

With this information, we can start: