/usrpartitions and run passwd(1) to change the root password:
-sflag to boot(8):
probing: pc0 com0 com1 mem[638K 1918M a20=on] disk: hd0+ hd1+ >> OpenBSD/amd64 BOOT 3.33 boot> boot -s
/usrwill need to be mounted read-write.
# fsck -p / && mount -uw / # fsck -p /usr && mount /usr
ntpdwill 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
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
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
For example, to set the machine to use EST5EDT as the new local time zone:
# ln -fs /usr/share/zoneinfo/EST5EDT /etc/localtimeAlso see the date(1) manual.
To use the Unicode character set in UTF-8 encoding whereever supported, set the
LC_CTYPE environment variable to the value
export LC_CTYPE="en_US.UTF-8"to your
~/.xsessionbefore starting the window manager. See customizing X for more details.
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.
LC_CTYPEenvironment 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-8in the remote shell after connecting.
The OpenBSD base system completely ignores all locale-related environment
LANG only affect the character encoding.
Some ports may respect other
but using them or setting
LC_CTYPE to any value other than
is not recommended.
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.
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
nameserverlines in your resolv.conf(5).
/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 shadowYour
/etc/resolv.conffile might look something like this:
search in.example.org nameserver 126.96.36.199 nameserver 188.8.131.52 lookup file bindIf you are using DHCP, you should add
lookup file bindto your
resolv.confwill be overwritten by dhclient(8).
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 configuredline informs us that no driver was found for it.
not configureddevice, 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.