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:

Using OpenNTPD

OpenNTPD is a safe and simple NTP-compatible way to have accurate time on your computer. The ntpd(8) daemon is enabled by default at install time, resulting in your computer's clock slowly syncing with the pool.ntp.org time servers. Once the clock is accurately set, ntpd will hold it at a high degree of accuracy. However, if your time is more than a few minutes off, it is recommended to bring it close to accurate initially with the -s flag.

To use OpenNTPD as a server, add a listen on * line to your ntpd.conf(5) file and restart the daemon. You can also instruct it to only listen on a specific address or interface.

When you have ntpd(8) listening, other machines may not be able to synchronize their clocks right away. This is because time information won't be served until the local clock is synced with a reasonable level of stability. Once this level is reached, a "clock now synced" message will appear in /var/log/daemon.

Time zones

By default, OpenBSD assumes your hardware clock is set to UTC (Coordinated Universal Time) rather than local time. This 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 Standard Time (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
Also see the date(1) manual.

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.

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

Some new users experience a login delay when using services such as ssh(1), or when using a proxy or 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 "www.openbsd.org") 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) and ftp-proxy(8). Unfortunately, in some cases, the machine that is making the connection does not have a proper reverse DNS entry.

Fix using the hosts file

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

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

::1          localhost.in.example.org localhost
127.0.0.1    localhost.in.example.org localhost
192.168.1.1  gw.in.example.org        gw
192.168.1.20 scrappy.in.example.org   scrappy
192.168.1.35 shadow.in.example.org    shadow
Your /etc/resolv.conf file might look something like this: 
search in.example.org
nameserver 24.2.68.33
nameserver 24.2.68.34
lookup file bind
If you are using DHCP, you should add lookup file bind to your /etc/resolv.conf.tail file, as resolv.conf will be overwritten by dhclient(8).

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
[...]
Here we have two different network cards, neither of them functional. The first one had its vendor code identified, and the general type of card was determined, but not the precise model. The second one was fully identified, but the not configured line informs us that no driver was found for it.

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