Capstone — Building a Real Triple-Boot Test Environment

GRUB & Multibooting

Chapter 10 · Capstone — Building a Real Triple-Boot Test Environment

The final chapter. One virtual machine, one virtual disk, three real operating systems — built in the correct order, configured properly, deliberately broken, and repaired using exactly the procedure grub1-9 taught. A disposable VM is exactly the right place to intentionally break something you already know how to fix.

The Environment — Three OSes, One Shared Disk

A single VM (VirtualBox or QEMU, tool-agnostic), UEFI firmware enabled in its settings, one virtual disk — this is how real triple-boot actually works: one machine, one disk, three operating systems sharing it, not three separate machines.

Step 1 — Partition Planning

GPT, matching grub1-5's own recommended UEFI pairing. Layout: one shared EFI System Partition (grub1-6's own material), a Windows NTFS partition, a Fedora root partition, and Debian's own root partition plus a dedicated /boot partition — grub1-8's own advanced-partitioning recommendation, applied for real this time rather than just described.

Step 2 — Install Order

Windows first, Fedora second, Debian last — grub1-8's own generalized rule applied directly: every uncooperative OS first, Linux/GRUB last, leaving Debian as the final, authoritative installation.

Step 3 — Confirming the Menu

GNU GRUB Debian GNU/Linux Advanced options for Debian GNU/Linux Fedora Linux (chainload to kernel) Windows Boot Manager (chainload to bootloader)

Booting after Debian's install should show exactly this shape: native Debian kernel entries generated by 10_linux, a Fedora entry chainloading directly to its own kernel and initramfs (grub1-7), and a Windows entry chainloading to its own bootloader (grub1-6) — all produced automatically by Debian's own os-prober, none hand-written.

Step 4 — Applying Chapters 3 and 4's Own Configuration

GRUB_DEFAULT=saved GRUB_TIMEOUT=10 GRUB_TIMEOUT_STYLE=menu GRUB_SAVEDEFAULT=true

grub1-3's own workflow, applied deliberately: a real triple-boot menu needs a genuinely usable timeout, not the single-OS GRUB_TIMEOUT=0 default. Run update-grub to apply it. Then, as a direct test of grub1-4's own live-edit workflow, press e on the Fedora entry, confirm it's genuinely editable exactly as it was for a single-OS menu, and back out with Esc — confirming the live-edit workflow still behaves correctly in this more complex environment.

Step 5 — Deliberately Breaking It

Boot into Windows and simulate grub1-6's own gotcha directly — reset the UEFI boot order, or use Windows's own boot-repair tooling, so Windows becomes the sole boot target. Reboot: the three-way menu is gone, the system boots straight into Windows. Exactly grub1-6's own scenario, now reproduced on purpose, in an environment safe to break.

Step 6 — The Rescue, Applied for Real

  1. Boot the Debian live USB image (the same media from Step 2's own install)
  2. Mount Debian's root partition and its EFI System Partition
  3. Bind-mount /dev, /proc, /sys; chroot in
  4. grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
  5. update-grub
  6. Exit, unmount, reboot, remove the media

grub1-9's own five-step procedure, applied end to end for real — and the full three-way menu, Debian/Fedora/Windows entries and all, is back.

PieceChapter
GPT + UEFI, shared EFI System Partitiongrub1-5, grub1-6
Dedicated /boot partitiongrub1-8
Install order (uncooperative OSes first)grub1-6, grub1-8
10_linux / os-prober-generated menugrub1-2, grub1-6, grub1-7
Permanent GRUB_TIMEOUT/GRUB_DEFAULT configgrub1-3
Live edit verification via 'e'grub1-4
The deliberate break (simulated Windows overwrite)grub1-6
The full chroot + grub-install rescuegrub1-9
Still out of scope, honestly
This capstone deliberately skips LVM — deferred back in grub1-8 to the site's own still-outstanding "Linux filesystems" topic, not covered here either. Secure Boot enrollment is likewise not tested end to end here — grub1-5's own light-touch preview stands as this course's full coverage of it. And this is a genuinely manual, hands-on lab exercise, not an automated, idempotent build — deliberately not what ansible1's own capstone did, since GRUB's own configuration isn't really automatable the same way service configuration is; a full VM rebuild means repeating these steps by hand, not re-running a playbook. Finally, this is VM-only — a real, stated limitation distinct from testing against actual physical hardware, where firmware quirks can behave differently than a hypervisor's own UEFI implementation.

Hands-On Exercises

Exercise 1

Explain why the partition layout in Step 1 gives Debian and Fedora each their own root partition, but only one shared EFI System Partition between all three operating systems.

📄 View solution
Exercise 2

Explain what would likely have gone wrong in Step 3's own confirmation step if the install order in Step 2 had instead been Debian, then Fedora, then Windows.

📄 View solution
Exercise 3

A reader asks why this capstone doesn't just write an Ansible playbook (per the site's own ansible1 course) to automate the whole triple-boot build. Give an honest answer using this chapter's own scope note.

📄 View solution

Chapter 10 Quick Reference — GRUB & Multibooting Complete

  • One VM, one disk, GPT + UEFI, a shared EFI System Partition, a dedicated Debian /boot — the real-world shape of triple-boot
  • Install order: Windows → Fedora → Debian, leaving Debian's own GRUB authoritative
  • The resulting menu combines native entries, a chainload-to-kernel entry, and a chainload-to-bootloader entry — all auto-generated
  • grub1-3's permanent config and grub1-4's live-edit workflow both verified working in the more complex environment
  • The deliberate break (simulating grub1-6's own Windows-overwrite gotcha) and its repair (grub1-9's own five-step chroot rescue) close the loop for real
  • Honest scope note: no LVM, no Secure Boot enrollment tested end to end, a manual (not automated) build, VM-only
  • The full GRUB & Multibooting course — 10 chapters — is now complete.