Re: [PATCH manager] report: list recent reboot events and their kernel version

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

Am 20.07.26 um 16:58 schrieb Alexander Zeidler:
> On Mon Jul 20, 2026 at 3:33 PM CEST, Maximiliano Sandoval wrote:
>> Thomas Lamprecht <t.lamprecht@proxmox.com> writes:
>>> For just the boots we could use "journalctl --list-boots -n 5 -r".
>>> Depending on wtmpdb and writing yet another log file just for kernel version might
>>> be a bit overkill, given that the info is there in the journal, albeit it *is*
>>> annoying that we would have to manually parse them from the journal...
>>
>> For the purposes of support we are more interested about the kernel
>> version used each boot. It would be interesting to have info about the
>> BOOT IDs or having the timestamp of the last entry for a give boot
>> though.
>>
>> Another consideration of journalctl is that the boots might be rotated
>> away.
> 
> While the mentioned `journalctl --list-boots -n 5 -r` does not include
> the booted kernel versions, it lists at least a close timestamp of the
> crash.
> 
> I am not aware of a rotation issue, i.e., I think any rotation may apply
> to the same extent to `wtmpdb` and `last`. Although a minor problem can
> be when using e.g. the following command and there was no reboot since
> then. But in such seldom cases we likely have to ask for more specific
> journal information anyway.
> 
> `journalctl --since "3 months ago" -g "Command line:|Journal stopped" -q | tail`
> 
> The command is limited to 3 months, since the query can take several
> seconds for journals that are flooded with entries. The advantage is,
> that it also contains the kernel command lines used. A crash timestamp
> is not available, but boot timestamps (usually shortly after finally
> crashed) and whether a reboot/shutdown was performed gracefully.
FWIW, we already got proxmox-mini-journalreader and it can already produce
json that we could extend to produce the relevant info, i.e. iterating through
boots (IIRC that is a indexed table) and parser first Line to extract the
kernel. That could then be outputted as structured JSON there which can be
parsed by the report here. In the midterm we could even think about integrating
that as fully fledged API to our products API, if it can provide value as first
class boot + kernel list there. For now just parsing the json in the report
would be more than enough (or CLI only integration as middleground).

You can try "poaching" one of our Devs that isn't to afraid from a bit of
C to implement this, would be probably the safest course be here, especially
as we maintain the journald handling already anyway.