Dual-Booting Two Linux Distributions

A genuinely different problem from grub1-6, not just an easier version of it. Windows and GRUB are two entirely separate bootloaders with a clean handoff between them. Two Linux distros both install the same bootloader family, each with its own package manager convinced it alone is responsible for keeping the boot configuration current.

Why This Is a Genuinely Different Problem

With Windows, GRUB chainloads to a completely foreign bootloader it doesn't understand or manage — clean separation, no conflict of ownership. With two Linux distros, both typically install their own copy of GRUB, and each distro's own package manager — apt on a Debian-based system, dnf on a Fedora-based one, pacman on Arch — considers itself responsible for regenerating "the" grub.cfg every time its own kernel updates. A genuine conflict of ownership, not a clean handoff.

What Actually Happens When You Install a Second Distro

The second distro's installer typically detects that GRUB is already installed, and either offers to install its own alongside it or asks directly which distro's GRUB should actually control the boot process. This matters structurally: only one GRUB installation can actually be the one occupying the MBR's boot sector or holding the primary EFI boot entry (grub1-5's own material). That one installation's own os-prober is what scans for and lists every other distro's kernels as additional menu entries.

os-prober Finding Multiple Kernels — Not Just Multiple OSes

grub1-2 distinguished 10_linux (lists every kernel for the current distro) from 30_os-prober (finds other operating systems entirely). For a second Linux distro specifically, os-prober generates entries that chainload directly to that other distro's own kernel and initramfs — a different kind of chainload target than grub1-6's own bootloader-level handoff to Windows. This arrangement is more efficient, but genuinely more fragile: it can break if the other distro's own kernel file gets renamed or removed by its own package updates without the authoritative distro's grub.cfg ever being regenerated to notice.

Choosing an Authoritative GRUB

Practical guidance: settle on one distro's GRUB installation as authoritative — commonly whichever was installed last, since it's naturally the one left controlling the boot sector or EFI entry — and let its own os-prober manage the real, in-use grub.cfg, rather than fighting over which one "should" be in charge. The other distro's own GRUB installation, once superseded, becomes effectively redundant for actual booting — though its own package manager has no idea, and will keep dutifully regenerating its own grub.cfg on every kernel update: a file that firmware simply never reads. This is exactly the "competing package managers each wanting to own the boot process" tension this chapter opened with.

The os-prober Update Timing Problem

A genuine, real gotcha: the authoritative distro's own grub.cfg only picks up a new kernel from the other distro once the authoritative distro's own update-grub is manually re-run. The other distro's own package manager updating its own kernel does not automatically trigger the authoritative distro's own regeneration — they're two entirely separate systems, with no coordination between them at all. This can leave a stale, "phantom" menu entry pointing at a kernel that's since been replaced or removed, until update-grub is deliberately re-run on the authoritative side.

Hands-On Exercises