No one else has answered this, so I'll step in and try. The answer is "Yes ... but ...."
Multibooting is not always easy to provision, and may require administrative skills you do not have... as you are asking the question. Administrative or operational mistakes can cause data loss.
Here are some of the things to consider when provisioning multibooting. This is not a complete list.
- Does the hardware architecture provide the ability to deploy an OS-independent bootloader or an OS-specific bootloader which can load other OSes?
- Does the architecture provide a multi-OS partitioning schema that can be used by these particular OSes?
- Example: For MBR architectures, the answer is "yes". For GPT architectures, the answer is "not yet, but soon, for OpenBSD." For non-MBR/non-GPT architectures, the answer is "no."
- Is the partitioning schema flexible enough for these OSes?
- For MBR architectures, the answer is "it depends."
- MBRs are limited to 4 primary partitions, extended partitions provide some additional flexibility but mapping of these partitions requires careful planning, due to how they are nested.
- MBRs partitions are limited to the first 2TB of a drive, but the BIOS may require boot blocks to be located much closer to the start of the drive. (On some older 32-bit x86 machines, this limit may be as low as within the first 504MB.)
- These BIOS restrictions may limit usefulness or add significant complexity.
- You are unlikely to discover BIOS restrictions until an installation fails to boot. Motherboard vendors do not publish them, and there is no "standard" to rely upon.
- It may be difficult, or impossible, to relocate all OS boot blocks within the BIOS addressable range limit.
- The BSDs use disklabels which are independent of the MBR partition assigned to each OS, while Linux uses MBR partitions.
- PC-BSD and DragonflyBSD share the same MBR partition type - 0xA5. Careful planning will be needed to support bootloading with multiple MBR partitions of the same type. Not only booting -- you must ensure the disklabel from one of these systems does not interfere with the disklabel of the other.
In general, it is easier to use separate disk drives for these separate systems, or run them as guest OSes in a virtual machine hypervisor.
(Edited to add a bunch of clarity and a discussion of both > 2TB and boot block location restrictions with MBRs.)