Exercise 3: Why rescue.target Can Succeed When the Normal Boot Chain Is Broken — Possible Solution
====================================================================

Explanation:

Per this chapter's own explanation of grub1-4's kernel parameter,
systemd.unit=rescue.target tells systemd to boot directly to
rescue.target "instead of the normal default, bypassing
graphical.target's/multi-user.target's own much larger set of
Wants=/Requires= dependencies entirely." rescue.target is, by design,
a minimal target -- per this chapter's own compare-table, it
corresponds to single-user/minimal recovery mode, requiring only a
small handful of essential units (enough for a basic root shell) to
be considered "reached."

If something is broken elsewhere in the normal boot chain -- a
misconfigured service that graphical.target or multi-user.target
requires, a broken network configuration, a failing custom unit that
would normally be pulled in as a dependency of the default target --
that broken unit is very likely part of the much larger dependency set
those two targets pull in, but is NOT part of rescue.target's own,
deliberately minimal dependency set. Since reaching a target (per
systemd1-4's own definition) means everything THAT target itself
requires/wants has started -- not everything on the system in general
-- rescue.target can be reached successfully precisely because it
never asks systemd to start the broken unit in the first place. The
much smaller set of things rescue.target actually depends on can
still all start correctly, even while something entirely unrelated to
rescue.target's own minimal requirements remains broken.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the mechanism precisely: rescue.target succeeds not
because it somehow "fixes" or bypasses the broken component, but
because its own deliberately small dependency set simply never
includes the broken unit in the first place, directly applying
systemd1-4's own definition of what "reaching a target" actually
means.