Exercise 2: journalctl -b -1 Returns Nothing After an Unexpected Reboot — Possible Solution
====================================================================

Most likely cause: persistent journal storage was never enabled on
this server, so the previous boot's own logs no longer exist at all.

Explanation:

Per the chapter's own material, "by default on many systems, the
journal lives in /run/log/journal/ -- RAM-backed, volatile, wiped
completely on reboot." If this server was never specifically
configured with persistent storage (via creating /var/log/journal/
with correct ownership, as the chapter describes), then the ENTIRE
journal from before the unexpected reboot -- not just some of it, all
of it -- was stored only in RAM, and was unavoidably lost the instant
the reboot happened, regardless of how the reboot itself was
triggered.

journalctl -b -1 specifically asks for logs from the boot immediately
before the current one. If that previous boot's own journal data was
volatile and got wiped when the reboot occurred, there is genuinely
nothing left anywhere on disk for journalctl to retrieve -- this isn't
a query syntax problem or a filtering issue, it's that the underlying
data the query is trying to read simply doesn't exist. The chapter's
own explicit warning applies directly here: "journalctl -b -1 only
works at all if persistent storage is actually configured" --
precisely the missing precondition in this scenario.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies the specific missing configuration (persistent
storage never enabled) as the root cause, explains why the volatile
default means the data is genuinely gone rather than just hard to
find, and directly cites the chapter's own explicit warning about
this exact precondition.