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
- Boot into single user mode.
This part of the process varies depending on your
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
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
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
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
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
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
For example, to configure OpenBSD to use a hardware clock set to
US Eastern Standard Time (5 hours behind UTC, so 300 minutes):
and search for option "TIMEZONE=value" for more information.
# config -ef /bsd
Enter 'help' for information
ukc> timezone 300
timezone = 300, dst = 0
Saving modified kernel.
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:
Also see the date(1) manual.
# ln -fs /usr/share/zoneinfo/EST5EDT /etc/localtime
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
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.
If logging in via xdm(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.
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.
Some new users experience a login delay when using services such as
ssh(1), or when using a proxy or
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,
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
file contains the line lookup file bind.
This tells the resolver to start with the
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:
Your /etc/resolv.conf 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
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
lookup file bind
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:
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.
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
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.