OpenBSD FAQ - General Questions [FAQ Index]

I forgot my root password

The basic process to regain root is to boot into single user mode, mount the / and /usr partitions and run passwd(1) to change the root password: If this is a non-personal machine, you should probably use doas(1) to give multiple (trusted) people the ability to execute root commands.

"Wait. That looked too easy! That isn't very secure!" If an attacker has physical access to your system, they win, regardless of the OS on the computer. There are ways to force the use of a password on single-user mode, see ttys(5), or eliminate the pause on i386/amd64, see boot.conf(8). Getting around those tricks is also pretty easy. One way would be to boot from a CD or USB drive and edit (or replace) the password file. You can try to prevent that, but then someone will pull the hard disk out of your computer. Making your computer difficult to manage properly isn't real security, and if you don't have the physical machine secured, you have no real security.

Note: many "remote management" systems give most of the functionality of physical access to the computer, and that needs to be considered. Don't tell yourself the system is secure if there is a way for an attacker to grab console, insert a virtual floppy and force a reboot of the machine. They might as well have physical access to the system. The console management system is likely not as secure as OpenBSD.

The boot loader

The OpenBSD boot loader is documented in the architecture-specific boot(8) man page. If no commands are issued at the boot> prompt, the boot loader will automatically try to boot /bsd. You can specify a kernel by typing:
boot> boot hd0a:/bsd
This will boot the kernel named bsd from the a partition of the first BIOS recognized hard disk.

The following options are available.

The format is boot [image [-acds]].

Using OpenNTPD

OpenNTPD is a trivial-to-administer, safe and simple NTP-compatible way to have accurate time on your computer. OpenBSD's ntpd(8) is controlled with a simple configuration file, ntpd.conf(5).

The OpenNTPD daemon is enabled by default at install time, which results in your computer's clock slowly moving into synchronization with the time servers. Once your clock is accurately set, ntpd will hold it at a high degree of accuracy. However, if your clock is more than a few minutes off, it is recommended that you bring it close to accurate initially, as it may take days or weeks to bring a very-off clock to sync. You can do this using the -s option of ntpd(8) or any other way to accurately set your system clock.

Why can't my other machines synchronize to ntpd?

OpenNTPD does not listen on any address by default. In order to use it as a server, you have to add a listen on * line to /etc/ntpd.conf and restart the daemon. Of course, if you want it to listen on a particular IP address rather than all available addresses and interfaces, replace the "*" with the desired address.

When you have ntpd(8) listening, it may happen that other machines still can't synchronize to it! A freshly started ntpd(8) daemon (for example, if you just restarted it after modifying ntpd.conf) refuses to serve time information to other clients until it adjusts its own clock to a reasonable level of stability first. When ntpd(8) considers its own time information stable, it announces it by a "clock now synced" message in /var/log/daemon. Even if the system clock is pretty accurate in the beginning, it can take up to 10 minutes to get in sync, and hours or days if the clock is not accurately set at the start.

Why is my clock off by twenty-some seconds?

When using rdate(8) to synchronize your clock to a NTP server, you may find your clock is off by twenty-some seconds from your local definition of time.

This is caused by a difference between UTC (Coordinated Universal Time, based on astronomical observations) and TAI (International Atomic Time, based on atomic clocks). To compensate for variations in the earth's rotation, "leap seconds" are inserted into UTC, but TAI is unadjusted. These leap seconds are the cause of this discrepancy. For a more detailed description, search the web for leap seconds UTC TAI.

Addressing the problem is fairly simple. In most countries you will get the correct time if you use the -c parameter to rdate(8) and use a time zone out of the directory /usr/share/zoneinfo/right. For example, if you are located in Germany, you could use these commands:

     # cd /etc && ln -sf /usr/share/zoneinfo/right/CET localtime
     # rdate -ncv
In other countries, the rules may differ.

Time zones

By default, OpenBSD assumes your hardware clock is set to UTC (Universal Coordinated Time) rather than local time, assumed by some other operating systems, which can cause problems when multibooting.

Many other operating systems can be configured to do the same, which avoids this problem altogether.

If having the hardware clock set to UTC is a problem, you can change the default behavior of OpenBSD using config(8). For example, to configure OpenBSD to use a hardware clock set to US/Eastern (5 hours behind UTC, so 300 minutes):

# config -ef /bsd
Enter 'help' for information
ukc> timezone 300
timezone = 300, dst = 0
ukc> quit
Saving modified kernel.
See options(4) and search for option "TIMEZONE=value" for more information.

Normally, the time zone is set during install. If you have need to change the time zone, you can create a new symbolic link to the appropriate time zone file in /usr/share/zoneinfo. For example, to set the machine to use EST5EDT as the new local time zone:

# ln -fs /usr/share/zoneinfo/EST5EDT /etc/localtime
See also the date(1) manual and the section on OpenNTPD above.

Character sets and localization

The OpenBSD base system fully supports the ASCII character set and encoding, and partially supports the UTF-8 encoding of the Unicode character set. No other encodings or character sets are supported by the base system, but ports can be used to handle them.

The level of UTF-8 support and the default encoding configuration vary greatly with the program or library. For example, xterm(1) has full UTF-8 support enabled by default, while the regular expression library does not have any UTF-8 support yet.

To use the Unicode character set in UTF-8 encoding whereever supported, set the LC_CTYPE environment variable to the value en_US.UTF-8:

