Util-Linux Archive on lore.kernel.org
 help / color / Atom feed
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
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.


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

  reply index

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-09 19:07 Paul Thomas
2019-09-10 13:44 ` Sami Kerola [this message]
2019-09-10 14:04   ` Paul Thomas

Reply instructions:

You may reply publically 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:

* 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 \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Util-Linux Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/util-linux/0 util-linux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 util-linux util-linux/ https://lore.kernel.org/util-linux \
	public-inbox-index util-linux

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git