Dual and Multi Booting FreeBSD, Linux, and OpenBSD
The OpenBSD install is overall the simplest compared to FreeBSD and
Linux but the fdisk and disklabel programs are the most difficult.
I've done many OpenBSD installs over the past two years and never had
any difficulty with OpenBSD's disk setup software. Previously all
installs used the entire hard disk. The past ten or so days have made
it abundantly clear that OpenBSD's disk setup software was built for
full disk installs, and little consideration was given to multi boot
issues in its design. With care and starting with
clean disks it works adequately in
multi boot installs, but you need to know what you are doing. I don't
believe the OpenBSD developers want OpenBSD installed with other
systems on the same hard disk; if they did, they would provide a
better disk setup programs and address the 1024 cylinder limit that
the other systems have fixed.
Like the FreeBSD install, OpenBSD's install has no "Back" options.
During the OpenBSD install, you can press [Ctrl+C] at any time and
will immediately drop to a # single user prompt. Typing "install" and
pressing Enter will restart the install without rebooting. In fdisk,
pressing [Ctrl+D] will immediately exit fdisk without saving any
changes and take you to disklabel. In disklabel, you can use [Ctrl+D]
to cancel a sequence of partition setup prompts. If you use [Ctrl+D]
at the disklabel prompt you will immediately exit disklabel without
saving any changes you may have made. If you accidentally exit
disklabel this way, you will need to abort the install and restart.
Any changes already saved (with 'w') in fdisk or disklabel, do not
need to be repeated, and will show when you use the 'p' option in
The first important question in the OpenBSD install is whether you
want to use the *entire* disk for OpenBSD. This is defaulted to no.
If you accept the default and press enter, you will be placed in
OpenBSD's fdisk to partition the drive. If instead, you type "yes"
and press Enter you won't see fdisk, but the install will use fdisk to
allocate the entire drive to OpenBSD.
The OpenBSD install is incredibly unforgiving. If you choose to use
the entire hard disk, the install erases without any notice or
warning, all existing hard disk partition information, as soon as you
press Enter. Four FreeBSD systems previously installed on the same
hard disk, were gone in an instant with no indication anything had
occured. This was confirmed by starting a FreeBSD install after
aborting the OpenBSD install and by the Ranish partition manager. Both
saw only a single type a6, OpenBSD, partition occupying the entire
hard disk. This was what I'd expected; I just wasn't sure with a full
disk install, if the slice infomation was overwritten when entering
OpenBSD's disklabel, or if the install waited until the disklabel
changes were saved to commit the slice changes.
If you are doing a multi system install and don't give the entire hard
disk to OpenBSD, its fdisk is crude and error prone compared to the
fdisks provided with FreeBSD and Linux. On clean disks and those with
only OpenBSD created partitions with all cylinders below 1024 it
normally starts with correct partition information displayed. If
other systems are installed or have been installed previously,
OpenBSD's fdisk rarely displays correct partition information when it
starts. You need to use the 'p' option to redisplay the partition
information, which is then normally displayed correctly.
The OpenBSD fdisk display is a nine line display. It starts with the
disk geometry in cylinders/heads/sectors. The last four lines, each
show the data for one slice. They are numbered 0: - 3: and followed
by the hex slice type. Starting and ending cylinders, heads, and
sectors are shown for each partition, except that no cylinder numbers
over 1023 are dispalyed. All cylinders over 1023 are reduced to 1023,
which is not very helpful, since most disks today have far more
than 1024 cylinders. Also shown is the offset (from the begining of
the disk) and size in 512 byte sectors. If you are good at 8 digit
mental arithmetic, you may be able to verify that you've correctly
entered your slice information. The last column gives the system name
for the slice. Unused slices show as all zeroes.
OpenBSD's fdisk writes changes when you type a 'w' and press Enter.
When you do this, the displayed disk partition data will be written to
disk, whether the setup is plausible or not. Fdisk is almost totally
lacking in useful errors or warnings.
If you do save changes with fdisk, and the OpenBSD slice is not at the
same offset as a previously installed OpenBSD system, fdisk displays
"wd0: no disk label" in bright white on blue. Given the prominence of
the display, this appears as some serious error or warning when the
condition is inevitable on any new or clean hard disk. In a dual or
multi boot installs, this message is almost a prerequisite for a
straight forward OpenBSD install. The absence of this message when
fdisk writes changes to a disk, means that disklabel will start with
information from a previous install. If disklabel uses old disklabel
data and any partition information has changed, disklabel's behaviour
becomes unpredictable. The details are discussed
To modify or edit a slice, which includes putting an unused slice to
use (creating), type an 'e' followed by a space and the slice number.
If the type is entered as 0, which is the marker for an unused slice,
the slice data will be zeroed if it was previously used, and you will
be returned to the fdisk prompt. At each OpenBSD fdisk prompt while
editing a slice, the default value will be displayed. You can simply
press enter to accept the displayed default, but few fdisk defaults
If you enter a value other than zero for slice type, you will be
prompted if you wish to edit in CHS mode which is defaulted to no. CHS
is cylinders, heads, and sectors. If you accept the default, you
enter the cylinder starting and ending offset in sectors. This should
be simpler than CHS, except that OpenBSD's fdisk won't adjust the
sector entries to the nearest cylinder boundary. Since the odds of
entering the first or last sector in a cylinder, unless you perform
the necessary calculations, are the number of sectors in that cylinder
to one (or several thousand to one), the default editing mode
virtually guarantees the creation of slices other partitioning
software will see as invalid. See
To create slices other systems can use without errors, you must edit
with OpenBSD's fdisk in CHS mode, and insure that all slice boundaries
correspond with the begining and end of cylinders. There is one
exception. The first physical slice on a disk should leave the first
track empty, so should start with cylinder 0, head 1 and not head 0.
To correctly allocate slices with OpenBSD's fdisk, you need to use the
number of cylinders displayed in the disk geometry, estimate the
amount of the disk you wish to give each slice, and calculate the
starting and ending cylinders for each slice. The start of the next
higher slice should always start in a cylinder that is one higher than
the last cylinder of the preceding slice, unless you want unused gaps
on the disk. You don't need to calculate heads and sectors. Except
the first slice, slices should always start with head 0 and sector 1.
Slices should always end with the last head number and last sector
OpenBSD's fdisk doesn't give useful defaults to most values. If you
change the type on an existing slice, the defaults will be the slice's
current values which is normally helpful, except if the cylinder is
greater than 1023, the default reverts to 0. Otherwise the defaults
are pretty useless. In CHS mode, the cylinders are not the next
cylinder after the preceding slice or limited by a following slice if
one exists. They are 0 for both the start and end of every slice.
Likewise both heads and sectors for both the start and end of a slice
are mostly defaulted to 0. Sectors are numbered from 1, so a 0
default is always wrong and won't be accepted by fdisk (one of fdisk's
very few integrity checks). On occasion, I've seen starting sector
defaulted to 1. Fdisk will warn you but accept the values, if you
create a slice with a starting cylinder greater than the ending
cylinder. It doesn't warn you about overlapping slices, gaps between
slices, or slices that start in the middle of a cylinder.
To mark a slice as bootable with OpenBSD's fdisk, use 'f' followed by
a space and the partition number.
I would like to recommend using anything else to setup your hard disk
slices but the most reliable way to do any install that includes
OpenBSD is to start with OpenBSD and install it into the first slice
on the hard disk starting in cylinder 0. Start by editing slice 0
with "e 0" then enter "a6" for the type. The starting cylinder should
be 0, head 1 (not 0 which would be used for any other slice) and
sector 1 (sectors always start at 1).
The ending cylinder obviously depends on how large you wish to make
OpenBSD's slice. The only special consideration is if the system will
have two or more OpenBSD systems installed, the last OpenBSD system to
be installed must be installed into a slice that starts enough below
cylinder 1023 that there is room for its '/' file system inside of
cylinder 1023. Otherwise, the ending cylinder is whatever you
calculate it to be, based on the total number of cylinders in the
system, and how much space you wish to allocate to the OpenBSD slice.
The ending head and sector should always be the last available of
After defining a new OpenBSD slice's size, mark it as bootable or
active with 'f 0', assuming you're working with the first slice. Then
save your changes with 'w'. Quit OpenBSD's fdisk with 'q' and enter
which will take you into disklabel.
When the label is written you should see "wd0: no disk label",
normally highlighted in bright white on blue. If you are working on a
SCSI disk "wd0" would be replaced by "sd0" and if on the second hard
disk by "wd1". This looks like a warning or error but this is
something you want to see in dual and multi boot installs.
If you do not see the "no disk label" message it means that there is
an existing disklabel and which will be used when you enter the
disklabel program. You will be editing information from the old
disklabel and not the current disk setup. While this is great on a
single disk installs, because it lets you reuse your old partition
information, and the slice has to be the same as the old slice since
it's the entire hard disk, it's a real problem on multi boot installs.
It appears that fdisk will always find an old disklabel if the new
slice starts at the same location as an old slice used for OpenBSD. If
OpenBSD was previously installed on the disk and the disk was not
wiped clean, this will normally be the
case for the first slice which should always start at cylinder 0, head
1, sector 1. Presumably the disklabel is found at the begining of or
at a fixed offset from the start of the slice. When disklabel has
started with old or invalid information I've seen all of the following
problems in various installs: total hard disk size listed as a small
fraction of the real size, unable to calculate starting offsets for
any partitions after the first, unable to correctly calculate relative
sizes (megabytes or gigabytes rather than sectors), unable to locate
the end of the OpenBSD partition, non OpenBSD slices or partitions in
wrong locations or with wrong sizes.
When you begin a dual or multi boot install with OpenBSD, enter
disklabel for the first OpenBSD system, and use 'p' to display the
current disklabel, you should see only a: and c:. A:'s size should be
exactly the number of sectors that was calculated as the size of the
OpenBSD slice created in fdisk. If you have any doubt about this,
abort the install with [Ctrl+C] and restart it with "install". Verify
that the sizes match and that c: matches the size of the entire disk
in sectors. It's possible to work with disklabel when it starts with
invalid information, but probably not worth the effort.
The most thorough way to deal with OpenBSD using old disklabel data,
is to abort the install and use Ranish Partition Manager or a similar
tool to completely initialize the hard
disk to a logically new state. The fast and dirty way to get a new
disklabel is to use Ranish to overwrite the first few megabytes of the
new slice which will take a few seconds or the entire '/' which will
take somewhat longer but probably not more than a couple minutes. The
problem with not cleaning the entire disk, is that there may still be
additional old install information on the disk which may cause
problems for either subsequent OpenBSD or Linux installs. The time
for a complete disk wipe will likely be less than dealing with
additional problems, that may be caused by old install data.
Disklabel includes a 'D' option that starts a new disklabel with
default information. The displayed disklabel appears as it would when
fdisk displays the "no disk label" message. If there is only one
OpenBSD partition on the disk, then only a: and c: show but if other
systems are already installed, their partitions will show in
disklabel. While 'D' seems to fix any problems that OpenBSD has
with its own old information, it does not address how Linux can
sometimes find old BSD disklable data.
If OpenBSD is installed after other systems have been installed a new
disklabel will contain partitions, normally starting at i: for any
primary partitions that exist on the disk and will include any Linux
extended partitions. If a Linux system is installed, and you use
OpenBSD's fdisk to delete the Linux extended partition, OpenBSD's
fdisk won't pick up Linux extended partitions that were orphaned by
this deletion of the containing primary partition. If an OpenBSD
system was previously installed after the Linux system was installed,
the old OpenBSD disklabel will definitely have the old Linux
partitions and the new install will pick it up if it's at the same
starting offset as the previous OpenBSD install. If you see disklabel
display partitions i: - p: that don't exist or are wrong, then use the
'D' option to create a correct disklabel, if you aren't going to
clean the disk.
The more differences disklabel sees from a normal single system
install starting in cylinder 0, the more likely it is to behave
erratically. If disklabel cannot calculate starting offsets for new
partitons (a: - h:) correctly and any i: - p: partiontions extist, you
should you delete all existing partitions before assigning a: - h:
partitions for OpenBSD. Especially when OpenBSD is installed at a
location that doesn't start with cylinder 0, the i: - p: partitions
seem to perevent disklabel from calculating starting offsets correctly.
If you later wish to mount Linux or FreeBSD partitions from OpenBSD,
after disklabel calculates the sizes and offsets without any i: - p:
partitions present, carefully write down all the partitions you've
created with their sizes and starting offsets. Then use the 'D'
option to recreate all foreign partions as the kernel sees them. Your
a: - h: partitions will be replaced by as single a: partition. Delete
a: and recreate the partitions a: - h: from your notes, entering all
data in sector offsets. This should allow you to create partitions of
the desired sizes, starting on cylinder boundaries to minimize
unallocated sector warning messages when the file systems are
created, and still provide access to pre-existing Linux and FreeBSD
If you install OpenBSD after FreeBSD or Linux, setup the slice or
slices for OpenBSD using the first system's fdisk. Don't use
OpenBSD's fdisk to define the slice or mark the OpenBSD slice as
bootable. If you are mixing OpenBSD with FreeBSD and or Linux, you
will be using a boot loader from one of those systems to control the
I've seen several systems that were bootable, rendered unbootable
when OpenBSD's fdisk wrote changes to the disk. If OpenBSD follows
FreeBSD and all slices were set up in FreeBSD, the loader will be
ready to go when OpenBSD is installed. If GRUB is the boot loader,
OpenBSD won't boot until you update GRUB's configuration. This is
covered in the
GRUB section and may be done before
OpenBSD is installed so it will be immediately bootable. If GRUB is
clobbered by any other system, this can be fixed by reinstalling GRUB
as discussed Installing GRUB.
OpenBSD's fdisk may not update the IPL code in the MBR. Twice I've had
to update the MBR with either Ranish's standard IPL code or DOS's
"fdisk /mbr", before I could boot a newly installed OpenBSD system.
One of these times, "GRUB" filled the screen from GRUB's first stage
loader, that could not find the second stage since the disk had been
erased (except the MBR). My experiments provided no insight as to why
OpenBSD sometimes updates the disk so previously bootable systems
are not bootable, and other times leaves the IPL code unchanged.
Unlike FreeBSD, OpenBSD's fdisk and disklabel commit their changes to
disk when you complete each step or whenever you choose during the
Grub makes it easy to perform some partition
trickery, without which two or more bootable OpenBSD systems on
one disk would not be possible. Perform the first
install as described previously begining at the begining of the
disk and leave enough room that the second slice in which a second
copy of OpenBSD will be installed, will have room for the second
system's "/" file system within the first 1024 cylinders.
When you do the second install, change the first slice from type a6
and to a8; any unknown value should work but a8 is close to the valid
value, not defined, and has worked for me. Then define the new second
slice as a6. The starting cylinder will be one greater than the
ending cylinder of the first slice. The staring head will be 0
instead of 1 and the last cylinder will be based on the combined size
of the first two slices. The starting sector is always 1 and the
ending head and sector the highest possible values. The second slice
needs to be marked as bootable. The first slice won't be bootable
again until GRUB is installed and configured to boot two OpenBSD
Using the technique just described, up to four OpenBSD systems could
be installed on a single hard disk. With more than two systems, the
primary issue is how to locate them so the boot files remain inside
the 1024 cylinder limit. Up to something between 1300 and 1350
cylinders, all four systems could be basically the same size. Since
with most large disks, 24 cylinders is plenty for an OpenBSD '/' file
system, an easy way to allocate space follows. With two systems, the
first gets up to the first 999 cylinders and the second starts at
1000. With three systems, the first gets 0 - 499, the second, 500 -
999, and the third starts at 1000. With four systems it's 0 - 333,
334 - 666, 667 - 999, 1000+.
GRUB can allow multiple copies of OpenBSD to boot because it includes
a command that allows GRUB to change the slice to be booted to type a6
and the other OpenBSD slices to an unknown type. No OpenBSD system is
ever aware of the other systems' presence. The booting slice type must
be a6 for OpenBSD to boot, and if there are two a6 slices, only the
first will ever boot. See GRUB
After fdisk and disklabel, the rest of the OpenBSD install is the same
as any other.
OpenBSD Partitioning Issues
I generally believe that OpenBSD software is the highest quality
software available, but OpenBSD's disk partitioning software is
substandard. It's the minimum necessary to create an a6, OpenBSD,
primary partition. OpenBSD's fdisk is lacking in integrity checking
and does not handle disk partitions consistently with other systems.
The fdisk write command, 'w', will write partition data with whatever
partition information is displayed, including completely implausible
overlapping partitions. It let me create FreeBSD, Linux, and extended
partitions, each occupying the entire hard disk, including the first
track which should be reserved for the MBR and boot information. This
was in addition to a full disk, OpenBSD partition, that did not occupy
the first track. On this I was able to install a bootable OpenBSD
system with a single / partition occupying 29GB. This bizarre disk
setup prevented booting from three different floppies, each of which
booted without problem, once a normal, non conflicted partition data,
was written to the hard disk.
Besides often not showing correct partitioning information when it
starts, I have seen fdisk display the same slice data twice on the
screen with different information in the two displays.
OpenBSD's fdisk handling of the partition table is different than
FreeBSD and Linux and does not conform with the standards. Two times
that I tried using sectors to establish slices, I had nothing but
trouble with all other partitioning software. The first time, slice 0
was edited to type a6 and given the first 29,000,000 sectors (about
half a 30GB disk) and marked bootable with "f 0". A basic install
with several file systems consuming the entire partition was performed.
In the OpenBSD install, no slice was allocated for a FreeBSD
partition. When the FreeBSD install started, it saw only an unused
disk without partitions. I then tried a Linux install to see what it
saw. Linux's fdisk displayed the message "Warning: too many
partitions (16, the maximum is 8)". It displayed partitions a: - g:
as OpenBSD laid them out including the "unused" c: that occupied the
whole disk. It's not clear that I wiped the disk clean so this may
have been old information. Manual Disk Druid saw an empty disk as did
the automatic partition option. The Ranish Partition Manager also saw
only a single unused primary partition occupying the entire disk and
with no type. When I returned to the OpenBSD installer to see if I
could add a partition, it too displayed completely empty slice data
with all four partitions nothing but zeroes. I may have forgotten to
use 'p' to redisplay the information.
I reentered the 0 disk partition information as before and started the
1 disk partition (second slice) as an a5 (FreeBSD) at sector
29,000,001 and used the rest of the disk. I saved this, then aborted
the install, and started over to see that fdisk displayed the same
information it had just written. It did. I then rebooted to verify
that the previous OpenBSD install was still bootable and it was.
FreeBSD's fdisk then saw the OpenBSD and FreeBSD partitions with one
unused sector between and some free space at the end.
Linux's fdisk started with several dialog boxes. The first said
"Invalid partition on /tmp/hda." with Ignore and Cancel options. When
I ignored the error, a new dialog displayed "Unable to align partition
properly. This probably means that another partitioning tool generated
an incorrect partition table, because it didn't have the correct BIOS
geometry. It is safe to ignore, but ignoring may cause (fixable)
problems with some boot loaders." and also had Ignore and Cancel
options. The first message was redisplayed 3 or 4 times before I
could get into fdisk. (I saw these messages several times as I
experimented with dual and multi boot options.) Fdisk then displayed
the "too many partitions" error. 'p' showed the same partition layout
Red Hat's Disk Druid displayed "Invalid partition on /tmp/hda" and
when ignored, showed the OpenBSD partition as unused, and /dev/hda as
a BSD/386 partition, and a 1 cylinder, 6MB, free space at the end.
The auto partitioning process also displayed the short, "invalid
partition", message then crashed with an "unhandled exception" and
requested that the crash dump be saved to a floppy for a bug report.
Ranish Partition Manager saw an unknown a6 partition (it doesn't know
the OpenBSD type number) and a "FreeBSD, BSD/386" partition separated
by a single sector, unused primary partition at cylinder 1917 of 3877,
head 237 of 240, and sector 30 of 63. In other words, OpenBSD's fdisk
used exactly the number of sectors I specified, and did not align the
partitions on the nearest cylinder boundary.
I started a new OpenBSD installation, replacing all slice information.
This time I used the CHS method and made sure that both partitions
started on the first head and sector and ended on the last head and
sector of their respective cylinders, except the first track or 63
sectors of the first (OpenBSD) partition was left for the MBR and
boot programs. I used 1938 / 1939 of 3877 cylinders as the dividing
line. Disklabel displayed an i: partition for the FreeBSD partition
as well as the normal a: and c: partitions.
Linux's fdisk still displayed the "too many partitions" error. It saw
the OpenBSD partitions inside the first slice but not the FreeBSD
slice. Disk Druid saw both the OpenBSD and FreeBSD slices with no
free space. The auto partitioning process was selected to use only
free space. This process drives Disk Druid with preset parameters. It
displayed a message indicating that "Partitioning failed: could not
allocate partitions as primary partitions." and then the same Disk
Druid display showing no free space which is correct. The FreeBSD
fdisk also saw both the OpenBSD and FreeBSD slices.
Top of Page -
Copyright © 2000 - 2014 by George Shaffer. This material may be
distributed only subject to the terms and conditions set forth in
These terms are subject to change. Distribution is subject to
the current terms, or at the choice of the distributor, those
in an earlier, digitally signed electronic copy of
http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the
time of the distribution. Distribution of substantively modified
versions of GeodSoft content is prohibited without the explicit written
permission of George Shaffer. Distribution of the work or derivatives
of the work, in whole or in part, for commercial purposes is prohibited
unless prior written permission is obtained from George Shaffer.
Distribution in accordance with these terms, for unrestricted and
uncompensated public access, non profit, or internal company use is