A device should keep a small, separate install history for its whole life, listing what was installed, when, from which source, and whether it fell back. System journals rotate and lose old entries, so a dedicated, size limited record is what lets you reconstruct a device's past in a support case or an investigation.
Why the journal is not enough
The RAUC documentation raises this directly. It says logs mostly go to stdout or the journal, which may be insufficient for keeping a long term history of what the updater changed on the system. A common problem is journal rotation: storage is limited, the journal holds a lot of other information, and it has to be rotated. The project notes you might want to preserve the history of installs, reboots, and fallbacks for a very long time, even the full life of the device. RAUC labels the details of its new log events as preview, so check current documentation before depending on them.
What to record
| Field | Example | Use |
|---|---|---|
| Time | Device clock plus a monotonic counter | Ordering when the clock is wrong |
| Event | Installed, confirmed, fell back, rejected | The story |
| From and to release | 4.1.0 to 4.2.1 | Inventory reconstruction |
| Image hash | Hash of the installed image | Exact identity |
| Source | Update server or local media | Provenance |
| Result and reason | Success or error code | Debugging |
| Slot | A or B | Which copy runs |
Keep each entry small. A few hundred bytes per event is plenty.
Design steps
- Put the history in a place that survives updates, such as a data partition.
- Make it append only from the updater, and not writable by ordinary applications.
- Cap its size with a rule that keeps the oldest and the newest entries, since both matter.
- Include the history in the check-in, or at least the latest entries and a running hash.
- Test power loss during a write so the file is never left unreadable.
- Document who may read it, because it can reveal when a device was off or moved.
Why a fleet owner cares
When a customer asks "was this unit ever on release 3.9", you can answer. When an advisory affects an old release, you can find devices that passed through it, which matters if a vulnerable component left behind data or credentials. It also supports reporting: time from release to install on each device is a fleet metric, and the data comes from here.
Safeguard stores SBOMs per release and keeps matching them to advisories, and the device history tells you which of your devices ran which release. Start with the free scan at gold.safeguard.sh/scan.
Privacy and size
A lifetime history is personal data in some products, because it can show when a device was in use or moved between owners. Keep it free of user content, limit who can read it, and say in your privacy notice what is stored. On the technical side, a trimmed, capped file is safer than an open ended log that can fill storage and block the next update.
Quick check
Is the system journal a good enough update history?
Usually not, because it rotates and mixes in unrelated entries. Keep a separate record.
How big should the history file be?
Small and capped. Keep both the oldest and newest entries when trimming.
Sources
Last reviewed: 19 October 2026.
