Exercise 2: What Happens (and Doesn't) When the Non-Authoritative Distro Updates Its Kernel — Possible Solution
====================================================================

-- What happens --
--
-- Distro B's own package manager installs the new kernel files onto
-- its own partition, and, per the chapter's own description of
-- non-authoritative distros, Distro B's own GRUB installation
-- dutifully regenerates ITS OWN grub.cfg to include the new kernel --
-- a file that firmware never actually reads, since Distro B isn't the
-- one occupying the boot sector/EFI entry.

-- What does NOT happen --
--
-- The AUTHORITATIVE distro's own grub.cfg -- the one actually
-- controlling the boot menu everyone sees -- is completely unaffected
-- by this update. Per the chapter's own "update timing problem"
-- section, the two distros' package managers have no coordination
-- with each other at all; Distro B updating its own kernel does not
-- trigger the authoritative distro's own update-grub to run. The
-- visible boot menu keeps showing whatever menu entry os-prober
-- generated for Distro B during the LAST time the authoritative
-- distro's own update-grub ran -- which may now point at a kernel
-- file that Distro B has since replaced or removed, producing exactly
-- the "phantom" stale entry the chapter describes.

-- The specific fix --
--
-- Run update-grub (or the local equivalent) on the AUTHORITATIVE
-- distro specifically -- not on Distro B, since regenerating Distro
-- B's own unused grub.cfg does nothing for the actual boot menu.
-- Running it on the authoritative side triggers its own os-prober to
-- rescan, discover Distro B's new kernel, and regenerate the real,
-- in-use grub.cfg with an updated, correct entry.

WHY THIS WORKS AS AN ANSWER
------------------------------
This separates what actually happens (Distro B regenerates its own
unread grub.cfg) from what the user would actually experience (a
stale menu entry, since the authoritative grub.cfg is untouched), and
names the specific, correctly-targeted fix (update-grub on the
authoritative side, not the updated distro) rather than a vague "run
update-grub somewhere."