Exercise 3: Why fsck on a Live Mounted Root Filesystem Is Dangerous — Possible Solution
====================================================================

-- Why this is dangerous --
--
-- Per the chapter's own warn-box, "running fsck against a filesystem
-- that's currently mounted and actively being written to can itself
-- CAUSE corruption -- the exact opposite of the intended effect." The
-- fundamental problem is that fsck's own consistency check assumes
-- the filesystem's own on-disk state stays fixed while it examines
-- it -- it reads structures, cross-checks them against each other,
-- and potentially rewrites parts of them to fix inconsistencies it
-- finds. If the system is running normally on that same mounted
-- filesystem at the same time, ordinary processes are simultaneously
-- creating, modifying, and deleting files, changing the exact
-- on-disk structures fsck is in the middle of examining and
-- potentially altering. fsck could easily see a genuinely
-- inconsistent, half-updated view of the filesystem purely because
-- something else changed it mid-check -- and "repair" based on that
-- momentarily-inconsistent snapshot, actually introducing damage that
-- didn't exist before the check began, rather than fixing anything
-- real.

-- The correct alternative approach --
--
-- Per the chapter's own explicit guidance, for a root filesystem
-- that genuinely can't simply be unmounted while the system is
-- running (since the root filesystem holds the running system
-- itself), the correct approach is to boot into a live/rescue
-- environment instead -- directly reusing grub1-9's own chroot-rescue
-- material, booting from external media so the root filesystem in
-- question is no longer the ACTIVE root and can be mounted (but not
-- actively used by a running system) from outside, where fsck can
-- then safely check and repair it with nothing else simultaneously
-- modifying it.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the actual mechanism of the danger (fsck assumes a
static view while running processes keep changing the live
filesystem underneath it) rather than just citing the warning, and
gives the specific correct alternative the chapter names (a live
rescue environment, tying back to grub1-9) rather than a vague
"be more careful."