GeodSoft logo   GeodSoft

Dual and Multi Booting FreeBSD, Linux, and OpenBSD

Combining Operating Systems

I'm going to divide mixed system, dual and multi boot installs, into two groups. First are any and all combinations of FreeBSD and OpenBSD only. Second are all combinations of Linux with either or both FreeBSD and or OpenBSD.

As I installed one system after another, I saw more kinds of failure and erratic behaviour, mostly from OpenBSD but also from Linux's fdisk, than I can remember or figure out from my notes. At first I thought there was some critical order to perform the installs, but the further I pursued dual and multi booting, the more I became convinced most of the problems were not caused by the current installs on the hard disk but by inconsistent, incomplete, and unerased data from previous installs.

Both FreeBSD's and OpenBSD's fdisks will delete an extended partition as easily as any other, but neither appears to remove the sub partitions that are logically inside the extended partition but recorded separately on the hard disk. FreeBSD completely ignores the inner partitions in an extended partition. A new OpenBSD install will use old disklabel information, if the new install starts at the same offset as a previous install. The old disklabel data may record Linux partitions that no longer exist and primary partitions that have been moved. This can be significant when you can't use the space in an expanded slice or you start allocating partitions that are far beyond the end of a slice that was reduced in size and disklabel gives no warning of any kind.

Linux's fdisk repeated displayed a "too many partitions" error message. When this message was displayed fdisk could make no changes to the disk. As this message has appeared when no other system was currently installed but previous installs were deleted by clearing the partition table but not overwriting the disk, and it does not appear when other systems are installed on clean disk, this also appears to be old BSD disk label data. When the "too many partitions" error is displayed, fdisk can still list the partitions it sees. These were consistent with the locations of previous BSD installs.

I've become convinced the surest way to successfully install multiple bootable systems on one disk is to start with a clean disk containing a standard IPL (initial program loading) code in the MBR, an empty partition table and no unattached extended subpartitions or stray BSD disklabels on the disk. Starting with a disk that has any stray data from previous installs significantly increases the chances encountering difficulties.

The best way to ensure a clean disk is to use something like the Ranish Partition Manager. This is available from http://www.ranish.com/part/. This is shareware with a free 10 year evaluation period for home use and 30 days for commercial use. The commercial fee is $20 per department or technical unit.

The following procedures irretrievably destroy all data previously saved to the disk they are used on. The best way to use Ranish Partition Manager is to use the Delete key to delete all partitions that exist including any extended partitions. This should leave one unused primary partition occupying all but the first sector of the hard disk. Move the cursor up to highlight the MBR line near the top of the screen. If the MBR box in the lower right shows anything but Standard IPL, i.e., Boot Loader or Unkown IPL, press Enter. Use the space bar to change the MBR IPL code to Standard and press Enter. This is equivalent an old DOS "fdisk /mbr". Save the disk partition and MBR changes with F2. Then highlight the primary empty partition and press 'e'. Confirm that you want to overwrite the entire disk with zeroes. This takes more than an hour for 30 - 40GB hard disks but it assures that all old install information will be gone. When completed, the disk looks logically new to partitioning software.

Other partition managers and security software designed to erase disks can do this as well. The utility floppy that comes with Western Digital disks includes a program in the Diagnostics section that will overwrite the entire disk surface with zeroes and report any errors; it seems reasonable that other disk diagnostic software may also include this function.

Unix's dd can also be used to write zeroes to the disk surface; this should be accessible from the FreeBSD, Linux and OpenBSD install CDs. This is easily accessed from the OpenBSD install CD by selecting the shell option rather than install or using [Ctrl+C] to exit the OpenBSD install at any time. The OpenBSD command to clear the first IDE hard disk is "#dd if=/dev/zero of=/dev/wd0c". Red Hat Linux's install CD's rescue mode is a single user prompt. It's not necessary to mount the system as you're going to erase it, not "rescue" it. Once you get the "#" prompt "dd if=/dev/zero of=/dev/hda" will clear the first disk. FreeBSD's "Fixit" option from the main install menu provides access to a single user prompt; the second of the four install CDs is needed. The command "dd if=/dev/zero of=/dev/ad0" appears to clear the first disk.

