From: Sami Kerola <kerolasa@iki.fi>
To: Paul Thomas <pthomas8589@gmail.com>
Cc: util-linux <util-linux@vger.kernel.org>
Subject: Re: last reboot
Date: Tue, 10 Sep 2019 14:44:08 +0100 [thread overview]
Message-ID: <CAG27Bk2efpSwz97CHom4Mr0N+LSmFh1qT4rDeb9jF=2VVqfc0g@mail.gmail.com> (raw)
In-Reply-To: <CAD56B7foOQ8UYuMYPBqaYUa4DQw_qc4QUJRRkgdeV1g1x0NfoA@mail.gmail.com>
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/
next prev parent reply other threads:[~2019-09-10 13:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-09 19:07 last reboot Paul Thomas
2019-09-10 13:44 ` Sami Kerola [this message]
2019-09-10 14:04 ` Paul Thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAG27Bk2efpSwz97CHom4Mr0N+LSmFh1qT4rDeb9jF=2VVqfc0g@mail.gmail.com' \
--to=kerolasa@iki.fi \
--cc=kerolasa@gmail.com \
--cc=pthomas8589@gmail.com \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).