Exercise 1: Why GRUB Can't Be One Single Piece of MBR Code — Possible Solution
====================================================================

Explanation:

The MBR only provides a tiny, fixed amount of usable space for boot
code -- 446 bytes, per grub1-1's own figure -- nowhere near enough
room to fit a full bootloader capable of understanding real
filesystems, parsing a configuration file, and drawing an interactive
menu. Real filesystem support alone requires far more code than that
tiny space can hold. GRUB solves this by not trying to fit everything
into that first tiny space at all -- instead, that space holds only
the smallest possible piece of code, just capable enough to find and
load something slightly bigger.

The two intermediate stages that make this work: boot.img, which
fits directly in the MBR and knows almost nothing except how to
locate the next stage, and core.img, a larger piece that follows
immediately after (in the small gap after the MBR, or a dedicated
BIOS Boot Partition), containing enough basic filesystem drivers to
finally read a real filesystem and load the full GRUB environment
from /boot/grub. Each stage only needs to be just capable enough to
load the next, larger one -- solving the space problem by never
requiring the full bootloader to exist anywhere as small as 446
bytes.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the specific space constraint (446 bytes) that makes a
single-stage bootloader impossible, then names both intermediate
stages and what each one is minimally capable of, rather than just
listing the stage names without explaining why they're necessary.