The Western Digital program takes about twice as long as the Ranish Partition Manager (RPM) does and zeroes the MBR including both the partition table and IPL areas. RPM will let you zero the MBR but only as a separate step and never as part of a partition or the unused space on a disk. All the Unix "dd" commands should erase the entire disk including the MBR. Linux's dd took 2 hours and 12 minutes to zero a 30GB drive. The Unix "dd" command provides no visual completion indicator. When I aborted an OpenBSD erase, dd indicated that it was writing about 1.5MB / second or would take over 5 hours for a 30GB drive. FreeBSD's dd wrote less than 300KB / second and took more than 8.5 hours to clear a 13GB drive.

When the MBR is zeroed, Linux's fdisk reports the zeroed partition table as invalid and can recreate an empty one; the only IPL code it will install is LILO or GRUB and not standard IPL code. OpenBSD simply shows an empty partition table; multiple experiences however, suggest that OpenBSD may not reliably supply standard IPL code, when it's needed, and that OpenBSD may not be able to boot, following a disk erase that zeroes the MBR. A DOS "fdisk /mbr" command will install standard IPL code and allow OpenBSD to boot when its partition is marked active. FreeBSD installed into and booted from a completely zeroed disk without error. The standard IPL code provided by FreeBSD was not recognized by RPM as standard; it was standard enough that it booted both FreeBSD and subsequently OpenBSD. FreeBSD did not however mark its slice as active, suggesting the slice to boot may be hard coded in the IPL code, rather than taken from the partition table.

At least two very different issues are also relevant to multiboot installs. OpenBSD assumes the system (CMOS) clock is set to UTC time. To keep the local displayed time consistent accross multiple systems on the same hard disk (or within the same case), if OpenBSD is part of the mix, then all systems need to be setup expecting the system clock to use UTC time.

Networking and IP addresses also should be considered when setting up dual and multi boot machines. The different systems on the same hard disk can never be active at the same time. Thus you can install all with the same IP address (and optionally the hostname). If you share IP address or host names and use SSH, you will get warnings when you switch systems because the keys won't match. You may not be able to connect with some SSH configurations. Depending on your IP availability you might also make each unique.

Due to their inherent nature as dual or multi boot systems, these systems will not be up all the time. Some may only be up very infrequently. I've chosen a new arbitrary address range from one of the private ranges for all these machines. Each install gets a unique name and a unique IP address. If a few of these machines are up concurrently they can communicate among themselves and with my workstation to which I added an additional alias IP address in the same range as the multi boot machines. Without significant network configuration changes these machines cannot directly communicate with the outside world or any of my permanent machines. Dual and multi booting adds more things to consider than just the obvious install issues.

FreeBSD and OpenBSD

When dual booting OpenBSD and FreeBSD either can be installed first but OpenBSD should always be physically first because it has the 1024 cylinder limit and FreeBSD does not. OpenBSD's disklabel is also more reliable when the slice starts in cylinder 0 than elsewhere. Because the FreeBSD fdisk is much easier to use and less likely to make mistakes, it makes sense to start the install with it. FreeBSD's fdisk has no CHS (cylinders, heads, sectors) allocation method and only lets you set sizes by sectors or optionally megabytes by ending the number entered with an 'm' or gigabytes by ending the number with a 'g'. It ensures the resulting partitions are aligned on cylinder boundaries.

In contrast, OpenBSD's fdisk default method is sectors and if this method is used, it will not align the resulting partitions on cylinder boundaries, leaving a result other systems can't use or see. If you start with OpenBSD, the only safe way to use its fdisk is in the CHS mode, and insure that partitions start and end on cylinder boundaries.

In a two system install, the entire disk will often be allocated to two slices for the two systems. You may chose to devote more slices to FreeBSD if you anticipate multiple FreeBSD installs or a complex system that spans slices. If you leave free space that is not part of a slice, OpenBSD will not be able to use it. FreeBSD could (if all slices are not yet used) but it makes better sense to fully allocate the disk to two (or more) slices initially and if there is more space than needed, leave unallocated space within each slice or an extra slice for use by FreeBSD. Alternatively, it's easy to create a large partition for /tmp as the last partition in each slice. Because it doesn't have permanent files, later it can easily be deleted and some of its space used to create a new partition, then be recreated as a smaller partition. This is assuming you have not already allocated 7 partitions in FreeBSD or 16 in OpenBSD (including ones from other systems that OpenBSD sees).

