Exercise 1: Why a Partition Table Entry Can't Reveal the Filesystem Inside — Possible Solution
====================================================================

Explanation:

Per the chapter's own core distinction, a partition table (whether MBR
or GPT, per grub1-5's own material) only records WHERE a partition
begins and ends on the disk -- its starting sector, its size, and a
type code -- along with basic metadata about the partition boundary
itself. It has no awareness of, and makes no attempt to describe, the
actual internal STRUCTURE of the bytes living between those boundaries.

The filesystem is a completely separate layer, imposed entirely
within the space the partition table merely reserves -- inodes,
superblocks, directory structures, and file data are all written
INSIDE that reserved space by a tool like mkfs, at a later, distinct
step. The partition table has already finished its own job (marking
off a region of the disk) before a filesystem is ever created there,
and continues to know nothing about what mkfs subsequently does inside
that region. This is exactly why the chapter is explicit that "a
partition table entry says nothing about what kind of data actually
lives inside a given partition" -- the two are genuinely separate
concerns, handled by separate tools, at separate times, with the
partition table having no visibility into the filesystem layer at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the layered relationship directly (partition table
reserves space; the filesystem is imposed inside that space by a
separate, later operation), rather than simply restating that they're
different things without explaining why one has no knowledge of the
other.