Hi all; a bit of a chicken-and-egg conundrum here when booting up a
raspberry pi, unless there's something I've badly misunderstood.

The pi doesn't have an internal clock, so is absolutely reliant on
getting time off the network when it boots. ntpdate should do that (I
think by extracting a server name from the ntp config file and synching
to that). But that means resolving the name, and if the clock is far
enough wrong, dns lookups seem to fail. So the system can't do the
lookup to synch the clock to..........

I think I'm going to have to put in an explicit IP address into
ntp.conf, but that's not particularly robust for the long term.

Anyone else solved this? Or am I missing something obvious?

A number of related issues too:

o should /etc/wall_cmos_clock exist or not for a system with no rtc? It
is present (today), so presumably to do with:-

o The system also seems to have a knack of changing TZ between boots;
after (as I thought) correcting this yesterday with tzsetup, I had a
bunch of complaints overnight: "adjkerntz 5763 - - sysctl(set:
"machdep.wall_cmos_clock"): Operation not permitted"

o presumably jailed systems rely on the host time; yet they seem to have
their own TZ which needs setting. Correct?

o I did wonder about using a gps dongle to set the time: but gpsd seems
not to work on the rpi :-{ Anyone fixed this yet?

Thanks.

--
Mike Scott
Harlow, England

Mike Scott wrote:

> if the clock is far enough wrong, dns lookups seem to fail.

never known DNS to depend on a clock

In comp.sys.raspberry-pi Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
> Hi all; a bit of a chicken-and-egg conundrum here when booting up a
> raspberry pi, unless there's something I've badly misunderstood.
>
> The pi doesn't have an internal clock, so is absolutely reliant on
> getting time off the network when it boots. ntpdate should do that (I
> think by extracting a server name from the ntp config file and synching
> to that). But that means resolving the name, and if the clock is far
> enough wrong, dns lookups seem to fail. So the system can't do the
> lookup to synch the clock to..........

Are you doing DNSSEC or DNS over HTTPS by any chance?
Otherwise that's odd for DNS to depend on the date.

> o I did wonder about using a gps dongle to set the time: but gpsd seems
> not to work on the rpi :-{ Anyone fixed this yet?

There are I2C RTC modules that go on a Pi:
https://wiki.seeedstudio.com/Pi_RTC-DS1307/
(many many versions from different vendors, many <$10)

FreeBSD can then be configured to use it:
https://vzaigrin.wordpress.com/2015/08/04/real-time-clock-on-raspberry-pi-with-freebsd-11/
(it is possible this is now simpler, I haven't tried it)

Theo

In article <t3ls16$6vg$1@dont-email.me>, Mike Scott
<usenet.16@scottsonline.org.uk.invalid> wrote:

> Hi all; a bit of a chicken-and-egg conundrum here when booting up a
> raspberry pi, unless there's something I've badly misunderstood.
>
> The pi doesn't have an internal clock, so is absolutely reliant on
> getting time off the network when it boots. ntpdate should do that (I
> think by extracting a server name from the ntp config file and synching
> to that). But that means resolving the name, and if the clock is far
> enough wrong, dns lookups seem to fail. So the system can't do the
> lookup to synch the clock to..........

dns is not dependent on the time.

> I think I'm going to have to put in an explicit IP address into
> ntp.conf, but that's not particularly robust for the long term.
>
> Anyone else solved this? Or am I missing something obvious?

get an rtc clock.

here's one. there are others:
<https://www.adafruit.com/product/3386>

On 2022-04-19, Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:

> The pi doesn't have an internal clock,

"Here's a nickel, kid. Get yourself a better computer."

> o should /etc/wall_cmos_clock exist or not for a system with no rtc?

It should not.

The existence of /etc/wall_cmos_clock indicates that the RTC is set
to a local time zone instead of UTC. The only reason for such a
perverse setup is if you dual-boot MS Windows on that machine.

> o presumably jailed systems rely on the host time; yet they seem to have
> their own TZ which needs setting. Correct?

Yes.

Internally, the kernal always keeps the time based on UTC. TZ just
points to formatting instructions for converting that time into a
human-readable format, including local time zones.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

On Tue, 19 Apr 2022 09:31:33 +0100, Mike Scott
<usenet.16@scottsonline.org.uk.invalid> declaimed the following:

>Hi all; a bit of a chicken-and-egg conundrum here when booting up a
>raspberry pi, unless there's something I've badly misunderstood.
>
>The pi doesn't have an internal clock, so is absolutely reliant on
>getting time off the network when it boots. ntpdate should do that (I
>think by extracting a server name from the ntp config file and synching
>to that). But that means resolving the name, and if the clock is far
>enough wrong, dns lookups seem to fail. So the system can't do the
>lookup to synch the clock to..........
>

If you are using a recent Raspian OS (whatever they are calling it this
year) it may not be using ntpdate. It should first be grabbing a date/time
from a file that is written periodically (and on shutdown) with "current
time", followed by running a systemd timesyncd to get time via the
internet. There is some discussion as to how often systemd corrects the
clock -- it may be a one-off shortly after boot, though mine seems to
indicate it updates every 34 minutes (after initial update? or based upon
detected drift rate).

https://packages.debian.org/unstable/main/fake-hwclock
https://opensource.com/article/20/6/time-date-systemd

-=-=-=-
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Mar 17 22:16:14 2022 from 2600:1700:e630:890::48
md_admin@microdiversity:~$ timedatectl
Local time: Tue 2022-04-19 14:41:51 EDT
Universal time: Tue 2022-04-19 18:41:51 UTC
RTC time: n/a
Time zone: America/Detroit (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
md_admin@microdiversity:~$ timedatectl timesync-status
Server: 2600:3c00::f03c:92ff:fe30:9f1f (2.debian.pool.ntp.org)
Poll interval: 34min 8s (min: 32s; max 34min 8s)
Leap: normal
Version: 4
Stratum: 2
Reference: 81070142
Precision: 1us (-24)
Root distance: 20.110ms (max: 5s)
Offset: +196us
Delay: 47.741ms
Jitter: 1.238ms
Packet count: 5962
Frequency: -2.658ppm
md_admin@microdiversity:~$ systemctl status systemd-timesyncd.service
? systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled;
vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
+-disable-with-time-daemon.conf
Active: active (running) since Mon 2021-11-29 10:42:09 EST; 4 months 19
days ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 300 (systemd-timesyn)
Status: "Synchronized to time server for the first time
[2600:3c00::f03c:92ff:fe30:9f1f]:123 (2.debian.pool.ntp.org)."
Tasks: 2 (limit: 2059)
CGroup: /system.slice/systemd-timesyncd.service
+-300 /lib/systemd/systemd-timesyncd

Warning: Journal has been rotated since unit was started. Log output is
incomplete or unavailable.
md_admin@microdiversity:~$

--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

On 2022-04-19, Andy Burns <usenet@andyburns.uk> wrote:
> Mike Scott wrote:
>
>> if the clock is far enough wrong, dns lookups seem to fail.
>
> never known DNS to depend on a clock

Me neither. Wonder what symptoms made the OP come to this conclusion?

On Tue, 19 Apr 2022 21:22:46 -0000 (UTC), Jim Jackson <jj@franjam.org.uk>
declaimed the following:

>On 2022-04-19, Andy Burns <usenet@andyburns.uk> wrote:
>> Mike Scott wrote:
>>
>>> if the clock is far enough wrong, dns lookups seem to fail.
>>
>> never known DNS to depend on a clock
>
>Me neither. Wonder what symptoms made the OP come to this conclusion?
>

Could it be DNSsec rather than plain DNS? Since DNSsec uses crypto
authentication, a wildly out of date time stamp might reject server
certificates.

After all, if they don't have fake-hwclock and system boots with the
start of 1970 as the date, likely any server certificate will have a
validity start date way after that...

https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

On 19/04/2022 22:22, Jim Jackson wrote:
> On 2022-04-19, Andy Burns <usenet@andyburns.uk> wrote:
>> Mike Scott wrote:
>>
>>> if the clock is far enough wrong, dns lookups seem to fail.
>>
>> never known DNS to depend on a clock
>
> Me neither. Wonder what symptoms made the OP come to this conclusion?

(OP) because three (or was it more?) times during startup, the PI clock
was hopelessly adrift, and dns queries were failing which was stopping
ntpdate/ntp. I didn't investigate properly, just put 2 and 2 together
and maybe got the wrong answer. This is a small server for our family
and the interest was in getting it up and running ASAP, so I manually
set the time to something near correct, at which point dns started
working and things settled down. I should add I'm running my own copy of
bind, btw; I don't know if that makes a difference.

It seemed decidedly weird, and clearly needs checking out properly.

But I seem to have a bunch of issues around time - time from gpsd
doesn't seem to work on the pi; adjkerntz has been moaning on the jailed
systems, plus the problem above.

Thanks, and to others too, for comments.
>
>

--
Mike Scott
Harlow, England

On 19/04/2022 14:09, Christian Weisgerber wrote:
> On 2022-04-19, Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
>
>> The pi doesn't have an internal clock,
>
> "Here's a nickel, kid. Get yourself a better computer."

:-}

I've just been porting everything off an old i386 in a bid to save space
and kWh. RTC aside, it's not doing too badly. I think the connectors
take as much space as the board.

>
>> o should /etc/wall_cmos_clock exist or not for a system with no rtc?
>
> It should not.

That's what I thought. But it appeared after I ran tzsetup.

"Is this machine's CMOS clock set to UTC? If it is set to local time,
or you don't know, please choose NO here!"

I picked 'No' as in 'don't know', as there's no option for "not gotta
clock".

>
> The existence of /etc/wall_cmos_clock indicates that the RTC is set
> to a local time zone instead of UTC. The only reason for such a
> perverse setup is if you dual-boot MS Windows on that machine.
>
>> o presumably jailed systems rely on the host time; yet they seem to have
>> their own TZ which needs setting. Correct?
>
> Yes.
>
> Internally, the kernal always keeps the time based on UTC. TZ just
> points to formatting instructions for converting that time into a
> human-readable format, including local time zones.
>

Thanks for commenting.

--
Mike Scott
Harlow, England

On Wed, 20 Apr 2022 08:12:33 +0100, Mike Scott
<usenet.16@scottsonline.org.uk.invalid> declaimed the following:

>But I seem to have a bunch of issues around time - time from gpsd
>doesn't seem to work on the pi; adjkerntz has been moaning on the jailed
>systems, plus the problem above.
>

How long does it take your GPS module to get a lock?

A few months ago I bought one of those USB GPS modules (and a 10 foot
USB cable so I could get it into a window -- GPS doesn't get through a
metal roof and metal siding). Have not tried it on my experimental (ie;
normally not powered) R-Pi -- but using u-Blox u-center on my Windows box
has shown that the module can easily take up to 10 minutes to get a 2-D
(lat/long/time) lock -- which is way too long to expect a GPSD time signal
to be available for setting the clock. 3-D (lat/long/alt/time) fixes could
take up to half an hour.

Unless the GPS module is always powered, even through R-Pi power cycles
and reboots [which may drop USB power], it is possible that the module is
not suitable for boot-time time-sync.

--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

On Wed, 20 Apr 2022 08:22:05 +0100
Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:

> On 19/04/2022 14:09, Christian Weisgerber wrote:

> > It should not.
>
> That's what I thought. But it appeared after I ran tzsetup.
>
> "Is this machine's CMOS clock set to UTC? If it is set to local time,
> or you don't know, please choose NO here!"
>
> I picked 'No' as in 'don't know', as there's no option for "not gotta
> clock".

Yes would have been the correct answer - but the question is badly
phrased for a Pi or indeed anything not a PC - s/CMOS/system/ and it makes
more sense. That text hasn't been changed in thirty years or so and rather
assumes that it's on a PC that once ran Windows and may be called upon to
do so in the future.

The only way bad time should break DNS is if you're using DNSSEC or
DNS over HTTPS or something of that order.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

On Wed, 20 Apr 2022 13:20:16 -0400, Dennis Lee Bieber wrote:

> GPS doesn't get through a
> metal roof and metal siding). Have not tried it on my experimental (ie;
> normally not powered) R-Pi -- but using u-Blox u-center on my Windows
> box has shown that the module can easily take up to 10 minutes to get a
> 2-D (lat/long/time) lock -- which is way too long to expect a GPSD time
> signal to be available for setting the clock. 3-D (lat/long/alt/time)
> fixes could take up to half an hour.
>
It sounds as though you had not only a metal roof, but a restricted view
of the sky as well. Most GPS receivers need to see at least three
satellites simultaneously before they can get a fix and, of course, they
need to know where they are before they can determine the time. If the
unobstructed sky a GPS receiver can see is restricted by radio-opaque
objects (and at GPS frequencies 'radio opaque' may also include wet trees
and other shrubbery) its possible that the area of sky the GPS receiver
can see may not contain include many as three satellites when you switch
it on - hence the multi-minute delay before it gets a fix and the time.

I have big oaks behind my house (thats the south side) and a portable GPS
(such as a Garmin GPS II+ or Medion S3747 PNA) may take a long time (many
minutes, if ever in summer) to get a fix there, while if I stand 10 metres
away from said house on its north side, both GPS units get a fix within
2-3 minutes at worst, simply as a result of having a much less obstructed
sky view. This effect is obvious when the Garmin is being used because
pre-fix establishment it shows you home many satellites it can see and
where they are - it never gets a position and time fix until it can see at
least three satellites.

--
--
Martin | martin at
Gregorie | gregorie dot org

On 20/04/2022 18:20, Dennis Lee Bieber wrote:
> On Wed, 20 Apr 2022 08:12:33 +0100, Mike Scott
> <usenet.16@scottsonline.org.uk.invalid> declaimed the following:
>
>
>> But I seem to have a bunch of issues around time - time from gpsd
>> doesn't seem to work on the pi; adjkerntz has been moaning on the jailed
>> systems, plus the problem above.
>>
>
> How long does it take your GPS module to get a lock?
>
> A few months ago I bought one of those USB GPS modules (and a 10 foot
> USB cable so I could get it into a window -- GPS doesn't get through a
> metal roof and metal siding). Have not tried it on my experimental (ie;
> normally not powered) R-Pi -- but using u-Blox u-center on my Windows box
> has shown that the module can easily take up to 10 minutes to get a 2-D
> (lat/long/time) lock -- which is way too long to expect a GPSD time signal
> to be available for setting the clock. 3-D (lat/long/alt/time) fixes could
> take up to half an hour.
>
> Unless the GPS module is always powered, even through R-Pi power cycles
> and reboots [which may drop USB power], it is possible that the module is
> not suitable for boot-time time-sync.
>
>

Thanks for the comment.

Doesn't take long at all if it's only been off for a short while.

I've just tried it back on the original fbsd 11.x system, and gpsd+cgps
shows good time and lock, and ntp will at least acknowledge its presence
(I use NMEA rather than PPS - well, it was cheap, but good enough!)

On the pi though, the year shown by cgps and xgps flips rapidly between,
IIRC, 2022 and 2002, the month changes too, and the time of day by
(again IIRC) a second. ntp won't sync at all with it on the pi4. I'm
assuming there's a gotcha somewhere with zero-padding or sign-extension
or something similar.

When I've time, I'll see if the gpsd utilities show anything helpful.

--
Mike Scott
Harlow, England

On 20/04/2022 18:06, Ahem A Rivet's Shot wrote:
> On Wed, 20 Apr 2022 08:22:05 +0100
> Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
>
>> On 19/04/2022 14:09, Christian Weisgerber wrote:
>
>>> It should not.
>>
>> That's what I thought. But it appeared after I ran tzsetup.
>>
>> "Is this machine's CMOS clock set to UTC? If it is set to local time,
>> or you don't know, please choose NO here!"
>>
>> I picked 'No' as in 'don't know', as there's no option for "not gotta
>> clock".
>
> Yes would have been the correct answer - but the question is badly
> phrased for a Pi or indeed anything not a PC - s/CMOS/system/ and it makes
> more sense. That text hasn't been changed in thirty years or so and rather
> assumes that it's on a PC that once ran Windows and may be called upon to
> do so in the future.

Thanks; I manually removed the files from /etc, and it was happier
overnight.

>
> The only way bad time should break DNS is if you're using DNSSEC or
> DNS over HTTPS or something of that order.
>

Yes, indeed. I still don't know what was going on with the pi. I did
fire up the old i386 I'm replacing with it, and set the clock back and
forth some tens of years. Absolutely no problem with DNS lookups or
having ntpdate reset the time. The pi is in use 24/7, so I can't readily
check that (anyone know where in the UK to buy a spare pi4??)

No, I don't use DNSSEC or similar, so it'll have to remain a mystery for
now. But thanks to you, and to all, for taking the issue on board.

--
Mike Scott
Harlow, England

>> A few months ago I bought one of those USB GPS modules (and a 10 foot
>> USB cable so I could get it into a window -- GPS doesn't get through a
>> metal roof and metal siding).

GPS may have a hard time getting through modern, Low-E window glass.
Low-E windows contain glass that has been coated in invisible layers
of a metallic oxide. It will greatly attenuate RF signals.

Jonesy
--
Marvin L Jones | Marvin | W3DHJ.net | linux
38.238N 104.547W | @ jonz.net | Jonesy | FreeBSD
* Killfiling google & XXXXbanter.com: jonz.net/ng.htm

In comp.sys.raspberry-pi Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
> The pi doesn't have an internal clock, so is absolutely reliant on
> getting time off the network when it boots. ntpdate should do that (I
> think by extracting a server name from the ntp config file and synching
> to that). But that means resolving the name, and if the clock is far
> enough wrong, dns lookups seem to fail. So the system can't do the
> lookup to synch the clock to..........

Never heard of DNS being time-dependent. If you ask it to look up a
hostname, it should return whatever result is current.

One way to resolve the Raspberry Pi's lack of a clock is to add one. Cheap
DS1307 boards with a battery that are designed to plug into the GPIO header
are under $10. You could spend a little more to get a more precise chip, or
a bit more still (though still under $100) to add a GPS receiver so you can
build your own stratum-0 time source.

--
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

On 21/04/2022 19:52, scott@alfter.diespammersdie.us wrote:
> In comp.sys.raspberry-pi Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
>> The pi doesn't have an internal clock, so is absolutely reliant on
>> getting time off the network when it boots. ntpdate should do that (I
>> think by extracting a server name from the ntp config file and synching
>> to that). But that means resolving the name, and if the clock is far
>> enough wrong, dns lookups seem to fail. So the system can't do the
>> lookup to synch the clock to..........
>
> Never heard of DNS being time-dependent. If you ask it to look up a
> hostname, it should return whatever result is current.

I can't reproduce this on another system. No idea what's been going on,
and can only assume something else was going on as well.

>
> One way to resolve the Raspberry Pi's lack of a clock is to add one. Cheap
> DS1307 boards with a battery that are designed to plug into the GPIO header
> are under $10. You could spend a little more to get a more precise chip, or
> a bit more still (though still under $100) to add a GPS receiver so you can
> build your own stratum-0 time source.

Now there you've jogged my memory. I've just pulled from an older pi a
ds3231 I bought several years ago and forgot about. Seems to have
battery backup on it. Only trouble there's a heatsink in the way.....
frustrating.

As I've noted elsewhere, data from gpsd isn't reliable on the pi.

--
Mike Scott
Harlow, England

On 22/04/2022 08:36, Mike Scott wrote:
......
> As I've noted elsewhere, data from gpsd isn't reliable on the pi.
>
>
>
Just to note that after upgrading to gpsd-3.23.1, gpsd now seems to work
correctly: ntpd is very happy to sync to an nmea source in priority to
the internet servers.

Thanks all for input.

--
Mike Scott
Harlow, England