Dual and Multi Booting FreeBSD, Linux, and OpenBSD

OpenBSD Installs

• OpenBSD Partitioning Issues

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 either.

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 below.

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 are useful.

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 below.

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 number.

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 each.

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 partitions.

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 boot process.

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 process.

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 systems.

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 configuration details.

After fdisk and disklabel, the rest of the OpenBSD install is the same as any other.

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 as before.

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 - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). 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 allowed.