You have several options, but which is best depends on details you haven't specified:
- Use logical partitions -- The most conventional approach is to create an extended partition, which can hold as many logical partitions as you like. See Chapter 5 of the Linux System Administrators' Guide or this SuperUser question and its answers for more on this subject. In brief, the MBR partitioning scheme supports up to four primary partitions, one of which may be an extended partition, which serves as a placeholder for an arbitrary number of logical partitions. Linux doesn't care about primary/logical partition types, even for boot purposes, so you can create as many logical partitions as you like to suit your needs. The most common caveat is that if a disk already has four primary partitions, one of them must be deleted or converted to logical form before you can create logical partitions. My
fixparts program, which is usually installed in a package called gdisk or gptfdisk, can do the conversion. See the official FixParts documentation for details. There are also issues of placement -- you cannot have a primary partition in-between logical partitions. Finally, standard Windows partitioning tools are a menace on any disk that uses logical partitions, although the OS itself handles them fine. Thus, you must be careful to not use the standard Windows partitioning tools if you use logical partitions.
- Use LVM -- This approach is similar to the preceding one, but it has more limitations from the point of view of this discussion. Logical Volume Management (LVM) is a way to take one or more partitions or raw disk devices (both of which are called physical volumes in LVM-speak) and carve it up into logical volumes, which work much like partitions. Thus, you could set aside a partition on your disk as an LVM physical volume and create as many logical volumes as you need. The big limitation compared to logical partitions is that it may be harder to boot from a logical volume. Although GRUB can theoretically boot from a kernel stored in a logical volume, most distributions like to see a separate
/boot partition when LVM is in use. Also, most non-Linux OSes can't read Linux LVMs, so this is not a good solution for shared data space. OTOH, LVM is much more flexible than regular partitions, so if you regularly add, delete, or resize storage, using LVM is a big plus. Note that you can use a logical partition as a physical volume, so this solution is not mutually exclusive with the preceding one.
- Convert to GPT -- If Windows is not booting from your hard disk, you can convert it from MBR to use the GUID Partition Table (GPT). GPT doesn't distinguish between primary, extended, and logical partitions, and it supports up to 128 partitions by default. (You can raise that limit, if necessary.) Linux can boot fine from GPT disks even in BIOS mode, with the caveat that a few BIOSes choke on GPT disks. GPT is also the default if your computer is new enough to have EFI firmware. (Most computers introduced since late 2011 have such firmware.) Thus, if your computer is new, you could convert to GPT and boot in EFI mode, with the big caveat that you'd need to either convert Windows to boot in EFI mode (using this Windows tool) or deal with booting Linux in EFI mode and Windows in BIOS mode (which is awkward). Windows prior to Vista SP1 and some older OSes can't handle GPT at all, and no version of Windows can boot from GPT in BIOS mode without jumping through hackish hoops (although Windows requires GPT to install in EFI mode). Thus, using GPT is a good option if you don't need to boot Windows from the disk in BIOS Mode or access the disk from older OSes; but it's not an option at all if you need to boot Windows in BIOS mode. Using GPT is mutually exclusive with using logical partitions, but you can use LVM on a GPT partition, so you can combine those two methods, if you like. My GPT fdisk documentation covers GPT issues in more detail, including how to convert an existing disk from MBR to GPT.
You haven't provided enough detail for me to know which of these options would be best for you. The safest approach, given the information you have presented, is likely to be to use logical partitions. Depending on the distributions you install, you may need to set up an extended partition before you begin, or the installer might help with that. Using GPT is likely to create enough follow-on problems that it's not worth it, but I can't be positive of that. Especially if you've got a relatively new computer, using GPT and booting in EFI mode may provide some advantages, so it might be worth considering if you're willing to re-install Windows or risk converting its boot mode. My guess, though, is that you'd be better off sticking with MBR and use logical partitions.
If you'll be working with multiple distributions, and especially if you expect to be changing the mix in the future, I recommend using LVM, probably in conjunction with logical partitions or a conversion to GPT. I like to set up several 500-1000MB partitions to be used as /boot partitions, then leave the rest of the Linux space in one or more LVM partitions. (Setting up several LVM partitions makes it relatively easy to re-allocate some of the LVM space to non-Linux use in the future, should the need arise.) OTOH, LVM has a moderate learning curve, so if you're just starting out, it may not be a good option. Then again, some distributions, like Fedora, use LVM by default, so you may end up using it even if you didn't intend to do so. Also, booting multiple Linux distributions has a significant learning curve to begin with.
That last point raises another possibility: Instead of multi-booting, you might want to consider using virtualization, like VirtualBox or VMware. You can set up as many virtual machines as you like within your primary OS. This enables you to run them side-by-side and it means you won't need to deal with multi-boot issues. This approach has drawbacks, particularly if you need direct low-level hardware access in all your OSes, but it's much easier than trying to multi-boot half a dozen or more OSes.
