OpenBSD FAQ: General Questions

OpenBSD FAQ - General Questions [FAQ Index]

I Forgot My Root Password
Using OpenNTPD
Time Zones
Character Sets and Localization
Reverse DNS
Device "not configured" in dmesg

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:

Boot into single user mode. This part of the process varies depending on your platform. For amd64 and i386, the second stage boot loader pauses for a few seconds to give you a chance to provide parameters to the kernel. Here you can see we pass the -s flag to boot(8):
```
probing: pc0 com0 com1 mem[638K 1918M a20=on]
disk: hd0+ hd1+
>> OpenBSD/amd64 BOOT 3.33
boot> boot -s
```
Mount the partitions. Both / and /usr will need to be mounted read-write.
```
# fsck -p / && mount -uw /
# fsck -p /usr && mount /usr
```
Run passwd(1) to change the root password. From being in single user mode, you already have root privileges, so it will not ask you to provide your current password.
Boot into multiuser mode. This can be done by either entering "CTRL-D" to resume the normal boot process, or by entering the reboot(8) command.

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. While booting, ntpd will set the clock based on data received from NTP peers validated using constraints retrieved using https. Once the clock is accurately set, ntpd will hold it at a high degree of accuracy using the configured time servers specified in ntpd.conf(5). At boot, ntpd will only jump the clock forward. If your clock has to be moved backward, manually set the clock using date(1).

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 via sysctl.conf(5). For example, put the following in /etc/sysctl.conf to configure OpenBSD to use a hardware clock set to US Eastern Standard Time (5 hours behind UTC, so minus 300 minutes):

kern.utc_offset=-300

See sysctl(2) and search for "kern.utc_offset" for more information.

Note that the hardware clock must already be running at the desired offset before booting OpenBSD with the above configuration or the system time will be incorrectly adjusted at boot.

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 wherever supported, set the LC_CTYPE environment variable to the value en_US.UTF-8:

If logging in via xenodm(1), add export LC_CTYPE="en_US.UTF-8" to your ~/.xsession before starting the window manager. See customizing X for more details.
If logging in via the text console, add export LC_CTYPE="en_US.UTF-8" to your ~/.profile. The text console's UTF-8 support is a work in progress, and some non-ASCII characters may not display properly.

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?

If the device is not one you need, you can safely ignore the not configured warnings.
In some cases, it's just a variation of a supported device. This means it may be relatively easy for a developer to add support for the new card. Otherwise, a new driver would have to be written, which may not even be possible if the device is not fully documented.
If you're running the install kernel, the device may not be supported due to space constraints. Be sure to try with the standard GENERIC kernel.
Before reporting a not configured device, make sure you have first tested the most recent snapshot, as support may already have been added. Also check the mailing list archives to see if the issue has been discussed already.