Persistent journal: the stale boot clock sets the previous boot aside as .journal~; how to read it
/ crosscheck (push) Successful in 1s

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DDwfd6Ki8UfG4hK6W5YpJz
This commit is contained in:
2026-10-13 23:04:36 +09:00
parent 00082ac491
commit 47ba62bb17
+19
View File
@@ -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.