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

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

[Alexander Zeidler]

Based on the most recent reboot events, it is possible to determine
whether and when a crash, fencing, or reboot occurred and with which
kernel version the node booted.

Use `wtmpdb last` as a replacement for the well-known `last`, since
the latter became obsolete [0] with Debian Trixie / PVE 9.

 # wtmpdb last reboot --fulltimes --limit 5
 reboot   system boot  7.0.14-5-pve     Mon Jul 20 14:22:34 2026 - still running
 reboot   system boot  7.0.14-5-pve     Thu Jul 16 15:12:16 2026 - crash
 reboot   system boot  7.0.14-5-pve     Thu Jul 16 11:20:15 2026 - Thu Jul 16 15:10:46 2026  (03:50)
 reboot   system boot  7.0.14-5-pve     Wed Jul 15 13:39:34 2026 - crash
 reboot   system boot  7.0.14-2-pve     Wed Jul 15 07:39:18 2026 - Wed Jul 15 13:38:04 2026  (05:58)

 wtmpdb begins Wed Jul 15 07:39:18 2026

[0] https://www.debian.org/releases/trixie/release-notes/issues.html#the-last-lastb-and-lastlog-commands-have-been-replaced

Signed-off-by: Alexander Zeidler <a.zeidler@proxmox.com>
---
 PVE/Report.pm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/PVE/Report.pm b/PVE/Report.pm
