last reboot

last reboot

[Paul Thomas]

Hello, 'last' is a handy tool, and using it for
'last reboot' provides a nice log.

I was wondering if there are currently any platforms where more
information about the reboot type is supported? For instance on the
Zynq UltraScale+ devices there are a variety of reboot reasons:
https://www.xilinx.com/html_docs/registers/ug1087/crl_apb___reset_reason.html#

So on each startup the reason could be read and logged before
resting the register[1].

I guess one tricky issue would be the kernel interface,
for a test I was just using memtool like this:
# memtool md 0xFF5E0220+1
ff5e0220: 00000001

Where 00000001 indicates an 'External POR', but this probably
isn't how we'd want to do it.

I'm not subscribed to the mailing-list so please cc me any response.

thanks,
Paul

[1] If the register is not reset then multiple bits can accumulate
so you wouldn't now which is correct for the current boot

Re: last reboot

[Sami Kerola]

On Tue, 10 Sep 2019 at 10:20, Paul Thomas <pthomas8589@gmail.com> wrote:
>
> Hello, 'last' is a handy tool, and using it for
> 'last reboot' provides a nice log.
>
> I was wondering if there are currently any platforms where more
> information about the reboot type is supported? For instance on the
> Zynq UltraScale+ devices there are a variety of reboot reasons:
> https://www.xilinx.com/html_docs/registers/ug1087/crl_apb___reset_reason.html#
>
> So on each startup the reason could be read and logged before
> resting the register[1].
>
> I guess one tricky issue would be the kernel interface,
> for a test I was just using memtool like this:
> # memtool md 0xFF5E0220+1
> ff5e0220: 00000001
>
> Where 00000001 indicates an 'External POR', but this probably
> isn't how we'd want to do it.
>
> I'm not subscribed to the mailing-list so please cc me any response.
>
> thanks,
> Paul
>
> [1] If the register is not reset then multiple bits can accumulate
> so you wouldn't now which is correct for the current boot

Hi Paul

The last(1) is pretty simple tool.  It can and will display information
tracked in utmp(5) data.

http://man7.org/linux/man-pages/man5/utmp.5.html

The utmp data is stored over many many reboots, that might stay around for
years.  Notice that changing utmp(5) is probably not the easiest thing to
achieve.  That format is part of POSIX.  Assuming standards are changed then
update to various libc implementations is needed as well.

Alternatively some sort of extented-utmp format could be created to avoid
standardization work, but getting that to adopted might be hard.  While utmp
has it's flaws it is not exactly broken.  In short while I'm not strictly
against better reboot reason tracking I am a somewhat doubtful how feasible
this work is.

That said what is that memtool?  I have never noticed it before.  By glance
it looks a little like abandonware.  Maybe it could be get a home in
util-linux if a tool like that is found to be useful, and old maintainer
does not mind.

-- 
Sami Kerola
http://www.iki.fi/kerolasa/

Re: last reboot

[Paul Thomas]

Hi Sami,

>
> The last(1) is pretty simple tool.  It can and will display information
> tracked in utmp(5) data.
>
> http://man7.org/linux/man-pages/man5/utmp.5.html
Thanks for the information.

>
> The utmp data is stored over many many reboots, that might stay around for
> years.  Notice that changing utmp(5) is probably not the easiest thing to
Yes, staying around for years with an entry for each boot would be desirable.

> achieve.  That format is part of POSIX.  Assuming standards are changed then
> update to various libc implementations is needed as well.
>
> Alternatively some sort of extented-utmp format could be created to avoid
> standardization work, but getting that to adopted might be hard.  While utmp
> has it's flaws it is not exactly broken.  In short while I'm not strictly
> against better reboot reason tracking I am a somewhat doubtful how feasible
> this work is.
OK, this makes sense. I might do something simple for our use case.

>
> That said what is that memtool?  I have never noticed it before.  By glance
> it looks a little like abandonware.  Maybe it could be get a home in
> util-linux if a tool like that is found to be useful, and old maintainer
> does not mind.
I'm not sure what the current state is, but it's included in the latest debian:
https://packages.debian.org/buster/memtool

It's a very simple (if not dangerous) tool to r/w /dev/mem. But it's very handy
for spying on memory mapped I/O registers like in this case.

I guess adding an interface isn't any worse than /dev/mem directly, but it
still might not be desirable to have it on every system?

-Paul