If you start with FreeBSD, allocate a 166 type partition for OpenBSD at the start of the disk. In the FreeBSD install, the boot loader prompt comes between fdisk and disklabel. Install the FreeBSD boot loader in the MBR; it will recognize the slice you created for OpenBSD and provide a prompt to boot the OpenBSD system. When you install OpenBSD, make no changes in fdisk but use the partition created by FreeBSD. There is no need to have the OpenBSD slice active; the FreeBSD boot loader will do what's needed when you select OpenBSD using the boot loader. If you save changes with OpenBSD's fdisk, you may prevent FreeBSD's boot loader from working. I've seen multiple, previously bootable systems rendered unbootable by a simple write from OpenBSD's fdisk. If you press F1, for OpenBSD (the system in the first slice), in the boot loader before installing OpenBSD, it will just wait until your press F2, for FreeBSD.

If you start with OpenBSD, you can assign slices for both systems, but it's easier to create the FreeBSD slice or slices in FreeBSD. If you start with OpenBSD, you will want to mark its partition active so it will boot prior to a FreeBSD install. FreeBSD can use slices reserved for it by an OpenBSD install but there is no advantage in doing so. To dual boot FreeBSD and OpenBSD, FreeBSD must install its boot loader into the MBR, because it's FreeBSD's boot loader that will be used to select which system to boot.

If you plan to install more than one OpenBSD system, you should start with OpenBSD and will need to install Grub as the boot loader. See the end of the OpenBSD install process for details.

Following disk partitioning, the install is basically the same as any other for both FreeBSD and OpenBSD. If FreeBSD is installed first, OpenBSD's disklabel may show FreeBSD partitions as i: through p: in some cases.

Linux with FreeBSD and or OpenBSD

When and how to install Red Hat 7.2 Linux in conjunction with either or both FreeBSD and OpenBSD depends primarily on the specific quirks of fdisk and Disk Druid. If you want control of Linux partitioning then you have no choice but to use Linux's fdisk. If the hard disk is brand new or has been wiped clean as described above, it probably makes no difference what order the install is done in. If the disk might contain old BSD disklabel data, then you should start with Linux and fdisk and there is no guarantee that it will work but at least you will know right away, and not after you've done another install. If fdisk starts with the "too many partitions (16, maximum is 8)" error message and displays old partition data, you have no choice but to wipe the disk clean (or to install a BSD system first and follow with Linux, using Disk Druid only). Even fdisk's 'o' option which normally clears all partition information won't function. The complete erase may seem extreme but I've gone so far as to use Disk Druid and done a complete Linux only, "full disk" install and even this did not succeed in erasing the BSD disklabel information. If fdisk starts with no error messages, your Linux install should complete without problems.

If Linux is going with FreeBSD, it makes no difference where either goes. With OpenBSD, it must be inside the 1024 cylinder limit and OpenBSD's disklabel will behave more reliably if the slice starts in cylinder 0. If you start with Linux, either leave the front of the disk open or create the slice for OpenBSD with Linux's fdisk. If Linux is set up first and the disk is clean, i.e., no pre-existiing BSD disklabel in the first slice, OpenBSD will detect the Linux partitions and they will be mountable from OpenBSD.

If there is any doubt about which BSD systems you intend to install or how much space you plan to give them, I suggest forcing Linux to install entirely within a single extended partition at the logical end of the disk. Disk Druid will warn you the system may not be bootable, make you confirm that you want to put the boot partition in the extended partition, and advise you to make an install floppy. This is advice you should follow.

Regardless of the state the disk is in, Disk Druid is not confused by FreeBSD or OpenBSD disklabels but has no ability to create any partition types except Linux. If you want to use Disk Druid, then you must install either or both FreeBSD and OpenBSD first, and use Disk Druid with the free space only option. If you start with Disk Druid before the hard disk has been partitioned, it will use slices needed by FreeBSD and or OpenBSD.

