Exercise 2: What Goes Wrong When mdadm.conf Is Skipped — Possible Solution
====================================================================

What's likely to go wrong, and when:

Per the chapter's own tip-box, "Run mdadm --detail --scan >>
/etc/mdadm/mdadm.conf immediately after mdadm --create succeeds --
it's easy to forget once the array is already working, and the gap
only becomes visible at the worst possible time: the next reboot."
The key detail is exactly WHEN this becomes a problem: not immediately.
The array the administrator just created, formatted, and mounted will
continue working completely normally for as long as the system stays
running, since the kernel already has the array assembled and active
in memory -- nothing about skipping mdadm.conf affects the array's
current, already-running state.

The problem surfaces specifically at the next reboot. Per the chapter,
"without writing the array's own configuration to mdadm.conf, the
array may not reassemble correctly -- or with the wrong device
ordering -- on the next reboot." When the system boots back up, mdadm
needs to know which physical devices belong together as an array and
how; without that configuration recorded in mdadm.conf, the boot
process may fail to reassemble the array at all, or may assemble it
with a different device numbering than before (e.g. what was /dev/md0
before might come up differently), silently changing what device path
represents the array and potentially causing anything referencing the
old path (an fstab entry, a mount script) to fail to find it.

Because this gap is invisible while the system stays up and only
manifests on the next reboot -- which could be days, weeks, or months
later, for entirely unrelated reasons like a kernel update or a power
outage -- it's a genuinely easy mistake to make and forget about,
exactly as the chapter's own tip-box warns.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies the specific delayed timing of the failure (works
fine now, breaks specifically at the next reboot) rather than a vague
"it might not work," and explains the underlying reason (mdadm has no
persisted record of the array to reassemble it correctly) using the
chapter's own tip-box.