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