When logging into remote systems with ssh(1), the LC_CTYPE environment variable is not propagated, and you have to make sure that the local terminal is set to the character encoding used by the remote server before starting the ssh(1) client program. If that encoding is unknown or unsupported by OpenBSD, make sure you use the default xterm(1) configuration and set LC_CTYPE=en_US.UTF-8 in the remote shell after connecting.

The OpenBSD base system completely ignores all locale-related environment variables except LC_CTYPE; even LC_ALL and LANG only affect the character encoding. Some ports may respect other LC_* variables, but using them or setting LC_CTYPE to any value other than C, POSIX or en_US.UTF-8 is not recommended.

Reverse DNS

Many new users to OpenBSD experience a two minute login delay when using services such as ssh(1) or ftp(1). This can also be experienced when using a proxy, such as ftp-proxy(8), or when sending mail.

This is almost always due to a reverse-DNS problem. DNS is the Domain Name Service, the system the Internet uses to convert a name, such as "", into a numeric IP address. Another task of DNS is the ability to take a numeric address and convert it back to a name. This is known as a Reverse DNS entry.

In order to provide better logging, OpenBSD performs a reverse DNS lookup on any machine that attaches to it in many different ways, including ssh(1), ftp(1), ftp-proxy(8). Unfortunately, in some cases, the machine that is making the connection does not have a proper reverse DNS entry.

An example of this situation:

A user sets up an OpenBSD box as a firewall and gateway to their internal home network, mapping all their internal computers to one external IP using NAT. They may also use it as an outbound mail relay. They follow the installation guidelines, and are very happy with the results, except for one thing -- every time they try to attach to the box in any way, they end up with a two minute delay before things happen.

What is going on:

From a workstation behind the NAT of the gateway with an unregistered IP address of, the user uses ssh(1) to access the gateway system. The ssh(1) client prompts for username and password, and sends them to the gateway box. The gateway then tries to figure out who is trying to log in by performing a reverse DNS lookup of The problem is addresses are for private use, so a properly configured DNS server outside your network knows it should have no information about those addresses. Some will quickly return an error message. In these cases, OpenBSD will assume there is no more information to be gained, and it will quickly give up and just admit the user. Other DNS servers will not return ANY response. In this case, you will find yourself waiting for the OpenBSD name resolver to time out, which takes about two minutes before the login will be permitted to continue. In the case of ftp-proxy(8), some ftp clients will timeout before the reverse DNS query times out, leading to the impression that ftp-proxy isn't working.

This can be quite annoying. Fortunately, it is an easy thing to fix.

Fix, using /etc/hosts:

The simplest fix is as follows: Populate your hosts(5) file with all the workstations you have in your internal network. Make sure that your resolv.conf(5) file contains the line lookup file bind. This tells the resolver to start with the hosts(5) file, and failing that, to use the DNS servers specified by the nameserver lines in your resolv.conf(5) file.

Your /etc/hosts file will look something like this:

::1 localhost localhost gw scrappy shadow
Your /etc/resolv.conf file will look something like this:
lookup file bind
A common objection to this is "But, I use DHCP for my internal network! How can I configure my /etc/hosts?" Rather easily, actually. Just enter lines for all the addresses your DHCP server is going to give out, plus any static devices:
::1 localhost localhost gw scrappy shadow d100 d101 d102
         [... snip ...] d198 d199
This case assumes you have the DHCP range set to through, plus the three static definitions as listed at the top of the file.

If your gateway must use DHCP for configuration, you may well find you have a problem -- dhclient(8) will overwrite your /etc/resolv.conf every time the lease is renewed, which will remove the lookup file bind line. This can be solved by putting the line lookup file bind in the file /etc/resolv.conf.tail.

Fix, using a local DNS server

Details on this are somewhat beyond the scope of this document, but the basic trick is to set up your favorite DNS server, and make sure it knows it is authoritative for both forward and reverse DNS resolution for all nodes in your network, and make sure your computers (including your gateway) know to use it as a DNS server.

Device "not configured" in dmesg

In short, it means your device is not supported by the kernel you are using, so you will not be able to use it.

PCI and many other types of devices offer identifying information so that the OS can properly recognize and support devices. Adding recognition is easy, adding support is often not. Here are two examples of "not configured" devices:

vendor "Intel", unknown product 0x5201 (class network subclass ethernet,
rev 0x03) at pci2 dev 9 function 1 not configured
"Intel EE Pro 100" rev 0x03 at pci2 dev 10 function 0 not configured
The first one (a network adapter) had its vendor code identified and the general type of card was determined, but not the precise model of the card. The second example is another network adapter, this one a developer had seen and entered into the identification file that is used to identify the card. In both cases, however, the cards will be non-functional, as both are shown as not configured, meaning no driver has attached to the card.

What can I do about a "not configured" device?

Unfortunately, many manufacturers use product model numbers to indicate marketplace position, rather than the technical nature of a product. For this reason, you may buy a product with the same name or model number as a product listed in the platform pages, but end up with a totally different product that may not work with OpenBSD.

For example, many early wireless network adapters were based on the Prism2 chipset, using the wi(4) driver, but later, when lower-cost chips became available, many manufacturers changed their product to use chips for which no open source drivers exist, but never changed their model numbers. Wireless network adapters, unfortunately, are far from the only example of this.