Date: Fri, 24 Feb 2023 13:52:48 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Current FreeBSD <freebsd-current@freebsd.org>, freebsd-arm@freebsd.org Subject: Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot Message-ID: <F14A8CE9-D8B5-46D2-8BB8-1B3ADC9A6A90@yahoo.com> In-Reply-To: <20230224210502.GA8127@www.zefox.net> References: <20230224210502.GA8127@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 24, 2023, at 13:05, bob prohaska <fbsd@www.zefox.net> wrote:
> After installing=20
> =
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230223-fe5c211ba873-261074.img
> on a Pi3 and setting up the hard disk to use separate swap and /usr =
partitions
> an oddity came to light regarding dates.
>=20
> The image file was written to disk the night of the 23rd, from a Pi3 =
with
> a correctly-set time and date. It was left idle overnight, configured =
the
> morning of the 24th and booted without issue. It then cloned -current =
into
> /usr/src, at which point the time was noticed to be wrong, apparently =
fast.
>=20
> It turned out ntpdate wasn't running, so it was started and then =
tzsetup
> run. After a reboot the time reported correctly.=20
>=20
> However, make buildworld in /usr/src triggers an exhortation to "check
> your time" and refuses run further.=20
>=20
> running date on the system reports
> Fri Feb 24 12:49:41 PST 2023
> but ls -l /usr/src reports time around=20
> Feb 24 19:10
> an obvious inconsistency.
>=20
> Presumably just waiting until the system clock catches
> up with the /usr/src timestamps will fix the error. Is
> there a better method?
>=20
> Still, the date and time handling don't seem quite right.=20
> In at least one earlier instance it appeared that tzsetup=20
> altered the reported timeszone without shifting the time
> stamp by the UTC/PDT offset. I always thought timestamps
> were internally in UTC+timezone, displayed with the right
> offset. It looks to a casual observer like something else
> is going on.=20
>=20
> An earlier fiasco (on this same Pi3) included wildly wrong
> timestamps in a filesystem. The Pi3 has no hardware clock,
> how does it set time when booted without a reference?
There are 2 files involved:
/etc/localtime Current zoneinfo file, see tzsetup(8) and =
zic(8).
/etc/wall_cmos_clock Empty file. Its presence indicates that the
machine's CMOS clock is set to local time, =
while
its absence indicates a UTC CMOS clock.
An oddity here is that there is no existing
CMOS clock but the /etc/wall_cmos_clock
status still has consequences, as I remember.
Various related man pages are:
adjkerntz(8)
tzseteup(8)
zic(8)
=46rom an RPi4B:
# ls -Tld /etc/wall_cmos_clock
ls: /etc/wall_cmos_clock: No such file or directory
# sysctl machdep.wall_cmos_clock
machdep.wall_cmos_clock: 0
(So: As if a CMOS clock was using UTC time.)
# strings /etc/localtime | tail -1
PST8PDT,M3.2.0,M11.1.0
# sysctl machdep.adjkerntz
machdep.adjkerntz: 0
# date
Fri Feb 24 13:42:52 PST 2023
(Matching the local time.)
So, as configured, /etc/localtime is used to
specify covert kernel UTC to local time as
needed: no addition non-zero offsets.
As I remember, things can be odd with file
systems from Windows variants and the time
stamps interpretation. Keeping such matching
vs. not can get into the choice of if
/etc/wall_cmos_clock is to exist or not.
It can be a seprate issue if time tracking
is off rate or some such.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F14A8CE9-D8B5-46D2-8BB8-1B3ADC9A6A90>