Multi-Boot With More Than Two OSes & Advanced Partitioning

grub1-6 and grub1-7 established two chainloading mechanisms for two different kinds of neighbor. This chapter shows they don't need reinventing for a third, fourth, or fifth operating system — they combine and scale directly — and goes deeper on partitioning strategy for a genuinely complex layout.

Generalizing to Three or More Operating Systems

The underlying mechanisms don't change with more operating systems on the disk: one authoritative GRUB installation (grub1-7's own principle), os-prober scanning every other partition (grub1-2/grub1-6/grub1-7), each additional OS adding one more menu entry via whichever mechanism actually fits it. What genuinely grows with more OSes: install order matters even more — grub1-6's own "Windows first" lesson generalizes into "install every uncooperative OS first, Linux/GRUB last," so GRUB ends up as the final, authoritative bootloader regardless of how many neighbors it has — and os-prober's own scan simply has more partitions to check, with correspondingly more opportunity for something to go wrong.

A Dedicated /boot Partition — Why and When

In a genuinely complex multi-OS layout, keeping /boot as its own small, separate partition — rather than folded into the root filesystem — has real advantages, building on grub1-5's own material: it guarantees GRUB is working with a filesystem it definitely understands (plain ext2/ext4), sidestepping any support gap with a more exotic root filesystem, and keeping it small and separate means it survives a root-filesystem reinstall or reformat completely untouched. This becomes genuinely more valuable specifically once three or more OSes share a disk, where "just reinstall this one distro" is a real, common temptation that gets riskier the more entangled /boot is with root.

Chainloading — the Generalized Mechanism

grub1-6's chainload-to-a-foreign-bootloader and grub1-7's chainload-to-a-kernel-directly are two flavors of exactly the same underlying idea: GRUB's own general-purpose "hand control to this other thing" mechanism. This is precisely what lets an arbitrary number of operating systems share one boot menu without GRUB ever needing to understand any of their internals beyond locating the right file to hand off to.

A Three-Way Example — Debian + Fedora + Windows

• Partition layout: one shared EFI System Partition, a Debian root partition, a Fedora root partition, a Windows NTFS partition
• Install order: Windows first, then Fedora, then Debian last — leaving Debian's own GRUB as the final, authoritative installation
• The resulting menu: native entries for every Debian kernel (via 10_linux), a chainload-to-kernel entry for Fedora (grub1-7's own mechanism), and a chainload-to-bootloader entry for Windows (grub1-6's own mechanism) — all generated automatically by Debian's own os-prober, none hand-written

LVM Considerations — Deferred, Not Covered

Logical Volume Manager (LVM) is a genuinely common, flexible way to manage disk space across multiple partitions and operating systems, and GRUB does have real LVM support of its own (a module, the same kind of thing grub1-2 described GRUB carrying for filesystems and partition schemes generally). But LVM's own concepts — physical volumes, volume groups, logical volumes — are substantial enough to deserve their own dedicated treatment, exactly what this site's own still-outstanding "Linux filesystems" bucket-list topic exists for. Named honestly here as a real, acknowledged gap in this course's own scope, not silently skipped over.

Hands-On Exercises