Date: Mon, 3 May 2021 16:18:42 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Timezone problems on -current Message-ID: <B7A82D04-FE5B-4D9C-B155-D26A29C96CF5@yahoo.com> In-Reply-To: <20210503223811.GC37236@www.zefox.net> References: <20210503153442.GB37236@www.zefox.net> <3E0512C0-7667-44C4-B64B-501783C5B210@yahoo.com> <20210503223811.GC37236@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-May-3, at 15:38, bob prohaska <fbsd at www.zefox.net> wrote: > On Mon, May 03, 2021 at 11:24:02AM -0700, Mark Millard wrote: >> >> >> On 2021-May-3, at 08:34, bob prohaska <fbsd at www.zefox.net> wrote: >> >>> It seems that the timezone gets screwed up each time the OS is >>> upgraded on a Pi4 via sources on -current. ntpdate is working, but the >>> machine reports a local time of >>> bob@nemesis:~ % date >>> Mon May 3 15:27:04 PDT 2021 >>> while a Pi2 reports >>> fbsd@www:~ % date >>> Mon May 3 08:28:35 PDT 2021 >>> >>> The timezone is PDT in both cases, but the time shown looks like >>> UTC for the Pi4 but PDT for the Pi2. >> >> Note: I assume that neither RPi* has a RTC, not that >> it makes much of a difference here. >> > Correct, no RTC on any of them. > >> I expect that one RPi* has a file: >> >> # ls -Tld /etc/wall_cmos_clock >> -r--r--r-- 1 root wheel 0 Aug 8 01:49:01 2017 /etc/wall_cmos_clock >> >> and the other does not. > > All RPi*s in my collection report having /etc/wall_cmos_clock, > including the one displaying the wrong time. So much for my expectations. > Some are Pi2, running > armv7 12.2-stable, two are Pi3 running 14-current and 13.0-stable. > The only one showing wrong time is the Pi4 running 14-current. Do all the RPi*'s agree for there output for: # sysctl machdep.adjkerntz machdep.adjkerntz: 0 ? (My example context; yours may vary. But to get uniform handling, you would want all yours to agree.) Do all the RPi*'s agree for their output of: # strings /etc/localtime | tail -1 PST8PDT,M3.2.0,M11.1.0 (My example context; yours may vary. But to get uniform handling, you would want all yours to agree.) I'll note that: # strings /etc/localtime | head -1 TZif2 indicates the format-version of the file from what I can tell, allowing some cross checking for things being as expected. "man adjkerntz" has information on the subject. > When the Pi4 finishes building www/chromium I'll start experimenting > to identify just what I did to get the clock wrong. The obvious test > would be to correct the time with tzsetup and then update world and > kernel, reboot and see if time is again wrong. If there are other, > better things to try please indicate. I've never seen timekeeping > problems and know nothing of how it's done. I'm not so sure that this large-change would well isolate the problem --or be likely to change anything. > This begs a question: If I simply re-run installworld, without updating, > will it overwrite the existing world again without rebuilding everything? If you avoid buildworld and just installworld, sure. (buildworld after installworld will rebuild various things because of changes installworld makes, based on what META_MODE tests for.) But I'm not sure why you would do this. I'll note that there are other targets for installing some types of files, but they tend to destroy local tailoring and so are normally only for starting over. Otherwise etcupdate or the like deals with file adjustments in a way less likely to replace your localizations. > That would speed up the experiment considerably. > >> >> There can be an issue of time going backwards, depending on >> the delete vs. add action for /etc/wall_cmos_clock . >> > > I've long wondered about messing with time settings while the > machine is doing something important, like running make. Is that > something to avoid? Yep: avoid time changes in the middle of other things that are based on comparing timestamps. make, in part, uses timestamp comparisons. If date output ends up before file system dates, waiting for the correct time order can be appropriate. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B7A82D04-FE5B-4D9C-B155-D26A29C96CF5>