If you are definitely planning to install FreeBSD, Linux, and OpenBSD, but not two copies of any one, then either give FreeBSD two slices, leave an area unpartitioned and don't create the fourth slice, or use 3 slices to consume the whole disk. If an area is left unpartitioned, either FreeBSD or Linux, but not OpenBSD, will be able to use it later. Step by step setup instructions are provided for a triple boot system are provided in a separate section below.

You'll also have to decide where to put the GRUB boot loader. I strongly recommend changing the default and putting it in the first sector of the boot partition rather than in the MBR. If you put it in the MBR, you'll immediately be able to boot Linux from the hard disk. If you put it in the first sector of the boot partition and have installed Linux into a single extended partition, as I recommended, then you will definitely need the boot floppy to boot Linux the first time.

The reason that I recommend putting it in the first boot sector is that regardless of what any other subsequent installs do to the MBR, you'll always be able to boot Linux from the floppy. If you install GRUB in the MBR, and OpenBSD trashes it or you replace it accidentally with FreeBSD's boot loader, you won't be able to boot Linux even with the Linux boot floppy. If you do overwrite GRUB installed in the MBR, understand GRUB well enough, and have already made a GRUB boot floppy, then you can reinstall GRUB into the MBR with the floppy. You can also boot Linux directly from the GRUB floppy but won't be able to boot from the hard disk until GRUB is reinstalled into the MBR.

If you put GRUB in the first boot sector, other installs cannot prevent you from booting with the Linux floppy. As soon as you boot from the Linux floppy the first time, you can manually install GRUB into the MBR, and from then on boot Linux from the hard disk. You can also anticipate FreeBSD and OpenBSD installs by updating the /boot/grub/grub.conf file to boot whatever BSD systems you plan to install.

The surest way to install all three systems together on the same hard disk or just Linux and OpenBSD is to begin with a completely clean disk as discussed above. Install OpenBSD first, Linux next, and FreeBSD last. The drawback to this is using OpenBSD's fdisk program, and if you wish to mount any Linux partitions from OpenBSD, you'll need to figure out the manual commands to set this up. If Linux is installed before OpenBSD (but pyhsically after it on the disk), OpenBSD will recognize the Linux partitions. In OpenBSD's disklabel you will see partition letters between i: and p: and can mount the Linux partitions as soon as you log into the OpenBSD system with "#mount_ext2fs /dev/wd0n /mnt" or substituting for "n", whichever letters were displayed in disklabel.

If you do use OpenBSD's fdisk to allocate a slice for the current OpenBSD install, edit in CHS mode starting with cylinder 0, and mark the current slice active, unless GRUB is set up as the boot loader. If more than one copy of OpenBSD is being installed, change the previous slice type to the unknown a8, and start the next slice immediately after the preceding. Doing OpenBSD first on the first slice of a clean disk and subsequently on adjacent slices, assures that disklabel will correctly calculate starting offsets, properly use relative sizes rather than sectors only, align partitions on cylinder boundaries, and keep the disklabel partitions inside the current slice.

If you wish to mount Linux partitions later, there should be a manual method but I haven't looked for it. If a FreeBSD partition or partitions existed before installing OpenBSD and disklabel gave them a letter, the first partition within the FreeBSD slice can be mounted in OpenBSD with a plain mount command using the letter for the whole slice. The partition is readable but I'm not sure I'd trust OpenBSD to save updates reliably, becase there are some differences between OpenBSD and FreeBSD partitions.

It should be possible to create a DOS primary partition, or possibly in the extended partition, that will be visible to and mountable by all three systems to share data, but this is not an area I've explored as I think it pushes multi boot systems beyond the simple test systems for which multi booting is well suited; it starts to look like a permanent setup that would better be done on multiple disks or separate physical systems.

transparent spacer

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.

 
Home >
How-To >
Dual Boot >
combine.htm


What's New
How-To
Opinion
Book
                                       
Email address

Copyright © 2000-2014, George Shaffer. Terms and Conditions of Use.