Exercise 3: A Hand-Edited grub.cfg Change That Vanishes Three Weeks Later — Possible Solution
====================================================================

Explanation:

This is precisely the delayed-onset mistake the chapter's own
warn-box describes. When the change was first hand-edited directly
into grub.cfg, nothing regenerated the file at that moment, so the
edit sat there unchanged and appeared to work correctly -- there was
no immediate signal that anything was fragile about this fix.

Three weeks later, a routine kernel update ran, which -- per this
chapter's own explanation of 10_linux and the kernel-update-triggers-
-regeneration relationship -- caused update-grub/grub-mkconfig to run
again automatically as part of that update's own post-install steps.
grub-mkconfig doesn't read or preserve the PREVIOUS grub.cfg's own
content at all -- it builds an entirely new grub.cfg from scratch
every time, using only /etc/grub.d/'s scripts and /etc/default/grub's
settings as its source of truth. Since the hand-edited default-boot-
-entry change was never recorded in either of those actual source
locations -- it only ever existed as a direct, one-off edit to the
generated output file itself -- the freshly regenerated grub.cfg had
no way to know that change should be preserved, and it was silently
overwritten along with everything else in the file, including the
new kernel's own auto-generated entry from 10_linux.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the full causal chain -- the edit surviving until a
kernel update triggers regeneration, and grub-mkconfig rebuilding
grub.cfg from its real source files rather than preserving prior
edits -- rather than just saying "it got overwritten" without
explaining the underlying mechanism or the exact trigger.