[#obsdinst]:

OpenBSD Installation Guide

Available Guide(s)

In addition to this guide, there is OpenBSD FAQ 4 : Installation Guide maintained by the OpenBSD development team. This guide has quite a bit of information that overlaps with the official guide, perhaps starting at the official guide's OpenBSD FAQ 4: “Installation Guide”, Section on “Booting OpenBSD install media”. Also, installation instructions are included with the pamphlet-manual that comes with the official CD set.

This guide has some details about the “disk setup” process which, in the opinion of the author of this text, may be superior to what has been presented by the official guide. (This guide may provide some additional details about the “disk setup” process.) This guide also provides some post-installation recommendations.

Booting OpenBSD

Choosing the right boot media

Choosing a platform

A person who is going to install OpenBSD should identify which “platform” will be used to install the operating system.

Most common platforms

PCs

For most typical PCs, people will generally want to check of the computer is using a “64-bit” CPU. (In contrast, another possibility may be a “32-bit” CPU. Decades ago, typical computers used simpler (and slower) CPUs, like the 80286 which was a “16-bit” CPU.) If the system comes with more than 4GB of RAM, then the CPU is typically a “64-bit” CPU.

If the computer is using a “64-bit” CPU, then the “amd64” platform will genrally be desired. This is true even if the CPU was made by Intel, and not AMD.

One option may be to try the “amd64” platform first. OpenBSD FAQ 12.3.1: OpenBSD/amd64 CPU compatability recommends trying that, so testing this should be fairly safe. If the OpenBSD/amd64 platform doesn't boot properly, but the “i386” platform does work, then, by all means, continue to use the “i386” platform.

If a system does not properly boot the OpenBSD/amd64 kernel, then the next best bet is the “i386” platform. Such computers will typically have 4GB of RAM or less, and OpenBSD/i386 may impose some limitations of using 4GB or less (even if a machine has more RAM than that). Using the “i386” is generally not desired if the computer has more than 4GB of RAM.

Additional notes about choosing between OpenBSD/amd64 and OpenBSD/i386

Sometimes the “amd64” platform may not produce the absolute best results, as noted by OpenBSD FAQ 12.3.1: info on amd64 compatability and OpenBSD FAQ 12.3.3: Is OpenBSD/amd64 superior to OpenBSD/i386? However, in most cases, OpenBSD/amd64 provides superior memory management and speed, so if an OpenBSD installation is just m eant for one computer and OpenBSD/amd64 is an option, then use that instead of OpenBSD/i386.

If in doubt, the “i386” is the safest choice which works on the widest variety of computers. For systems that will not be performing tasks that use lots of RAM (like running virtual machines), OpenBSD/i386 may be the best option for a system that will be booted on a wide variety of machines. For instance, using OpenBSD/i386 may be a more compatible option for installing to removable media.

Other types of devices

At the time of this writing, consider the use of other, newer (mobile) types of non-PC devices may to be a process that may be a bit more experimental/bumpy.

This isn't meant to suggest that OpenBSD is incapable software. OpenBSD Journal @ Undeadly.org: article called “Android's C Library Has 173 Files of Unchanged OpenBSD Code” proves that OpenBSD code can be worthy for being used by the Android platform. However, this does not mean that the official OpenBSD installation process has been fine-tuned to work extremely well on these types of platforms (yet).

A person should be able to do some research to determine which CPU architecture is being used. Then, review the list of OpenBSD Platforms. Choosing the platform that matches a specific CPU architecture should be a relatively simple task.

This guide was written for PCs. Forum post indicates that OpenBSD's ARM support may be useful. However, supporting newer (mobile) types of non-PC devices may be a priority that has been delayed until after the development process has completed a switch to using LLVM/clang rather than GCC.

OpenBSD Platforms provides a list of supported platforms, as well as documentation specific to the platform. This platform-specific documentation lists supported hardware as well as some various boot images. (For example, OpenBSD/i386's installation details lists multiple floppy disk images that come with different drivers.)

Using bootable CDs

Using a bootable CD is probably the most common method for installing OpenBSD on a computer which does not currently have OpenBSD installed. The OpenBSD project generates a significant portion of its finances from selling official CDs. Those who can afford official OpenBSD CDs are highly encouraged to get them (with each new scheduled version of OpenBSD, if possible). CDs may also be downloaded: the install??.iso file is recommended if there are concerns on getting Internet access working before the operating system is installed. Otherwise, the cd??.iso file is smaller.

(For example, for OpenBSD 5.4, the “install??.iso” file was named “install54.iso” and the the “cd??.iso” file was named “cd54.iso”.)

These (install??.iso and cd??.iso) CD images, which are downloadable from the official public OpenBSD archives, are different than the images that are used for creating the official physical CDs. The official physical CDs contain more data, such as the source code for the “base” operating system and additional software. One of the official physical CDs in each release will also contain an audio track for the OpenBSD song that was created for that release (presumably starting with OpenBSD 3.0).

If using a downloadable image, (See: writing CDs.)

This, of course, will require making sure the computer is set to boot off of CDs.

Other traditional methods of booting

Perhaps as a result of being an older project that was around when floppy disks were at least somewhat commonly used, OpenBSD/i386: section on getting and installing the operating system discusses different bootable floppy disk images. (See: floppy disk images.)

Supported variation of booting

network booting

This process is not fully covered by this guide, but may work.

Using a console cable

The normal installation boot media will likely use standard console (monitor or similar video output display, and keyboard) for I/O. Another method that seems to be pretty well officially supported is to use a COM port. (This is mentioned by documentation, FAQs, and rather occassionally by the OpenBSD community.) (This guide does not document how to do that, due to a lack of experience which was driven by a lack of need. However, OpenBSD FAQ 7: FAQ about using a serial port for a console (FAQ section 7.6) provides a bit more details.)

Unofficial

At least one unofficial installation method has been created. The OpenBSD team may not provide support for using such an installation method, and this guide might not have any details other than the details provided by this section. Using such an alternative approach is not generally recommended.

YAIFO

Another option may be “YAIFO”, which stands for “Yet Another Installer For OpenBSD”.

YAIFO is third party

Note that this is third party, and is not being recommended by this documentation. (This is simply being mentioned as an option.) People should understand that, like the OpenBSD binary OS files provided from community resources, this is unofficial and the general practice of using an unofficial release like this would be a fairly easy way for malware authors to get malicious code running on a server. The malicious code could even insert problems that would exist after the installation. This warning is not made to suggest that YAIFO is problematic software, but simply to communicate a general principle. Support providers may generally want to know whenever some types of actions, like using YAIFO, were used during the operating system installation process.

This also comes with an SSH server which might help people to more easily install from remote, in some situations. There may also be different RAID support than some official standard boot media. The YAIFO projects page may be the closest thing to a current home page. (The referenced YAIFO home page at http://yaifo.sf.net redirects to a page by the maintainer, but does not seem to work as desired.) See also: YAIFO (old) version 3.8: coverage by the OpenBSD Journal. YAIFO 4.8 announcement mentioned a cosmetic issue with sparc64.

At the time of this writing (August 2013), it appears that the most recent release was YAIFO 4.8, which is several versions behind the official release of OpenBSD 5.3. However, this project is being mentioned anyway, in case it actually helps someone (like a developer who would rather pick up from some progress already made by this project).

Github section for YaifO looks like it is more up to date, and contains a README file that states, “There is no binary installer available, you should always compile it on your own.”

System Startup

(Note: This portion of the guide, called “System Startup”, does not have instructions that generally need to be followed. This is simply here to thoroughly document what happens when the computer starts loading OpenBSD, primarily after the system startup process completes.)

If there are further troubles related to hardware, OpenBSD FAQ 5 (Building the System from Source): “Boot-Time Configuration” section (FAQ 5.8) discusses the “Boot-Time Configuration”. (This section of the FAQ is not really about building the system from source code.) This process is not typically necessary, and so is not discussed in much detail by this guide. Simply know that if difficulties are encountered, workarounds may be available.

This documentation was made using Qemu. That fact may be evident from some of the hardware detection logs.

This guide shows some of the basic experiences that users will encounter. Some further technical details about OpenBSD's startup process are available for reference. (At some point, some of these details might be moved into that other section.)

Qemu's BIOS

QEMU emulator version 1.1.0

SeaBIOS (version rel-1.7.0-0-ga026308-dirty-20120417_104821-rincewind.home.kraxe l.org) iPXE v1.0.0-591-g7aee315 iPXE (http://ipxe.org) 00:03.0 C900 PCI2.10 PnP PMM+0FFC88D0+0FF888D0 C900 Booting from DVD/CD...

Unknown

It isn't yet clear where this line comes from. (It would either be QEMU's BIOS, or OpenBSD's bootable CD image...) At the moment of this writing, the author of this text has not yet identified which of those sources was responsible for this next particular line of output:

CD-ROM: E0

OpenBSD Start (up to boot)

Loading /5.3/AMD64/CDBOOT probing: pc0 com0 mem[637K 254M a20=on] disk: fd0 hd0+* cd0 >> OpenBSD/amd64 CDBOOT 3.19 boot>

At this point (at the boot> prompt), press the space bar to pause. Otherwise, there is usually an invisible timer that is counting down, and then the bootup process will continue.

Before discussing various ways to proceed from this point, here are some observations about the information that has been provided so far:

• The probing results shows “ pc0”. As shown by OpenBSD/i386 “manual page” for boot/boot.conf (and OpenBSD/amd64 “manual page” for boot/boot.conf), this refers to “the (default) PC VGA+Keyboard console”.
• Out of the 256 MB that was allocated to this machine, it looks like it is broken up into pieces. 637K? Is that referring to the old-school memory layout that was responsible for MS-DOS's infamous 640K memory limitation? (See: DOS memory for further discussion on that limitation.) The answer to that question seems to be: Yes. The OpenBSD/i386 “manual page” for boot/boot.conf (and OpenBSD/amd64 “manual page” for boot/boot.conf) does refer to this as “Conventional memory” that “is detected by querying the BIOS.”

Common approach for installing

This prompt does provide a user with an opportunity to make some choices. For people who are installing OpenBSD for the first time, generally the most desirable way to proceed will be to use the kernel on the CD's boot image.

To do this, simply push Enter. (If the space bar was pressed before, pressing backspace might be needed to erase the space bar? Or, just press Enter twice?)

To proceed after the space bar had been pressed, press the Enter key. An alternative to pressing space and Enter is to just wait for that timer to expire.

Common alternatives

Although the “boot>” prompt is most commonly bypassed without any interaction, and the next most common approach is simply to just press the Enter key to skip the optional delay, there are some alternate options.

If OpenBSD has already been installed, but the computer is not providing a way to directly boot that installation of OpenBSD, then this prompt can be used to specify the kernel from that OpenBSD installation. (Then, the system's boot process can be modified to fix the problem.) If this approach is desired, the user can specify the name of an alternate kernel to try booting.

This “boot>” prompt can also be used to specify a different boot process, which can be useful if there are authentication (password-related) challenges whenever the normal boot process is used. Again, this is usually a process related to circumventing a problem, and so the next step is generally to perform troubleshooting.

OpenBSD 4.2 Errata #003: OpenBSD/i386 CD1 issue documented how switching CDs could be used as a workaround of some BIOS software being unable to load a specific CD. (This technique may not work as well with other platforms: OpenBSD FAQ 12: section on amd64 and i386 binary compatibility mentions these two specific platforms as being able to perform such a technique.)

Another option

Instead of booting, another option may be to view the contents of data found on a long term storage device (an HDD or SSD). This can be useful to help determine what kernel(s) may be available to boot. Note that listing the contents of files from a bootable CD image might not be available at this prompt, since the system may not have loaded the all of the code that would be necessary to easily see the file structure of the CD.

Kernel Start

The “booting” line may show a bunch of numbers, with an animation that spins through a sequence of characters that may include \ and / and | and \. A log of the output may look something like:

booting cd0a:/5.3/amd64/bsd.rd: 3029000\ |\-|\-+929164|/-|-/+2880680\/|-|-\/|-\/|/|/-+0+531792 [80+329496/|+214001\/]=0xb8dbb0

However, what will be seen on the screen, after the animation is all done, will simply look something like this:

booting cd0a:/5.3/amd64/bsd.rd: 3029000+929164+2880680+0+531792 [80+329496+21400 1]=0xb8dbb0

An entry point will then be shown. e.g.:

entry point at 0x1001e0 [7205c766, 34000004, 24448b12, a658a304]

A Copyright statement will then be shown. It might look like the following:

Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California.  All rights reserved.

This copyright statement is in addition to the one that shows up (not much) later (in the “system message buffer”).

However, this often ends up scrolling by so fast that the exact comntents might not be easily visible.

(What was not captured, when documenting this, is exactly when the kernel message color scheme starts. This documentation currently represents an approximated guess.)

Kernel startup output

The following is an example of what gets logged to the (“dmesg”) “system message buffer”. It starts with another Copyright statement. The next details are specific to the kernel that is being used.

Copyright (c) 1995-2013 OpenBSD. All rights reserved.  http://www.OpenBSD.org OpenBSD 5.3 (RAMDISK_CD) #51: Tue Mar 12 18:27:15 MDT 2013     deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD

Naturally, the amount of memory reported will vary based on each machine that gets installed.

real mem = 267378688 (254MB) avail mem = 240312320 (229MB)

The next part reports hardware, and so will certainly vary between different types of computer systems. The following was based on QEMU 1.1.0

mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfd940 (10 entries) bios0: vendor Bochs version "Bochs" date 01/01/2007 bios0: Bochs Bochs acpi0 at bios0: rev 0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC HPET SSDT acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat acpiprt0 at acpi0: bus 0 (PCI0) mpbios at bios0 not configured cpu0 at mainbus0: (uniprocessor) cpu0: QEMU Virtual CPU version 1.1.0, 3052.15 MHz cpu0: FPU,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MM X,FXSR,SSE,SSE2,SSE3,CX16,POPCNT,NXE,LONG,LAHF,SVM,ABM,SSE4A cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 1 6-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped

Some chipset features...

pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 "Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wi red to compatibility, channel 1 wired to compatibility

[#obsdethd]: Information about detected drives

Information about detected drives. Optical discs may appear to use a driver called “cd”. Other than that, what will commonly be seen is that drives using (E)IDE connections (including SATA drives using the PCI IDE controller driver) will use the “wd” driver; and drives using SATA connections in AHCI mode, or using USB connections, will use the “sd” driver. On a physical system, the BIOS/CMOS Configuration Setup software utility may have some options related to SATA to flip the SATA support between IDE/Legacy mode and AHCI mode. Changing that option in the BIOS may change how the disk is detected by OpenBSD.

wd0 at pciide0 channel 0 drive 0: <QEMU HARDDISK> wd0: 16-sector PIO, LBA48, 16384MB, 33554432 sectors wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: <QEMU, QEMU DVD-ROM, 1.1.> ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, DMA mode 2

The names of drives may be discussed a bit further by detecting drives (in BSD).

Some other detected equipment:

"Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured

Video card detection. With QEMU, this may appear as:

vga1 at pci0 dev 2 function 0 unknown vendor 0x1234 product 0x1111 rev 0x00

although, if -vga cirrus is used in QEMU, it may show up as:

vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00

After the display will be some terminal information:

wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)

Following is information about a detected NIC

em0 at pci0 dev 3 function 0 "Intel PRO/1000MT (82540EM)" rev 0x03: irq 11, addr ess 52:54:00:12:34:56

Some more detected hardware, including a COM port at COM1, and a keyboard (which appropriately is using IRQ1).

isa0 at mainbus0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0

Some more details related to supporting disks.

softraid0 at root scsibus1 at softraid0: 256 targets root on rd0a swap on rd0b dump on rd0b

At this point, the output tends to stop being kernel messages. This means that the color scheme of white-on-blue text (over a black background for character cells with no text being actively printed) will typically stop coming.

Note: Much of the previous output ends up going to the /var/run/dmesg.boot file, which copies the “system message buffer” at the time when the system started up. If there are additional kernel messges, they may be appended to the “system message buffer” output. The entire available contents of the “system message buffer” can be seen by running dmesg.

Next, the operating system proceeds to run the next code that it is designed to run. On an installed system running multi-user mode, this will typically be the login prompt. If the system was set to start up in single-user mode, this may be a prompt with “root” (superuser, Administrator) access. If this is an operating system installation disk/disc, then the operating system's installer will output some data.

Operating system installation

Introduction

(The installation program will greet the user.)

erase ^?, werase ^W, kill ^U, intr ^C, status ^T Welcome to the OpenBSD/$(uname -m | uname -p) $(uname -r) installation program.

(The installation program doesn't actually show “uname”. Rather, it simply shows the architecture and version number, like what the “uname” command shows.)

Specify installation process

(I)nstall, (U)pgrade or (S)hell?

Let's take a look at these options.

Enter

There is no default. Pressing the Enter key will repeat the prompt.

(I)nstall

Performs a regular new installation of the operating system. This runs the install command (located in the / directory).

(U)pgrade

Upgrading is not really covered by this guide. See: OpenBSD Binary Updating/Upgrading without source code interaction. Presumably this option runs the upgrade command (located in the / directory).

(S)hell

Typing S and pressing Enter will effectively do the same thing as typing ! and pressing Enter. That will give a shell prompt, which can then be ended by using the exit command.

This guide is about performing a fresh installation, so go ahead and choose i to (I)nstall the operating system.

Installation Process Interface Instructions

It may be quite handy to know these details:

At any prompt except password prompts you can escape to a shell by typing '!'. Default answers are shown in []'s and are selected by pressing RETURN.  You can exit this program at any time by pressing Control-C, but this can leave your system in an inconsistent state.

If Ctrl-C is pressed, then the system simply exits to a command line shell prompt. However, that pretty much aborts the installation process. At most or all prompts of the installation program, typing ! on a line by itself will shell to a command prompt. However, that general rule of thumb does not necessarily apply to the prompts of commands that the installation program runs. Notably, fdisk and disklabel do not allow the ! command. (These programs simply display a harmless error message if this is attempted.) Also, trying to input an ! when the installation program is asking for a “Password for root account” will end up actually accepting ! as input for what a new password should be.

Note: If booting off of installation media, and then opening a shell, crunchgen is used. OpenBSD FAQ 5: section on Building a Release (section 5.4) describes this further: crunchgen “is used to create a single executable file made up of many individual binaries. The name this single executable file is invoked by determines which component binary is run. This is how a number of individual program files are squeezed into the ramdisk kernel that exists on boot floppies and other boot media.” (This may be similar to BusyBox, as noted by Wikipedia's article on BusyBox: section about a “Single binary” file, or TOOGAM's tutorial on data compression: Executable code.)

Variations

Note: After this guide was first created, it was found that the OpenBSD installation process could ask certain questions in a different order, possibly caused by the results of a DHCP request. Also, it is believed that a subsequent release of OpenBSD featured a revamped installer. This guide may provide some details that can be helpful, but the actual installation process may differ from this guide. People who are seeking to become professionals in the IT field should exhibit adaptability. If information is needed but doesn't seem to be available in one section of the guide, consider reviewing other parts of the guide.

Keyboard layout

Choose your keyboard layout ('?' or 'L' for list) [default] ? Available layouts: be br cf de dk es fr hu is it jp la lt lv nl no pl pt ru sf s g si sv tr ua uk us Choose your keyboard layout ('?' or 'L' for list) [default] L Available layouts: be br cf de dk es fr hu is it jp la lt lv nl no pl pt ru sf s g si sv tr ua uk us Choose your keyboard layout ('?' or 'L' for list) [default]

As shown in the above example, a list of keyboard outputs an be displayed. Simply pressing the Enter key will choose the default (which is likely/certain to be the “us” (United States of America) layout.

System hostname(s)

System hostname? (short form, e.g. 'foo')

Type in a name for this computer system. It is a good idea to have the name reflect how the system will be used. Some organizations may benefit by having computers named after some sort of standardized naming patterns, possibly specifying the location of the machine. If this machine is being deployed alongside other networks, such as a classroom environment, it may also be a good idea to name the computer after the technician who will be installing and maintaining the computer. (See the group leader, such as the classroom instructor, for any standardized naming patterns that may be getting used.)

Type in a name (better than the example of foo), and press Enter. As a (perhaps lousy) example:

System hostname? (short form, e.g. 'foo') demosys

A blank line

The installer slides down a line without printing any text.

What is appropriate to say when sliding?

Whee!

Network Configuration

NIC configuration

Available network interfaces are: if0 vlan0. Which one do you wish to configure? (or 'done') [if0]

Interface name notes

Note: this example text will surely look different than what is seen on the screen. This guide is a general guide meant for use with different computer systems. The phrase “if0” refers to the first network interface. In reality, the computer may show a different network interface name, or even multiple other network interfaces. (Don't worry about the difference.)

OpenBSD FAQ 9: “Migrating to OpenBSD”: “Tips for users of other Unix-like Operating Systems” notes, “Devices are named by driver, not by type. For example, there are no eth* devices.” Expect the name of the NIC to vary based on what hardware is being used in this computer. (For virtual machines, that may be referring to virtual hardware.)

Recommended actions

Setting up the networking can happen after installing the operating system, unless the actual installation is going to be using the network. (Downloading and installing software is a task that is supported by this installation process.) However, setting up the networking here might actually be a bit easier, and there's usually very little compelling reason to delay that until later.

In general, the desired approach at this point is going to be to ignore any network interface that is using the VLAN driver. (So, ignore any network interface that starts with the name “vlan”. That shouldn't be needed except for people who are using some advanced network designs that utilize VLANs, and even then it might not be needed.

In theory, the recommendation is to type the name of the network card that still needs to be configured. However, if there is only one detected physical network card, then the default is usually perfect. (The first time the prompt is seen, the default is to choose the first unconfigured network card. If the installation program shows the prompt again, the default may be “done”.)

If the (not recommended) decision being made is to just skip network configuration, then type “done” before pressing Enter.

When configuring a network card using the installation program, a series of questions will be asked.

IPv4 configuration

IPv4 address for if0 (or 'dhcp' or 'none') [dhcp]

Recommendation

Go ahead and press Enter.

Expected results on a network that functions correctly

To keep things a bit briefer, the documentation of successful results have been merged with the next example (which shows results on a network that does not function correctly). The only real difference is that, on a non-broken network, the messages that start with the word “Unexpected” would simply not appear.

Example results on a network that does not function correctly

Following is what the output looked like on a broken network.

Issuing hostname-associated DHCP request for if0. DHCPDISCOVER on if0 to 255.255.255.255 port 67 interval 1 DHCPOFFER from 10.0.2.2 (52:55:0a:00:02:02) DHCPREQUEST on if0 to 255.255.255.255 port 67 Unexpected DHCPOFFER from 10.0.2.2  (52:55:0a:00:02:02). State #3. Unexpected DHCPOFFER from 10.0.2.2 (52:55:0a:00:02:02). State #3. Unexpected DHCPOFFER from 10.0.2.2 (52:55:0a:00:02:02). State #3. Unexpected DHCPOFFER from 10.0.2.2 (52:55:0a:00:02:02). State #3. DHCPACK from 10.0.2.2 (52:55:0a:00:02:02) Unexpected DHCPACK from 10.0.2.2 (52:55:0a:00:02:02). State #4 bound to 10.0.2.16 -- renewal in 21600 seconds.

(In this example, the lease is 21600 seconds which is 360 minutes = 6 hours.)

The “Unexpected” messages might indicate packet duplication, which will likely lead to severe network connectivity issues. (This has been known to occur with QEMU systems when using network connections of the socket listen/connect type, and when other systems start up and then stop and start up again. Resolution might involve closing the QEMU machine that acts as the socket listen, which would require also stopping all of the QEMU machines that use socket connect.)

Manual alternative

Instead of selecting dhcp at the above prompt, another option would be to just type in an IPv4 address. If so, then the subnet mask will be asked for. An example is shown:

IPv4 address for if0 (or 'dhcp' or 'none') [dhcp] 192.0.2.100 Netmask? [255.255.255.0]

IPv6 configuration

IPv6 address for if0 (or 'rtsol' or 'none') [none]

The recommended answer at this point is to type rtsol and press Enter.

If rtsol worked

Ideally, that will be the end of the IPv6 configuration. (No real output is displayed. However, if install is re-run, the default may show as an IPv6 address, rather than [none]. What is actually stored in the configuration file, though, is simply rtsol)

Example of a problem

IPv6 address for if0 (or 'rtsol' or 'none') [none] if0: DAD detected duplicate IPv6 address 2001:db8::5054:00ff:fe12:3416: NS in/out=6/1, NA in=0 if0: DAD complete for 2001:db8::5054:00ff:fe12:3416 - duplicate found if0: manual intervention required

Ugh... when this example was documented, there was more indication that networking is not functioning as desired. Those kernel messages should not appear.

An alternative approach: manual configuration

If an IPv6 adress was typed in, then another question will be asked.

IPv6 prefix length for if0? [64]

Using 64 is the most common recommendation. (Go ahead and press Enter to accept that default.)

Repeating the process (if applicable)

After configuring both IPv4 and IPv6, the installer will then ask again what network cards to use. After the first successful configuration, the default will be “done”. However, this is not necessarily the best default. If there are any additional non-VLAN network cards that have not been configured yet (e.g. if there is if0 and if1 and vlan0, and if if0 is the only one that has been configured), go ahead and type in the name of the next non-VLAN network interface that is not configured yet.

When configuring the other network cards, if in doubt, just try using dhcp and rtsol. (Doing so is more likely to cause good things, rather than substantial harm, to happen. The worst likely case is that this causes about a half minute delay. The best case scenario is that it causes networking to fully function.)

If a more complicated setup is required

This is generally not necessary, but can be handy to know in some circumstances.

If a command prompt would be helpful (perhaps to try setting up an IP address manually and then running ping), remember that there is an option to type ! (and then Enter) to get to a command prompt. Doing this will allow access to the /tmp/hostname.* file that has been created (and which will eventually, later, be installed to a /etc/hostname.* file, on the filesystem where the operating system will get installed to).

When all of the non-VLAN network interfaces have been sufficiently configured, selecting “done” (which will be the default, if at least one NIC has been configured) will proceed. That may be the default, as shown below.

Available network interfaces are: if0 vlan0. Which one do you wish to configure? (or 'done') [done]

Additional network settings

Basic routing (default gateway)

IPv6 routing

This question does not seem to get asked. (!?!)

IPv4 routing

Default IPv4 route? (IPv4 address, 'dhcp', or 'none')

If a known static address is available, use that. Otherwise, commonly the best answer will be dhcp (so, go ahead and type that).

Default IPv4 route? (IPv4 address, 'dhcp', or 'none') dhcp

DNS domain name

The installation program may display a message such as:

Using DNS domainname example.net

If so, the name may have come from IPv4 DHCP.

If the installation program didn't automatically detect, then a DNS domain name may be prompted.

DNS domain name? (e.g. 'bar.com') [my.domain]

Go ahead and type in an appropriate host name. (If this is part of a classroom-type environment, see if the instructor has provided any directions about what host name to use, or find out whether the instructor has any specific instructions. Naming a computer after a person may be sensible, in such cases. Otherwise, for some pointers on selecting a host name, consider commonly used DNS names for some standard names. If none of those names sound most descriptive, simply choose a sensible name that describes how the machine will be used: the section on naming guidelines may have some helpful pointers.)

DNS domain name? (e.g. 'bar.com') [my.domain] example.net

DNS nameservers

The installation program may display a message such as:

Using DNS nameservers at 10.0.2.4 10.0.2.5 8.8.8.8

If so, the addresses came from /tmp/resolv.conf* files which likely got data put there earlier when the IPv4 DHCP client ran.

Otherwise, a prompt like this may show:

DNS nameservers? (IP address list or 'none') [none]

The address list should be a space-separated list of DNS nameservers. e.g.

DNS nameservers? (IP address list or 'none') [none] 8.8.8.8 8.8.4.4 208.67.222.222 208.67.220.220 4.2.2.2 4.2.2.1 4.2.2.3 4.2.2.4 4.2.2.5 4.2.2.6

If prompted, and if an internal DNS server is not available, then using a publicly known, publicly accessible usable DNS server (or multiple, specified separated by spaces) will likely work out fairly well in the short term.

YABL

Yet another blank line. Please prepare to feel enlightened by the supreme intelligence of the text that is about to be quoted from the installation script's output:

Whee! (Again!)

Root account password

Password for root account? (will not echo) (invisible-user-typed-password) Password for root account? (again) (invisible-user-typed-password)

If the post-installation security guide suggestions are followed, then this password might not be used for very long. It can be re-enabled by booting to single user mode. Some further details about password recovery are provided by OpenBSD FAQ 8: “General Questions”: section on a lost root password (section 8.1).

Some configuration flags

Specifying services to start

Start sshd(8) by default? [yes]

In most cases, this is a great default. (Press Enter for this question.)

For the next question, the default is not recommended.

Start ntpd(8) by default? [no]

What a terrible default. Press y and then press Enter. (Note: If this question was accidentally answered as “no”, then that will not be a major problem. Answering the question incorrectly simply means that NTP should be manually set up later, which should be simpler than re-starting the whole installation process.

Start ntpd(8) by default? [no] y

NTP server? (hostname or 'default') [default]

If the question about an NTP server comes up, press Enter.

Do you expect to run the X Window System? [yes]

If in doubt, the more convenient answer is generally “yes”. OpenBSD FAQ 11: Configuring X says, “There are security implications to this, so do not do this if you do not need it.” However, the security implications seem to be related to how logged in users might interact with the video card and/or PCI configuration registers. This does not introduce any noteworthy network security vulnerabilities. For those wanting to know more about this setting, section OpenBSD FAQ 8: Section about X (section 8.2: “X won't start, I get lots of error messages”) also discusses this a tiny bit, including how to change this setting later (although the FAQ might not be mention requiring a reboot to make the change actually be effective).

Do you want the X Window System to be started by xdm(1)? [no]

Ultimately, this is rather a matter of preference. For those who would like a traditional (text-based) login, use the default answer of “no”. (Selecting “no” is likely a more standard/common setup, which will likely make following other guides easier.)

Change the default console to com0? [no]

This question could often be rephrased as follows: Do you want to be blind?

Generally, “no” is preferred. (So, press Enter to accept the default.)

Admittedly, that sounds silly, so here's the details. The question is asking whether to change the default I/O from keyboard/monitor to the first COM port. (The phrase “COM1” here refers to traditional BIOS-style (DOS-style) names for COM ports. Some Unix/BSD standards specify to name these off of a zero-based count, so BSD's com0 is the BIOS's COM1.) For those who are familiar enough with older computer technology, this refers to using the DE-9 (often called DB-9) serial port for input and output, instead of using the keyboard for input and the monitor for output. Apparently using such a serial port can be nice when interacting with the operating system using debugging software. (A modern day approach, which might often provide many of the same benefits but without needing to use old and slow hardware, may involve using virtual machines.)

User setup

Setup a user? (enter a lower-case loginname, or 'no') [no]

Non-acceptable answers

Here are some documented examples of what happens in response to some answers. (For a normal installation, there is no need to enter these non-acceptable answers. This text is simply describing what happens if that gets tried.)

Setup a user? (enter a lower-case loginname, or 'no') [no] yes No really, what is the lower-case loginname, or 'no'? [no] root root is not a useable loginname. No really, what is the lower-case loginname, or 'no'? [no]

([sic]? Should that be usable? Or, did that spelling error show up just because somehow this got documented incorrectly?)

Typing “yes” causes the prompt to change. Typing “root” displays an error message, and then displays the previous prompt (unchanged from whatever it looked like before).

Go ahead and type in a real username. If the administration is going to be done using a team of people, then use an account name that the group will be familiar with. (Examples: admin or sysadmin or sysad or netadmin.) Otherwise, a generally sensible rule is to name the account after the person who will be using the account.

Setup a user? (enter a lower-case loginname, or 'no') [no] baseuser

Then, the system will ask for a “Full user name”.

Setup a user? (enter a lower-case loginname, or 'no') [no] baseuser Full user name for baseuser? [baseuser] Base User

For the “Full user name”, type in a name that can be displayed. If the account is meant for an automated process, put in appropriate name related to what the account will be used for. If the account is meant for a person who is part of a formal organization, then the most common answer will be the person's full name (commonly a first name, and also a middle name if available and desirable, and also a last name).

After that will be a couple of password prompts.

Password for baseuser account? (will not echo) (invisible-user-typed-password-someBigSecretNobodyKnows) Password for baseuser account? (again) (invisible-user-typed-password-someBigSecretNobodyKnows)

Type in a password twice. (Your typing will not be echoed to the monitor, meaning that the typed letters will not show up on the screen.)

Then, the next question is great for security. (Say Yes!)

Since you set up a user, disable sshd(8) logins to root? [yes]

[#obtimznq]:

Time zone

What timezone are you in? ('?' for list) [PST8PDT]

In the above example, PST8PDT was the default. This is believed to not always be the case, and so perhaps the default came from something detected by DHCP over IPv4 or by system BIOS/CMOS settings?

Entering a question mark will show a list of time zones. Example output:

What timezone are you in? ('?' for list) [PST8PDT] ? Africa/      Chile/       GB-Eire      Israel       NZ-CHAT      UCT America/     Cuba         GMT          Jamaica      Navajo       US/ Antarctica/  EET          GMT+0        Japan        PRC          UTC Arctic/      EST          GMT-0        Kwajalein    PST8PDT      Universal Asia/        EST5EDT      GMT0         Libya        Pacific/     W-SU Atlantic/    Egypt        Greenwich    MET          Poland       WET Australia/   Eire         HST          MST          Portugal     Zulu Brazil/      Etc/         Hongkong     MST7MDT      ROC          posix/ CET          Europe/      Iceland      Mexico/      ROK          posixrules CST6CDT      Factory      Indian/      Mideast/     Singapore    right/ Canada/      GB           Iran         NZ           Turkey What timezone are you in? ('?' for list) [PST8PDT]

One option, sensible for Americans, is to type US/

What timezone are you in? ('?' for list) [PST8PDT] US/ What sub-timezone of 'US' are you in? ('?' for list) ? Alaska          Central         Hawaii          Mountain        Samoa Aleutian        East-Indiana    Indiana-Starke  Pacific Arizona         Eastern         Michigan        Pacific-New What sub-timezone of 'US' are you in? ('?' for list) .. 'US/..' is not a valid timezone on this system. What timezone are you in? ('?' for list) [PST8PDT]

Users living near the west coast of the USA may then want to choose Pacific. (That will end up choosing US/Pacific.)

(These time zones will also be installed to the /usr/share/zoneinfo/ directory. Whichever time zone gets selected here will be the destination of the /etc/localtime symlink. The /usr/share/zoneinfo/Pacific/ directory is different from the /usr/share/zoneinfo/US/Pacific file. This guide currently does not have substantial details regarding the differences between /usr/share/zoneinfo/US/Pacific or /usr/share/zoneinfo/US/Pacific-New or /usr/share/zoneinfo/PST8PDT. Answers might be available from comments in the source files at CVSWeb: OpenBSD: Time Zone files.)

YABL

Yet another blank line. Please prepare to feel enlightened by the supreme intelligence of the text that is about to be quoted.

Whee! (Yet Again!)

Disks

OpenBSD needs to know where to store its data.

Available disks are: sd0. Which disk is the root disk? ('?' for details) [sd0]

To recap (information about detected drives, detecting drives (in BSD)), (E)IDE drives are typically using the wd driver, while drives using AHCI or USB connections typically use the sd driver. So systems using older hardware (or emulating older/simpler hardware) may say “wd0” rather than “sd0”.

Use DUIDs rather than device names in fstab? [yes]

Yes, using DUIDs (Drive/Disk Unique Identifiers) is nice. There is little to no compelling reason to not use the newer standard. Using DUIDs may allow the drive to be loadable even if the device connects with a different driver. Other than destroying some backwards compatability, there's little downside. And older operating systems that don't support DUIDs are not likely to be using the newer fstab file.

Primary system disk layout

If the system is using a hard drive that is 2TB or smaller, then the traditional standard is to use the MBR format. (Jump to the directions about using the MBR format.)

Newer systems may be using (U)EFI and expect to find hard drives using a GPT layout. (This is particularly likely if a single hard drive exceeds 2TB in size.)

GPT (GUID Partition Table)

These notes...

...are a bit old. Most of what is written in this GPT section was written before things like GPT support being worked on, GSOC 2014 (OpenBSD Foundation GSOC 2014, GSOC 2014 GPT code updates

For now, the course of action that is simplest is to use a disk that is 2TB or smaller, and use MBR. For people using a virtual machine, that simply means that the virtual machine's disk needs to be smaller than 2TB, not necessarily that the physical machine's partitions need to be that small.

These directions should be reviewed, as an update may be in order. In the meantime, larger disks have been able to be used, although some software might not be completely designed for such disks (so sizes might not be reported as one may think).

Overview of support (conceptual)

Theo de Raadt, the leader of the OpenBSD project, has stated that the GPT layout is fairly useless (not really providing significant benefits compared to other options for handling large disks... Forum post shows some of this discussion). GPT has been related to (U)EFI, which has been identified as being worse than useless: rather, (U)EFI may be harmful to positive software projects. The end results is that these technologies have not been getting any endorsements, or quick functional support, by the OpenBSD developers. OpenBSD Misc: post on 3TB support shows Theo's commentary.

OpenBSD is capable of using the large drives simply by ignoring the limitations imposed by the MBR.

Presumably the MBR should show a 2TB image with an MBR Partition Type Identifier of 0xEE. However, how OpenBSD handles that has not been heavily documented here yet... At the time of this writing, Wikipedia's article on “GUID Partition Table”: “Unix-class operating systems” lists support by FreeBSD 7.0, but does not mention OpenBSD as one of the supporting platforms.

Post on GPT support indicates an interest in code for GPT. However, that post is dated 2009, and the newer 2012 post about 3TB drives indicate less interest in getting such support added.

How to proceed

The upcoming section called “Handling the boot record (MBR) data” has information about how to use the “ fdisk -e ” command. Go ahead and use that command for what it can be helpful with, which is generally any partition boundary that exists within the first two TB. For example, if a 3 TB partition is made, and this 3TB drive starts at the beginning of the drive (or just one track from the start), then the starting boundary exists within the first two TB. So, the starting boundary may be useful, even though the ending boundary is past the first two TB.

Describing the example further

For example, if the OpenBSD partition should start near the front of a 3 TB disk, and use the entire 3 TB disk, then go ahead and use the “ fdisk -e ” program to create an MBR partition. The resulting MBR partition might only be 1 TB large, because of the mathematical effects of using modulo 2. (Modulo is the same thing as figuring out the “remainder” of a division problem, so 3 % 2 = 1.) So the partition created by “ fdisk -e ” might be much smaller than desired. So, in this example, the end of the partition is not something that “ fdisk -e ” helps to usefully specify.

However, in the above example, the “ fdisk -e ” program may successfully start the partition at the start of the second head/track of the hard drive. This is a generally recommended practice (as noted by OpenBSD Manual page for fdisk: “Caveats” section). Using “ fdisk -e ”'s CHS entry mode can help this to be done fairly easily. So, the start of the partition is something that “ fdisk -e ” can help to specify, successfully and usefully.

A drive that exists at least partially outside of the first 2 TB might not be fully handled properly by fdisk -e command. If OpenBSD is the only operating system that will be accessing data at the end of the first two TB, and OpenBSD is the only operating system that will be accessing data after the first 2 TB, then the general recommendation is to just not worry too much about fdisk -e providing just partial support for the drive. If other operating systems are also being used, then safely creating a layout that is also usable by other operating systems may be... more challenging. (The key will be to figure out how every operating system locates a position on the drive, and making sure that there is no overlap of any of the used sections of the drive. This may require some research, or perhaps even some safely-performed experimentation.)

[#obmkmbrp]: Handling the boot record (MBR) data

Traditionally, OpenBSD/i386 has been using the MBR layout (and probably still does), and for a while OpenBSD/amd64 has as well. For maximum compatibility and least surprises, properly handling the MBR data is recommended if the system is 2TB or less.

Use (W)hole disk, use the (O)penBSD area, or (E)dit the MBR? [OpenBSD]

Quite commonly, drives have not been pre-partitioned to support OpenBSD before running OpenBSD's install program. In that case, the middle option might simply just not show up. In that case, the prompt may look more like this:

Use (W)hole disk or (E)dit the MBR? [whole]

If available (because of a pre-defined setup), and if there are no issues with the setup (such as not having a needed boot signature), then choosing the default of “O” (for “use the (O)penBSD area”) is preferred. However, that will not be an option on a new/blank disk.

The non-default, “(E)dit the MBR”, is generally preferable. (This is true for physical disks, or an overly-large growable (“copy-on-write”/“dynamically expanding”) disk on a virtual machine.) Using only part of the disk will generally provide more flexibility on how else the disk may be used.

“(E)dit the MBR”

This is recommended.

Initial actions

A screen of information will rapidly show. (The next little bit of details are simply informational, documenting what happens, and are not requiring action.)

[#obfdstdo]: Displayed Instructions (what to do)

Upon choosing to (E)dit the MBR, some instructions will be displayed:

You will now create a single MBR partition to contain your OpenBSD data. This partition must have an id of 'A6'; must *NOT* overlap other partitions; and must be marked as the only active partition. Inside the fdisk command, the 'manual' command describes all the fdisk commands in detail.

Showing the partition table

The installation program then runs “fdisk ” on the specified drive (e.g. “ fdisk sd0 ”), which displays out the partition table.

The exact details of the displayed partition table may vary on different computer systems (although they might be identical if the hard drives are the same size, and if the drives were configured identically). Following is an example of what the partition table looks like on a blank 16GB drive looks like. (This was from a virtual machine, so the drive was exactly 16GB.)

D i sk:  wd0        g eome try : 2088 /255 /63  [3319 55432 Sect ors] O f fset : 0        S igna tur e: 0x0               S tart ing           E ndin g           LBA Info:   # : id       C    H    S  -       C    H    S  [        start:         size  ] - - ---- ------- ---- ---- --- ------ ---- ---- ----- ---------- ------------ -- ------------   0 : 00       0    0    1  -       0    0    0  [            0:            0  ]  unused   1 : 00       0    0    1  -       0    0    0  [            0:            0  ]  unused   2 : 00       0    0    1  -       0    0    0  [            0:            0  ]  unused   3 : 00       0    0    1  -       0    0    0  [            0:            0  ]  unused

The partition editor is run

The installation program then runs “ fdisk -e ” on the specified drive. A prompt will then be displayed.

fdisk: 1>

A basic introduction to this fdisk program

This program can be highly destructive of data. Be careful!

The prompt has a space after “fdisk:”. Later that space may (and probably will) turn into an asterisk. The asterisk will simply mean that there are unsaved changes.

The number in the prompt refers to how many levels of bootblocks are being used. That number may change if the select command gets used. If an “extended partition” setup is not being used, then the select command will not get used. Many modern users will not be seeing that number ever change.

Any time the main “fdisk: prompt is showing, the currently-editing bootblock can be viewed by using the p command. Go ahead and try out that harmless command.

Other commands that should be fairly harmless include exit (which stops editing the current bootblock) or abort. If the number in the “fdisk:” prompt is simply the number 1, then those two commands do the same thing. These commands cause the ”fdisk -e” program to end without saving changes.

When ”fdisk -e” gets run from within the OpenBSD installation program, the installation program often ends up getting into a bit of a loop until the disk is set up properly, or at least partially properly. If some horrendous error is made in fdisk, one option may be to exit/abort WITHOUT saving, and then also exit the disklabel command. What often happens, in such a case, is that the installer will then allow (and might rather insist upon) an opportunity to edit the disk (again).

[#obsfdsrq]: The goals to achieve in fdisk

A thoroughly unprepared disk (such as a blank disk) has three or four issues that need to be addressed before installing OpenBSD. Three of these issues are visible in the example partition table of a blank drive. The three issues are:

• First, the drive's “magic” boot signature is not set to 0x55AA (which is often reported as 0xAA55; generally 0xAA55 indicates a fine value for the “magic” boot signature). (Instead, this example shows a pre-existing value of 0x0 which is unacceptable for a drive that needs to boot.)
• Second, none of the partitions use an MBR Partition Type Identifier (listed in the id field) of A6.
• Third, there is not an asterisk next to a partition that says A6. (The asterisk represents which partition is marked with the partition bootable flag.)
• The last issue is to make sure the MBR's boot code is valid.

OpenBSD FAQ 4: “Installation Guide”: section on “Setting up disks” (FAQ 4.5.3) describes the requirements that a boot “drive has a valid MBR, a valid signature, an OpenBSD partition, and a partition flagged as "active".” Now, the bit about having a valid MBR generally ought to be resolved by the installation process when the other three issues are sufficiently taken care of.

Here is an example of a partition report that has all of those problems fixed. This report came from an actual physical drive that was about a TB in size.

fdisk: 1> p D i sk:  sd0        g eome try : 1216 01/2 55/6 3 [19 53525168 S ectors] O f fset : 0        S igna tur e: 0xA A55               S tart ing           E ndin g           LBA Info:   # : id       C    H    S  -       C    H    S  [        start:         size  ] - - ---- ------- ---- ---- --- ------ ---- ---- ----- ---------- ------------ -- ------------ * 0 : A6   16710    0    1  -   33419   85   16  [    268446150:    268435456  ]  OpenBSD   1 : 82   34919    0    1  -   38052    0    3  [    560973735:     50331648  ]  Linux swap   2 : 83   38053    0    1  -   54762   85   16  [    611321445:    268435456  ]  Linux files*   3 : 83   54764    0    1  -  121600  254   63  [    879783660:   1073736405  ]  Linux files* fdisk: 1>

This example drive layout successfully meets all three of the previously-stated needed criteria. Looking at the partition report of the blank drive, and then this more recent partition report, will show that all three of the problems exist on a blank drive, and all three of those issues look better in the report from the 1TB drive.

Further understanding of the displayed partition information

Understaning all of the output of an fdisk partition layout might be beyond what is typically necessary for an installation, but know that those numbers can be understood by a properly trained technician. A description of those numbers are available: see OpenBSD example fdisk partition report for details.

What to do in the partition editor

The following steps will help to achieve all of the desired goals.

Ensuring there is an A6 partition

Determine a partition number to use

There are four partitions. (The reason there are four partitions is that four partition records can fit in a standard partition table, as noted by MBR Disk details describing bytes 447-510 of an MBR. Suffice it to say that supporting more primary partitions is considered to be unstandard. However, for those wishing to learn more about the concept of trying to support additional partitions, that topic is discussed in the description of earlier bytes in the MBR.) Each of these four partitions are represented by a row of the partition table. (In this fdisk program, the partitions are numbered partition zero, partition one, partition 2, and partition 3.)

The column labelled “id” shows the MBR Partition Type Identifier value.

If there is at least one partition that uses a partition type value of 00 (in which case the last column will say “unused), that is probably a good partition to use. (The main reason it might not be a good partition number to use is if there are other partitions, and if the space is not large enough. If that happens, an error message is likely.)

If there is not a partition with type 00, then an existing partition will need to be recycled. This will mean an entire partition of data will be lost! Make sure that such data loss is acceptable before proceeding! In a structured/guided (e.g. classroom) lab environment, check for directions, or check with the instructor of the course, to see which partition should have all of its data be removed.

Making the A6 partition

Edit a partition. For example, if partition #0 is going to be modified, specify that.

fdisk: 1> edit 0

The “fdisk -e” program will then display the current information about the partition that is going to be modifed.

S tart ing           E ndin g           LBA Info:   # : id       C    H    S  -       C    H    S  [        start:         size  ]

Next, the “fdisk -e” program will ask which partition type to use. e.g.:

Partition id ('0' to disable) [0 - FF]: [0] (? for help)

(The number in the brackets represents the default, and is simply whatever the partition type has been (before running the edit command in fdisk).)

Optional and recommended: go ahead and enter ? to see the help. A whole screen of partition types will appear.

Partition id ('0' to disable) [0 - FF]: [0] (? for help) ?

Entering the “?” will output the partition table. (See: partition types displayed by OpenBSD's fdisk command for an online copy of that list.) After displaying the list, the same prompt is shown again.

As shown in the chart of partition types, a value of A6 is used to represent OpenBSD. Some directions, shown before fdisk was run, stated that a partition needs to be set to the value of A6. So, go ahead and specify a desired value of A6.

Partition id ('0' to disable) [0 - FF]: [0] (? for help) A6 Do you wish to edit in CHS mode? [n]

At this point, OpenBSD needs to know where to start the partition, and where to end the partition. The easy way to do this is likely to NOT use CHS mode, then accept the detected offset, and to specify a size. The following example shows this.

Partition offset: [0]

The default partition offset may typically work fine.

Partition size: [0]

If the partition type was something other than zero, chances are quite high that a reasonable partition size may have been specified. For a partition that was using partition type zero, the default partition size starts out with a pretty worthless default (a size of zero). The default size is simply to make no change, which is rather senseless when the initial default size is zero bytes.

If there is a desired amount of space to use, go ahead and type that in the amount of space to use. (The upcoming example shows what this looks like to specify a 12 gigabyte partition.) Alternatively, a size of * can be specified to use up most of the remaining space. (That's right: “most” of the remaining space. For some reason, experience has shown * seems to jump to the last cylinder, but not use all of the heads/tracks or sectors of the last head/track that does get used.)

Partition size: [0] 12G

Checking for overlap

This step probably should not be necessary, but is still worthwhile! Knowing about any problems with the layout, and fixing them now, will be much easier than dealing with the problems later. If there are overlapping partitions, the result is likely to be data corruption/loss (which might not be detected early on). Furthermore, if such a problem exists, the cause of the problem can be fairly challenging to figure out. So, make sure this is taken care of!

To do this, first, print out the partition table.

fdisk:*1> p

Ignore any partitions that are using a partition type of 00 (under the column labelled “id”). In all other cases, make sure that the starting Cylinder (shown under the “Starting” section, and then under the C column) shows up AFTER the Ending cylinder of the previous partition (which shows up under the the “Ending” section, and then under the C column).

(Actually, that's not absolutely strictly necessary for things to function. If the cylinder is equal, but the head is greater on the later partition, that should also work okay. Or, if the cylinder and the head are both equal, and the sector is greater on the later partition, then that should work okay. However, even if such a thing “should work”, there may be some compatibility and/or speed benefits to starting partitions on the start of a cylinder. So, to achieve those benefits, the starting cylinder should be on a later cylinder than what a previous partition uses.)

Saving changes so far

If everything looks good, and so recent actions will not have caused unwanted data loss, and there is no overlap to the partitions, then go ahead and save the changes made so far.

fdisk:*1> write fdisk: 1>

Selecting bootable

After a partition is set to A6, mark it as bootable.

fdisk: 1> flag 0 Partition 0 marked active. fdisk:*1> p

The partition that is flagged as bootable should have an asterisk to the left of the partition/row number.

Updating the boot signature

Note: This seems to have an affect on the drive's auto-layout. It may be interesting (from an educational/experimental vantage point) to actually try skipping this step for the moment. However, this does need to be done prior to installation. The easiest time to do this will be before newfs formats the filesystems, and before installing disk sets. So try to avoid saying “done” on configuring disks, until this is done.

fdisk: 1> update

This may also place OpenBSD's boot code onto the MBR, overwriting any other boot code that may exist. (That can be a great thing if the boot code is not working properly. That may be less desirable if there is other, working, preferred (perhaps customized) boot code there.) OpenBSD FAQ 13: “Using Drive: 0 Partition 3” error, archived by the Wayback Machine @ Archive.org stated, “The only time the OpenBSD loader is installed on your system during a normal install is when you say 'Y' to the 'Use entire disk for OpenBSD' question. If you answer 'N' and manually create the OpenBSD disk partition, it will not replace the boot loader unless you use the 'reinit' or 'update' commands of fdisk.”

Reviewing the partition report

Check the output for the following things: is the boot code showing the proper drive's “magic” boot signature? (If the drive is going to be used for initial booting, then it should be 0x55AA which may be reported as 0xAA55.) Is a partition flagged as active (by having an asterisk next to the partition number?) Is there a partition with an MBR Partition Type Identifier of A6?

If the drive is over two terabytes, then make a conveniently-accessible record (by typing on another available computer/device, or writing down) any of the numbers that are both in the LBA Info section and also are larger than 2,147,483,647. The reason for this is that disklabel may need some manual adjustments, so tasks will be easier if some of these numbers available. (This is not necessary if none of the partitions go past the 2 TB mark, because disklabel will likely handle things fine for those smaller drive layouts. Typically the last sector that disklabel would properly dtect would be sector number 2,147,483,647.) If the operating system has not been fully installed, then there may be fairly limited or non-existing support for multiple terminals and scrollback. This may be worked around by exiting disk editing programs (without saving) and shelling to a command prompt, although that is often not anywhere close to being convenient.

Quit

Either:

• quit
• or write and then exit
• or write and then abort.

If the (W)hole disk is chosen

(Note that this guide is not recommending using the (W)hole disk option. This documentation is simply covering the topic for the sake of thoroughness and completeness.)

Specifying the “(W)hole disk” option will overwrite any other data (including other partitions) that may be stored on the disk. That can be more destructive, removing all partitions. Also, this doesn't allow as much easy flexibility to use certain types of data layout configurations, such as having multiple filesystem types or multiple operating systems (possibly even multiple versions of the same operating system). The most common reason may be to support Dual Boot (involving OpenBSD).

Such disk layouts actions might often be unnecessary. People with access to multiple computers will often recommend just dedicating a whole computer to an operating system, and avoid unnecessary complexity of trying to handle multi-boot. (For instance, post indicating the claim that a “normal user does not install multiple operating systems on a single disk.”

However, even if there is no immediate foreseen need to use complex booting configuration, often there is also very little reason to unncessarily limit such flexibility. If the space doesn't need to be allocated, simply don't allocate it. (There may also be some other arguments on why it can be nice to not unnecessarily allocate space. Perhaps see: disk layout: partition size.)

OpenBSD FAQ 4: “Installation Guide”: section on “Setting up disks” notes that if a user does not take care of some “things using the "Use whole disk" option, you need to make sure they get done manually.” So this implies that the “(W)hole disk” option may be quicker, with fewer steps. This is actually true, at the cost that the entire system will get devoted to using OpenBSD's MBR partition. However, manually editing the partition table shouldn't take very long for someone who is well practiced.

(If “(W)hole disk” is selected, the installer will note “Setting OpenBSD MBR partition to whole wd0...done.”) This is typically unnecessary and may reduce the amount of easy flexibility that is available.

Handling the disk layout that BSD will primarily use

For most operations, the BSD operating systems really don't pay much attention to the MBR. Instead, they pay attention to a disk layout called the BSD disklabel, also known as a “bsdlabel”. An MBR partition boundary does have an effect because, by default, the BSD disklabel does use the MBR partition as boundaries. However, other than that one detail, the operating system really does not pay significant attention to the MBR partition. To effectively run BSD, a BSD disklabel needs to be created.

Modern versions of OpenBSD will recommend a default layout. Oddly, some testing indicated that the recommended layout does get heavily impacted by the drive's signature.

[#obnombr]: Example auto disk layout (of a blank disk)

It seems that a blank disk may have a more detailed (and, arguably, sensible) layout than a disk with the “magic” boot signature. For example, here is what a 16GB disk may look like:

The auto-allocated layout for wd0 is: #                size           offset  fstype [fsize bsize  cpg]   a:           540.8M                0  4.2BSD   2048 16384    1 # /   b:           510.0M          1107552    swap   c:         16384.0M                0  unused   d:           857.3M          2152000  4.2BSD   2048 16384    1 # /tmp   e:          1278.1M          3907680  4.2BSD   2048 16384    1 # /var   f:          1360.8M          6525152  4.2BSD   2048 16384    1 # /usr   g:           788.5M          9312064  4.2BSD   2048 16384    1 # /usr/X11R6   h:          2969.6M         10926848  4.2BSD   2048 16384    1 # /usr/local   i:          1208.3M         17008576  4.2BSD   2048 16384    1 # /usr/src   j:          1668.6M         19483200  4.2BSD   2048 16384    1 # /usr/obj   k:          5202.0M         22900544  4.2BSD   2048 16384    1 # /home

And, here's what the auto-layout on a 127.5GB disk looks like:

The auto-allocated layout for wd0 is: #                size           offset  fstype [fsize bsize  cpg]   a:          1024.0M               64  4.2BSD   2048 16384    1 # /   b:           510.0M          2097216    swap   c:        160560.0M                0  unused   d:          4096.0M          3141664  4.2BSD   2048 16384    1 # /tmp   e:          4606.0M         11530272  4.2BSD   2048 16384    1 # /var   f:          2048.0M         20963328  4.2BSD   2048 16384    1 # /usr   g:          1024.0M         25157632  4.2BSD   2048 16384    1 # /usr/X11R6   h:         10240.0M         27254784  4.2BSD   2048 16384    1 # /usr/local   i:          2048.0M         48226304  4.2BSD   2048 16384    1 # /usr/src   j:          2048.0M         52420608  4.2BSD   2048 16384    1 # /usr/obj   k:        102915.5M         56614912  4.2BSD   2048 16384    1 # /home

Some side notes about disklabel's report

In OpenBSD, c: is special. (It refers to the entire disk. It is believed that there is a similar drive/partition letter in NetBSD or FreeBSD, or both.)

What is commonly found is that, ignoring that one drive letter that represents the entire disk, most of the numbers in the offset column are equal to a previous offset plus a previous size. The offsets are based on sectors, which are half-kilobytes. As an example, in the previous text showing the 16GB disk, i: starts at 17,008,576. Subtracting the previous offset of 10,926,848 leaves a difference between 6,081,728 sectors. Each sector is a half kilobyte, so dividing 6,081,728 sectors by two gives 3,040,864 KB. A quick visual inspection will show that 3,040,864 KB is approximately the size of the h:. In fact, 3,040,864 KB divided by 1,024 does indeed result in being 2969.59375 MB. With rounding, that is what disklabel reports.

These disklabel drive letters will combine with the drive's name to create device names. So sd0's b: will become known as the /dev/sd0b device. That is the device name that will be used for mounting.

Choosing to modify the layout

Use (A)uto layout, (E)dit auto layout, or create (C)ustom layout? [a]

The desired answer is most certainly NOT going to be the default of (A)uto layout. (That is simply an opinion of the author of this text. The reason that “(A)uto layout” is so undesirable is because it will generally create a gigantic /home directory. As described later, that ends up being undesirable.)

In general, “(E)dit auto layout” is a desirable choice. Here is a summary of what each option means.

(A)uto layout

If the default is chosen (pressing a and pressing Enter, or just pressing Enter to choose the default), then the user is not asked for any further changes about the filesystem layout. (The install program will then proceed to run newfs in order to start creating the formatted filesystem volumes.)

(E)dit auto layout

This writes the proposed BSD disklabel (bsdlabel, disk layout) to the disk. It then edits the layout (like running disklabel -e on the drive), which is like writing the proposed auto layout to the bsdlabel and then selecting the “create (C)ustom layout” option.

create (C)ustom layout

This proceeds to edit whatever BSD disklabel (“bsdlabel”) already exists on the disk. On a previously-unused disk, this means starting out with a blank BSD disklabel.

To re-iterate, the most desirable choice will often be “(E)dit auto layout”. That helps to provide the security benefits that are available from a fairly complex BSD disklabel (“bsdlabel”), but creates that quickly so the user has less work to do.

Recommended changes to perform in disklabel

Brief overview

(These overview details are probably unnecessary, but are provided for reference.)

Entering “expert mode” (with the “X” command) may provide more options when modifying partitions. Saving to a file will generally be good, except that saving the resulting file might be quite challenging to do if disklabel is being run from the operating system's installation process. So, don't worry about it in that case. All BSD disklabel (bsdlabel) partitions must reside within the boundary. To see the boundary, use the l (for "list header") command, and see the “boundstart” and “boundend” sector numbers. By default, this boundary ends up being based on the A6 partition. If the boundary is somehow set too low, then changing it will generally be non-problematic as long as the boundary is contained within the A6 partition. This means that boundstart is not less than the “start“ column that fdisk reports for the A6 partition, and “boundend” does not go past the end sector which can be calculated by viewing the data from disk and adding the size to the start.

Setting the boundaries

This may or may not be something that should be done, depending on the size of the hard drive being used. If the size of the drive is unknown, type type l to list. If the number of bytes/sectors is 512 (which is most common), and if there are more than 2,147,483,648 (2^³¹) sectors, then the drive is over 2 TB.

For a drive that is under 2TB

On a drive that is 2TB or less, the MBR data should be properly set. On such a drive, the boundaries are generally fine, and don't need any adjustment.

For a drive that is over 2TB

Ahh... now's the tough part.

As noted by OpenBSD Misc mailing list: post on “Large (3TB) HDD support”, “You generally don't want your OpenBSD partitions living outside the OpenBSD MBR (fdisk) partition.
   EXCEPT when the MBR isn't providing useful info.  Like” what is encountered with drives that are over 2TB. When a drive is over 2TB, then limiting the disklabel to the MBR partition may generally be undesirable.

Note: This guide was written based on some reading, and some solid understanding of where data gets stored on a disk. However, it was not initially written based on experience handling such drives. For the moment, consider the use of such large drives to be requiring substantial care. (It might be best to think of this as “experimental”.)

Typically, before making any adjustments on the individual bsdlabel entries (“disklabel partitions”), the first thing that needs to be done is to adjust the “boundaries”. To see the current boundaries, type p. The boundaries are shown in the section identified as being the “OpenBSD area”. Or, type l to list, and see the “boundstart” and “boundend” lines.

Anticipate to change the boundaries. Note, however, that if the boundaries overlap with any portion of the disk that gets used by another operating system, then data corruption is often a likely result. These types of processes can be quite easy to make errors, and the errors can result in data-losing problems that can be challenging to identify.

Enter the b
command to edit boundaries.

> b Starting sector: [2147483647]

If the OpenBSD partition actually starts somewhere before the 2TB mark (usually sector 2147483647), then the starting sector probably requires no adjustment. (If OpenBSD is installed onto the very first partition, the default starting number might often be very low. The default starting number might be zero or, more likely, a cylinder above zero.) In that common case, just push Enter. The best way to determine the proper number for this is probably to look at the starting sector reported by fdisk. If the number being displayed is not accurate, then make sure to type in the accurate number before pressing Enter. The main requirement for this number is that it should not be within the boundaries of any partition other than the OpenBSD partition.

To utilize later parts of the disk, the next question may need a non-default answer.

> b Size ('*' for entire disk): [3221225472]

If the OpenBSD partition is the last partition on the disk

(This will be the case when OpenBSD's partition is the only partition on the disk.)

Type * and then push Enter.

> b Size ('*' for entire disk): [3221225472] *

This should automatically specify to go all the way up to the very last sector of the disk.

When there are later partitions

Care needs to be done to make sure that the OpenBSD area does not overlap with any later partitions. Figure out the sector number of the partition that comes after OpenBSD. (This is the start column of fdisk's output.) Then make sure to use a number which is less than the starting position of that later partition. (Being just one less is acceptable and is probably ideal.)

Adjusting these boundaries doesn't really have much direct effect: this simply removes limitations to that other partitions can then use up larger sections of the disk. However, no real substantial effect happens until the partitions actually need to use the expanded area. So, to take advantage of the newly expanded space, the sizes of the partitions will need to be modified.

/home

First of all, if using an automated layout, locate the partition that the OpenBSD installer recommends using for /home and do something better with that partition. One option: delete it. Seriously. The /home folder is meant for user data. In many cases, one megabyte would end up being more than sufficient. (This would be true for many servers that are maintained by administrators who don't need to be storing significant amounts of data for the user accounts that would log into the server. This would be entirely untrue for a system that regularly has many users logging into the system.) Having a larger area for /home is recommended, because, as OpenBSD's FAQ used to say, “We would rather have a few hundred megabytes of unused space than a kilobyte too little.” Still, using up ALL of the remaining space for /home is generally quite extremely excessive, and will cause newfs to take a long time (before the operating system is offering a multitasking user interface). Also, on a dynamically expanding drive (for a virtual machine), this might cause a larger-than-necessary disk image. (That may be speculation, but probably could be true for at least some file formats.) A much better idea is described by OpenBSD FAQ 4: Installation Guide. This installation guide discusses the practice of taking up “all remaining available disk space. With modern monstrously huge drives, this is usually a bad idea. If you know you will never use it, don't allocate it, and save it for some future use.” So, what we have here is that OpenBSD's installation program is not following the OpenBSD project's own advice. Additional discussion on this topic (including more quotes from the OpenBSD project) are in a section of documentation that discusses partition sizes.

If end users are going to be having access to directly using the disk space in /home on this system, either delete the mount point and then add a new one, or just modify the existing mount point.

At the main disklabel prompt, the p command will show the disk layout. The /home mount point is often assigned a drive letter of k: by default, so that is what will be used for example. However, be sure to check rather than just blindly following these examples. Make sure the changes made are being done to the desired partition.

If the mount point for /home is indeed k:, then “m k” can be used as a command to modify that drive. When asked about the location (“offset”), simply using the default is usually a simple answer that will work. (If additional changes are being made, a better answer may be to move the partition so that it is next to whatever other partitions are being used.) Then choose a more reasonable size (such as hundreds of megabytes, or perhaps 2G, but not hundreds of gigabytes).

An alternative method could be to just delete the mount point with “d k” (if the drive is k:). By deleting the special mount point for the /home directory, what will happen is that a /home directory will get created under whatever mount point is used for the parent directory, which will be the top-level / directory. This means that if /home fills up the entire partition, then / will be entirely filled. This is probably a bad idea for a system that has end users logging into the system. However, this probably is not a bad setup if the only people to log into the system (and use space in /home) are going to be network administrators.

In the above example (and many actual cases), /home is using the k: device object. To delete the mount point (in disklabel -e, which is what the installation program has run) type the d k command.

The most essential mount points

There are quite a few mount points, and some of them are typically more crucial than others.

In OpenBSD, and in NetBSD, a specific drive letter will refer to the entire disk. That is unchangable, so just ignore that partition. In OpenBSD, this is the c: BSD disklabel partition.

There absolutely needs to be a drive identified as / in order for the installation to proceed.

If disk space is limited to the point where some mount points look supportable, but not all of them, then here some some of the automatically generated mount points are more useful than others.

The most desired additional directories are /tmp and /var and /usr directories. If disk space allows, provide suitable room for each of those. The example auto-allocated layout of a 120ishGB drive shows a way to split this up if there is at least approximately 10.5GB available.

/usr/src and /usr/obj

The /usr/src and /usr/obj are likely to be completely unnecessary unless interacting with OpenBSD's source code (e.g. using OpenBSD's source code to update the operating system). If there is not enough space for another partition to be as big as desired, and if OpenBSD's source code is not expected to be used, then these partitions may be removable.

If simply removing these partitions is undesirable (after all, they were created for a reason), make sure that they are both large enough. If either partition is not large enough, then changes need to be made. Size requirements for /usr/obj/ has documented usage of 1.2GB, although this is likely to change with various versions of OpenBSD. (That size might include more than just the base operating system; e.g. Xenocara.) Compare that to the size of the partition: entering p will show the size in sectors which are each ¹/₂ KB in size. So, to be at least 1.2GB (1,258,291 KB), there needs to be at least 2,516,582 sectors that are ¹/₂ KB each. Make usre that /usr/obj is at least that large.

Sometimes the automatic installer has been known to make /usr/obj/ this a tiny bit too small. When working with the source code, running out of space on /usr/obj/ is really painful to deal with. Making the partition larger can also be a bit unpleasant to deal with, because that may require adjusting the size of every later partition. If /usr/obj/ is not large enough, and if both /usr/src/ and /usr/obj/ are right next to each other, consider deleting the later partition and re-sizing the earlier partition so that it covers the space that used to be taken care of by both partitions. Use that space for /usr/obj/. Using a different partition to store the /usr/src/ subdirectory can be finessed into another spot.

Additional mount points to consider

If creating the mount points manually, the other default mount points under /usr (that is: /usr and /usr/X11R6 and /usr/local) can be combined into one /usr folder. That is recommended if security concerns are minimal (especially if users are not logging into the machine) and if setting things up manually. The default size of /usr/local might be excessively large or insufficient. Basically, /usr/local is for adding programs beyond just what comes bundled with the operating system's installation files. (This refers to using pkg_tools (pkg_add) to install software.)

A more ideal setup

Actually, having some more space on /usr can be nice, and /var could be nice with some setups (such as if data for E-Mail is stored on /var), and /tmp can be handy to be large. So making each of those partitions larger could, in theory, be nice. For the swap partition, (slightly) exceeding the amount of RAM in a system can provide some benefit, as noted by discussion about swap size.

However, for most or all of these cases, the benefit will probably be minimal, and the process is a bit challenging. Not only would the partition sizes need to be increased, but the offsets would need to be adjusted to prevent overlap. In example/academic/test scenarios, making such effort manually will often be unnecessary. The R command might be helpful, although at the time of this writing (with OpenBSD 5.3 recently released), it seems non-intuitive. (After adjusting one “partition”, the software asks for details about other partitions. However, the software does not identify which partition the question is meant for, and so the user might think that this appears to be some sort of (endless?) loop.) Further testing/development may be needed before that approach becomes recommended.

After modifying the disk label

w writes to the disk. q writes to the disk and then quits. x exits without saving any currently-unsaved changes.

Write new label?: [y]

If n is selected, then disklabel -E diskname will exit with a return code of 1. This will cause the installer to decide to loop.

After adjusting the disk layout

If the installer is not happy with the results of the disklabel process, it may loop back to an earlier point. The installer may display a message:

'/' must be configured!

If the installer loops back, and notices the disk signature at 0x0, it may report:

MBR has invalid signature; not showing it.

Then, if the installer is looping back, the installer jumps back to the program asking about editing the “(W)hole disk”. e.g.:

MBR has invalid signature; not showing it. Use (W)hole disk or (E)dit the MBR? [whole]

The fastest way, without making any other changes, to get back to disklabel -e, is to choose to (E)dit the MBR, and then use ex to exit fdisk -e.

As soon as the installer is content, it will start overwriting any newly defined disklabel partitions. While newfs is running, go ahead and check out the tutorial on installing an operating system's section called “Be braced”.

e.g.:

/dev/rwd0a: 1024.0MB in 2097152 sectors of 512 bytes 6 cylinder groups of 202.47MB, 12958 blocks, 25984 inodes each /dev/rwd0d: 2168.0MB in 4440064 sectors of 512 bytes 11 cylinder groups of 202.47MB, 12958 blocks, 25984 inodes each /dev/rwd0f: 2048.0MB in 4194304 sectors of 512 bytes 11 cylinder groups of 202.47MB, 12958 blocks, 25984 inodes each /dev/rwd0g: 1024.0MB in 2097152 sectors of 512 bytes 6 cylinder groups of 202.47MB, 12958 blocks, 25984 inodes each /dev/rwd0h: 4608.0MB in 9437184 sectors of 512 bytes 23 cylinder groups of 202.47MB, 12958 blocks, 25984 inodes each /dev/rwd0j: 2048.0MB in 4194304 sectors of 512 bytes 11 cylinder groups of 202.47MB, 12958 blocks, 25984 inodes each /dev/rwd0i: 1536.0MB in 3145728 sectors of 512 bytes 8 cylinder groups of 202.47MB, 12958 blocks, 25984 inodes each /dev/rwd0e: 3408.0MB in 6979584 sectors of 512 bytes 17 cylinder groups of 202.47MB, 12958 blocks, 25984 inodes each /dev/wd0a on /mnt type ffs (rw, asynchronous, local) /dev/wd0d on /mnt/tmp type ffs (rw, asynchronous, local, nodev, nosuid) /dev/wd0f on /mnt/usr type ffs (rw, asynchronous, local, nodev) /dev/wd0g on /mnt/usr/X11R6 type ffs (rw, asynchronous, local, nodev) /dev/wd0h on /mnt/usr/local type ffs (rw, asynchronous, local, nodev) /dev/wd0j on /mnt/usr/obj type ffs (rw, asynchronous, local, nodev, nosuid) /dev/wd0i on /mnt/usr/src type ffs (rw, asynchronous, local, nodev, nosuid) /dev/wd0e on /mnt/var type ffs (rw, asynchronous, local, nodev, nosuid)

Unimportant observations

(The last part of that output appears to be something between “ mount | grep /mnt ” (which does not show “rw, ”) and mount -v | grep /mnt ” (which shows ctime). A quick review indicated this output may come from some script code called munge_fstab.)

(Though the number of cylinder groups change, the number of MB, blocks, and inodes for each cylinder will likely be the same throughout the entire drive.)

[#obck55aa]: Reviewing the disk change(s)

The installer says:

Let's install the sets!

However, before proceeding to do such a thing, consider whether the boot signature is set. If not, then the sets may be installed, only to result in an installation that won't boot. This can be fixed now, fairly easily.

First, if the computer is still at a prompt related to the OpenBSD installer, get to a command prompt.

! Type 'exit' to return to install.

The following shows a process of discovering the correct device name, seeing an invalid signature, and fixing it.

# fdisk sd0 fdisk: sd0: Device not configured # fdisk wd0 D i sk:  wd0        g eome try : 1216 01/2 55/6 3 [19 53525168 S ectors] O f fset : 0        S igna tur e: 0x0               S tart ing           E ndin g           LBA Info:   # : id       C    H    S  -       C    H    S  [        start:         size  ] - - ---- ------- ---- ---- --- ------ ---- ---- ----- ---------- ------------ -- ------------ * 0 : A6   16710    0    1  -   33419   85   16  [    268446150:    268435456  ]  OpenBSD   1 : 00       0    0    1  -       0    0    0  [            0:            0  ]  unused   2 : 00       0    0    1  -       0    0    0  [            0:            0  ]  unused   3 : 00       0    0    1  -       0    0    0  [            0:            0  ]  unused

This pretty much confirmed that the problem is still existent. The following shows how to fix the problem on a disk called wd0. (If the disk is sd0 then specify that instead.)

# fdisk -e wd0 Enter 'help' for information fdisk: 1> update Machine code updated. fdisk:*1> p D i sk:  wd0        g eome try : 1216 01/2 55/6 3 [19 53525168 S ectors] O f fset : 0        S igna tur e: 0xA A55               S tart ing           E ndin g           LBA Info:   # : id       C    H    S  -       C    H    S  [        start:         size  ] - - ---- ------- ---- ---- --- ------ ---- ---- ----- ---------- ------------ -- ------------   0 : A6   16710    0    1  -   33419   85   16  [    268446150:    268435456  ]  OpenBSD   1 : 00       0    0    1  -       0    0    0  [            0:            0  ]  unused   2 : 00       0    0    1  -       0    0    0  [            0:            0  ]  unused   3 : 00       0    0    1  -       0    0    0  [            0:            0  ]  unused fdisk:*1>

While looking at the fdisk portrary of the disk's main bootblock, if this disk is intended to contain the computer's primary boot code then be sure to mark a partition active. The output of the previous example was customized to show what a disk looks like when it has no partition flagged as being the “active”/“bootable”/“flagged” partition. The next step shows how this can be fixed, and shows the results. The asterisk next to the partition number (in the following example) identifies which partition is marked as active/bootable.

fdisk:*1> flag 0 Partition 0 marked active. fdisk:*1> p D i sk:  wd0        g eome try : 1216 01/2 55/6 3 [19 53525168 S ectors] O f fset : 0        S igna tur e: 0xA A55               S tart ing           E ndin g           LBA Info:   # : id       C    H    S  -       C    H    S  [        start:         size  ] - - ---- ------- ---- ---- --- ------ ---- ---- ----- ---------- ------------ -- ------------ * 0 : A6   16710    0    1  -   33419   85   16  [    268446150:    268435456  ]  OpenBSD   1 : 00       0    0    1  -       0    0    0  [            0:            0  ]  unused   2 : 00       0    0    1  -       0    0    0  [            0:            0  ]  unused   3 : 00       0    0    1  -       0    0    0  [            0:            0  ]  unused fdisk:*1>

When all the needed changes in fdisk are complete, and if the changes made are desirable, then be sure to save the changes.

fdisk:*1> q Writing MBR at offset 0. #

If the fdisk program was entered fairly early in the process of installing the operating system, then leaving the shell may return back to the install program, by using:

# exit

Installing the sets

After the installer says:

Let's install the sets!

the installer says:

Location of sets? (cd disk ftp http or 'done') [cd]

If using an official OpenBSD CD, or a download of install??.iso then choose cd. Otherwise, choose one of the next options.

If installing by CD

Available CD-ROMs are: cd0. Which one contains the install media? (or 'done') [cd0] Pathname to the sets? (or 'done') [$(uname -r)/$(uname -m | uname -p)]

Choosing the sets

Select sets by entering a set name, a file name pattern or 'all'. De-select sets by prepending a '-' to the set name, file name pattern or 'all'. Selected sets are labelled '[X]'.     [X] bsd           [X] etc53.tgz     [X] xbase53.tgz   [X] xserv53.tgz     [X] bsd.rd        [X] comp53.tgz    [X] xetc53.tgz     [ ] bsd.mp        [X] man53.tgz     [X] xshare53.tgz     [X] base53.tgz    [X] game53.tgz    [X] xfont53.tgz Set name(s)? (or 'abort' or 'done') [done]

We can remove the X's next to the package names that start with the letter “x” as follows:

[X] bsd           [X] etc53.tgz     [ ] xbase53.tgz   [ ] xserv53.tgz     [X] bsd.rd        [X] comp53.tgz    [ ] xetc53.tgz     [ ] bsd.mp        [X] man53.tgz     [ ] xshare53.tgz     [X] base53.tgz    [X] game53.tgz    [ ] xfont53.tgz Set name(s)? (or 'abort' or 'done') [done]

We can add an X by all packages as follows:

Set name(s)? (or 'abort' or 'done') [done] *     [X] bsd           [X] etc53.tgz     [X] xbase53.tgz   [X] xserv53.tgz     [X] bsd.rd        [X] comp53.tgz    [X] xetc53.tgz     [X] bsd.mp        [X] man53.tgz     [X] xshare53.tgz     [X] base53.tgz    [X] game53.tgz    [X] xfont53.tgz Set name(s)? (or 'abort' or 'done') [done]

At least with some installations of OpenBSD (perhaps especially with old versions?), the bsd.mp package is unselected by default. Computers with multi-core processors probably should be using that package, so having it being available probably is a good thing. (As a generalization, installing the bsd.mp package is a good thing.)

The simplest approach is likely to just select all packages. This may include some unnecessary software, and so may not be the approach recommended in some cases.

Installing

Set name(s)? (or 'abort' or 'done') [done] bsd          100% |*************************************|  8969 KB    00:03 bsd.rd       100% |*************************************|  7215 KB    00:03 bsd.mp       100% |*************************************|  9000 KB    00:03 base53.tgz   100% |*************************************| 61747 KB    01:06 etc53.tgz    100% |*************************************|   511 KB    00:00 comp53.tgz   100% |*************************************| 50626 KB    00:53 man53.tgz    100% |*************************************|  9510 KB    00:12 game53.tgz   100% |*************************************|  2715 KB    00:02 xbase53.tgz  100% |*************************************| 11263 KB    00:11 xetc53.tgz   100% |*************************************| 63696       00:00 xshare53.tgz 100% |*************************************|  4235 KB    00:09 xfont53.tgz  100% |*************************************| 38870 KB    00:34 xserv53.tgz  100% |*************************************| 27515 KB    00:22 Location of sets? (cd disk ftp http or 'done') [done]

Huh? Why is xetc53.tgz missing the "KB”? (If it is really 63696 bytes, then why wouldn't it just say "62KB” or "63KB”?

Time

If detected issue

e.g.:

Time appears wrong. Set to 'Sun May  5 14:21:51 PDT 2013'? [yes]

Hmm.... if it takes 5 seconds to decide upon an answer, then is the clock set to be 5 seconds off?

If timezone unknown

Hmm, unsure how this would happen, but the question has been known to crop up here...

Then, after printing another blank line, the time zone question cropped up.

Final steps of the initial install process

Steps that generally go fine

Saving configuration files...done. Generating initial host.random file...done. Making all device nodes...done.

Installing “bootblocks”

If all goes well when “bootblocks” was installed

Apparently, if the installation of the “bootblocks” program was completed successfully, then no text gets output by that process. If you don't see any text from the section describing errors, then no response is needed.

If there was a problem

Invalid boot signature

The installboot comand may output the first line of the following text:

installboot: invalid boot record signature (0x0000) @ sector 0 Failed to install bootblocks. You will not be able to boot OpenBSD from sd0.

Sigh... did this guide, or did this guide not, provide instructions that would avoid this? (The answer is: yes, the guide did provide such instructions.) Now fixing this will take a bit more effort than if the fix was applied earlier.

Determine the drive name. (Running mount may help to identify the drive name.)

Before trying to worry about getting the “bootblocks” program installed, finally get around to fixing the problem of the boot signature. See: section about checking the disk boot “magic” signature” for directions on how to get the right signature, because that will be the first necessary step in order to get the “bootblocks” program installed.

Next, after getting the magic signature resolved, proceed to install bootblocks manually. This may be done as follows (customizing the disk name as needed).

/mnt/usr/mdec/installboot -v /mnt/boot /mnt/usr/mdec/biosboot sd0

Note: This is assuming that the command is run from an OpenBSD boot CD. If running this on an actual installed system, take out the three references to /mnt, so the command would look like this:

/mnt/usr/mdec/installboot -v /mnt/boot /mnt/usr/mdec/biosboot sd0

After running the command, and before running any other commands, run:

echo $?

That will output the results of the previous command, which should be the installboot command. The results should say 0 (zero). If the output states:

installboot: open: /dev/rsd0c: Device not configured

Then the error code will be 1, and this probably means that an incorrect drive name was specified. Once again, check the drive name and specify the right one. (For instance, maybe wd0 is needed instead of sd0.) If that doesn't seem to be the problem, re-check that fdisk successfully saved the changes when updating the drive signature.

Another alternative could be to re-install. This may go faster since the disk layout doesn't need to change (other than fixing the signature). However, this will result in re-formatting the filesystems, and so then the sets will need to be re-installed. (If they were downloaded before, they will likely need to be re-downloaded.)

If all went well

CONGRATULATIONS! Your OpenBSD install has been successfully completed! To boot the new system, enter 'reboot' at the command prompt. When you login to your new system the first time, please read your mail using the 'mail' command.

If this is seen, the installation seems to have completed successfully.

Once everything is done successfully, there is likely little to no reason to try to do much else in this limited environment. Go ahead and run reboot or, if the desire is to stop the computer, use “ halt -p ”

First boot

If all goes well, the operating system will show a login: prompt. (Proceed to the section about “Post-installation”.)

Troubleshooting problems with the first boot

System stops at ddb> prompt

The system may stop operating normally after showing some output that looks something like this:

RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! IF RUNNING SMP, USE 'mach ddebcpu <#>' AND 'trace' ON OTHER PROCESSORS, TOO. DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb(0)>

General process

This sort of message probably comes after two lines that say something like:

panic: customPanicDescription Stopped at      Debugger+0x5:   leave

First of all, know that it is good to gather some information, including some of the details shown on the screen, before it scrolls off of the screen. Record the reason for the panic (shown on the line that starts with the word “panic: ”), and the next line that says “Stopped at”. These lines can be useful details.

Check the output that was made before the “panic: ” message. If that looks to be related to the reason of the panic, then consider that to be some useful troubleshooting information.

Also, check the information that was displayed just before the “panic” message. (If this happened while working on another terminal, see if there is anything output on the main terminal (by pressing Alt-Ctrl-F1).)

Then, use that panic message to check through this troubleshooting section to see if there are any resolutions. See if you can find information on how to resolve the problem, and do that before interacting with the system further.

If not, see the section about gathering information from ddb, and then check out information from the following resources: interacting with ddb, if OpenBSD panics..., gathering data about crashes in OpenBSD.

Specific issues

panic: root filesystem has size 0

The previous line might say the following, or something close to it:

root on wd0a swap on wd0b dump on wd0b

See if the system can boot up from an OpenBSD CD.

Use the fixed disk program on the drive with the root partition. For instance:

fdisk wd0

If everything looks good,

Use the “update” command to overwrite existing MBR code with what is found.

root on wd0a swap on wd0b dump on wd0b
panic: root filesystem has size 0

Screen is blank (or just showing a blinking cursor in the upper-left corner)

Try this:

[#obsdfbld]: Checking if an installed operating system can boot from different media

See if the system can boot from an OpenBSD CD.

If so, figure out the name of the hard drive. (This may be visible in the output of the boot loader, which is the program that shows “boot>” while the system is booting. For example, perhaps two lines up, the boot loader might say something like “fd0 hd0 cd0”, which refers to floppy disk zero, hard drive zero, and optical disk zero.

If the hard drive is named “wd0”, try listing the files on the hard drive, with something like:

ls wd0a:/

If that works, try booting a kernel from the hard drive. For example:

boot wd0a:/bsd

(If addition to /bsd is not found, other filenames might include /bsd.mp, or less commonly /obsd or /bsd.old or /bsd.sp, or less desirably /bsd.rd.)

If the system is starting up fine when booting from a CD but then using the files on the hard drive, this may just be an issue with the MBR. Try going into “ fdisk -e ” (e.g. “ fdisk -e wd0 ” ) and running the “update ” command (and then perhaps the “write ” command) within “ fdisk -e ”.

If that doesn't fix it, check other details related to “ fdisk -e ”. (See: Checking the “magic” boot signature”.)

Complaint about PCI Express

The following had been seen by a system that installed OpenBSD.

Alert!  Error initializing PCI Express slot  .

It was unclear whether this output was generated from OpenBSD; it might have been by a DELL BIOS. (However, the error message did initially show up after installing OpenBSD.)

Despite what the error message looks like, the cause of this was unrelated to the PCI Express slot. This was seen on a DELL system that took a while to go through the BIOS initialization (possibly including a POST), and the system showed a progress bar while that occurred. Also, the system could boot from the CD without problem.

This indicates that the update command was not performed while running fdisk

See: OpenBSD different boot loader.

Post-installation

The step(s) to take after installing the operating system may vary depending on specific goals trying to be accomplished. Here are some available resources:

Making a virtual machine

If the goal is to create a virtual machine, detailed information is available in the tutorial about making a virtual machine. That guide also provides some common post-installation tasks. Starting up a bunch of network services might be more sensible to do after creating virtual machines, so that the virtual machines can be used to provide the network services.

Post-installation setup

A large guide is available at setupos. (Admittedly, at the time of this writing, this guide may be a bit lengthy/overkill.)

Network services

Details on starting up various network services may be found in the tutorial about building a network.