Persistent journal: the stale boot clock sets the previous boot aside as .journal~; how to read it

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DDwfd6Ki8UfG4hK6W5YpJz

docs/impl/reports/PERSISTENT-JOURNAL.md

@@ -58,4 +58,23 @@ was a hang or a power loss; the last kernel messages before the gap are the lead
 Timestamps of an early boot can be off until NTP or GPS sets the clock (no RTC
 battery), so order by `-o short-monotonic` within a boot.
 
+### The previous boot hides behind the stale clock
+
+Seen on the first reboot after enabling it (2026-10-13): `journalctl --list-boots`
+showed only the new boot. With no RTC battery the clock starts at 2025-06-04, and
+`fake-hwclock` only puts it right about 11 s in. The kernel and early-boot entries
+logged before that carry 2025 times; flushed after the previous boot's 2026
+entries, they make journald set the old file aside as `system@….journal~`, which
+`journalctl` skips by default. Nothing is lost (that boot's log ends cleanly in
+`Shutting down` / `Journal stopped`); it has to be named:
+
+```bash
+journalctl --file '/var/log/journal/*/system@*.journal~' --list-boots
+journalctl --file '/var/log/journal/*/system@*.journal~' -e      # how that boot ended
+```
+
+Every boot does this until the clock survives power-off: the RTC backup battery
+(project-yukart roadmap, Phase 0) is the fix. Early-boot entries of each boot also
+read 2025-06-04; within a boot, `-o short-monotonic` orders them truthfully.
+
 Only the car unit (`mikkeli-orin-nano`) has this. The development Orin is unchanged.