index 29433d4a..6049c0bf 100644
--- a/PVE/Report.pm
+++ b/PVE/Report.pm
@@ -36,6 +36,7 @@ my $init_report_cmds = sub {
                 'hostname',
                 'date -R',
                 'cat /proc/cmdline',
+                'wtmpdb last reboot --fulltimes --limit 5',
                 'pveversion --verbose',
                 'cat /etc/hosts',
                 'pvesubscription get',
-- 
2.47.3

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

[Thomas Lamprecht]

Am 20.07.26 um 14:38 schrieb Alexander Zeidler:
> Based on the most recent reboot events, it is possible to determine
> whether and when a crash, fencing, or reboot occurred and with which
> kernel version the node booted.
> 
> Use `wtmpdb last` as a replacement for the well-known `last`, since
> the latter became obsolete [0] with Debian Trixie / PVE 9.
> 
>  # wtmpdb last reboot --fulltimes --limit 5
>  reboot   system boot  7.0.14-5-pve     Mon Jul 20 14:22:34 2026 - still running
>  reboot   system boot  7.0.14-5-pve     Thu Jul 16 15:12:16 2026 - crash
>  reboot   system boot  7.0.14-5-pve     Thu Jul 16 11:20:15 2026 - Thu Jul 16 15:10:46 2026  (03:50)
>  reboot   system boot  7.0.14-5-pve     Wed Jul 15 13:39:34 2026 - crash
>  reboot   system boot  7.0.14-2-pve     Wed Jul 15 07:39:18 2026 - Wed Jul 15 13:38:04 2026  (05:58)
> 
>  wtmpdb begins Wed Jul 15 07:39:18 2026
> 
> [0] https://www.debian.org/releases/trixie/release-notes/issues.html#the-last-lastb-and-lastlog-commands-have-been-replaced
> 
> Signed-off-by: Alexander Zeidler <a.zeidler@proxmox.com>
> ---
>  PVE/Report.pm | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/PVE/Report.pm b/PVE/Report.pm
> index 29433d4a..6049c0bf 100644
> --- a/PVE/Report.pm
> +++ b/PVE/Report.pm
> @@ -36,6 +36,7 @@ my $init_report_cmds = sub {
>                  'hostname',
>                  'date -R',
>                  'cat /proc/cmdline',
> +                'wtmpdb last reboot --fulltimes --limit 5',

we nowhere depend on wtmpdb so it's not a given that it's installed.

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...


>                  'pveversion --verbose',
>                  'cat /etc/hosts',
>                  'pvesubscription get',

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

[Maximiliano Sandoval]

Alexander Zeidler <a.zeidler@proxmox.com> writes:

> Based on the most recent reboot events, it is possible to determine
> whether and when a crash, fencing, or reboot occurred and with which
> kernel version the node booted.
>
> Use `wtmpdb last` as a replacement for the well-known `last`, since
> the latter became obsolete [0] with Debian Trixie / PVE 9.
>
>  # wtmpdb last reboot --fulltimes --limit 5
>  reboot   system boot  7.0.14-5-pve     Mon Jul 20 14:22:34 2026 - still running
>  reboot   system boot  7.0.14-5-pve     Thu Jul 16 15:12:16 2026 - crash
>  reboot   system boot  7.0.14-5-pve     Thu Jul 16 11:20:15 2026 - Thu Jul 16 15:10:46 2026  (03:50)
>  reboot   system boot  7.0.14-5-pve     Wed Jul 15 13:39:34 2026 - crash
>  reboot   system boot  7.0.14-2-pve     Wed Jul 15 07:39:18 2026 - Wed Jul 15 13:38:04 2026  (05:58)
>
>  wtmpdb begins Wed Jul 15 07:39:18 2026
>
> [0] https://www.debian.org/releases/trixie/release-notes/issues.html#the-last-lastb-and-lastlog-commands-have-been-replaced
>
> Signed-off-by: Alexander Zeidler <a.zeidler@proxmox.com>

Thanks.

It is **very** common to ask for `last` output in Enterprise Support,
this would be very helpful to avoid unnecessary round-trips.

Reviewed-by: Maximiliano Sandoval <m.sandoval@proxmox.com>

-- 
Maximiliano

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

[Maximiliano Sandoval]

Thomas Lamprecht <t.lamprecht@proxmox.com> writes:

> Am 20.07.26 um 14:38 schrieb Alexander Zeidler:
>> Based on the most recent reboot events, it is possible to determine
>> whether and when a crash, fencing, or reboot occurred and with which
>> kernel version the node booted.
>> 
>> Use `wtmpdb last` as a replacement for the well-known `last`, since
>> the latter became obsolete [0] with Debian Trixie / PVE 9.
>> 
>>  # wtmpdb last reboot --fulltimes --limit 5
>>  reboot   system boot  7.0.14-5-pve     Mon Jul 20 14:22:34 2026 - still running
>>  reboot   system boot  7.0.14-5-pve     Thu Jul 16 15:12:16 2026 - crash
>>  reboot   system boot  7.0.14-5-pve     Thu Jul 16 11:20:15 2026 - Thu Jul 16 15:10:46 2026  (03:50)
>>  reboot   system boot  7.0.14-5-pve     Wed Jul 15 13:39:34 2026 - crash
>>  reboot   system boot  7.0.14-2-pve     Wed Jul 15 07:39:18 2026 - Wed Jul 15 13:38:04 2026  (05:58)
>> 
>>  wtmpdb begins Wed Jul 15 07:39:18 2026
>> 
>> [0] https://www.debian.org/releases/trixie/release-notes/issues.html#the-last-lastb-and-lastlog-commands-have-been-replaced
>> 
>> Signed-off-by: Alexander Zeidler <a.zeidler@proxmox.com>
>> ---
>>  PVE/Report.pm | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/PVE/Report.pm b/PVE/Report.pm
>> index 29433d4a..6049c0bf 100644
>> --- a/PVE/Report.pm
>> +++ b/PVE/Report.pm
>> @@ -36,6 +36,7 @@ my $init_report_cmds = sub {
>>                  'hostname',
>>                  'date -R',
>>                  'cat /proc/cmdline',
>> +                'wtmpdb last reboot --fulltimes --limit 5',
>
> we nowhere depend on wtmpdb so it's not a given that it's installed.

OK, that is not ideal. Afaik only libpam-wtmpdb "Recommends" wtmpdb
(according to debtree).

> 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.

>>                  'pveversion --verbose',
>>                  'cat /etc/hosts',
>>                  'pvesubscription get',

-- 
Maximiliano

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

[Alexander Zeidler]

On Mon Jul 20, 2026 at 3:33 PM CEST, Maximiliano Sandoval wrote:
> Thomas Lamprecht <t.lamprecht@proxmox.com> writes:
>
>> Am 20.07.26 um 14:38 schrieb Alexander Zeidler:
>>> Based on the most recent reboot events, it is possible to determine
>>> whether and when a crash, fencing, or reboot occurred and with which
>>> kernel version the node booted.
>>> 
>>> Use `wtmpdb last` as a replacement for the well-known `last`, since
>>> the latter became obsolete [0] with Debian Trixie / PVE 9.
>>> 
>>>  # wtmpdb last reboot --fulltimes --limit 5
>>>  reboot   system boot  7.0.14-5-pve     Mon Jul 20 14:22:34 2026 - still running
>>>  reboot   system boot  7.0.14-5-pve     Thu Jul 16 15:12:16 2026 - crash
>>>  reboot   system boot  7.0.14-5-pve     Thu Jul 16 11:20:15 2026 - Thu Jul 16 15:10:46 2026  (03:50)
>>>  reboot   system boot  7.0.14-5-pve     Wed Jul 15 13:39:34 2026 - crash
>>>  reboot   system boot  7.0.14-2-pve     Wed Jul 15 07:39:18 2026 - Wed Jul 15 13:38:04 2026  (05:58)
>>> 
>>>  wtmpdb begins Wed Jul 15 07:39:18 2026
>>> 
>>> [0] https://www.debian.org/releases/trixie/release-notes/issues.html#the-last-lastb-and-lastlog-commands-have-been-replaced
>>> 
>>> Signed-off-by: Alexander Zeidler <a.zeidler@proxmox.com>
>>> ---
>>>  PVE/Report.pm | 1 +
>>>  1 file changed, 1 insertion(+)
>>> 
>>> diff --git a/PVE/Report.pm b/PVE/Report.pm
>>> index 29433d4a..6049c0bf 100644
>>> --- a/PVE/Report.pm
>>> +++ b/PVE/Report.pm
>>> @@ -36,6 +36,7 @@ my $init_report_cmds = sub {
>>>                  'hostname',
>>>                  'date -R',
>>>                  'cat /proc/cmdline',
>>> +                'wtmpdb last reboot --fulltimes --limit 5',
>>
>> we nowhere depend on wtmpdb so it's not a given that it's installed.
>
> OK, that is not ideal. Afaik only libpam-wtmpdb "Recommends" wtmpdb
> (according to debtree).

```
# apt rdepends wtmpdb
wtmpdb
Reverse Depends:
  Recommends: acct
  Recommends: libpam-wtmpdb
  Suggests: util-linux
  Recommends: libpam-lastlog2
  Enhances: chkrootkit
```

At least on a new PVE 9.2 installation `wtmpdb` is pre-installed, and
`last` is a symlink to it. For older installations which have only
`last` installed, the following line may be an alternative (beside
simply not getting the information):

`wtmpdb last reboot --fulltimes --limit 5 || last reboot -F -n5`

>
>> 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.

>
>>>                  'pveversion --verbose',
>>>                  'cat /etc/hosts',
>>>                  'pvesubscription get',

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

[Thomas Lamprecht]

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.