if the clock is far enough wrong, dns lookups seem to fail.
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..........
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?
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?
The pi doesn't have an internal clock,
o should /etc/wall_cmos_clock exist or not for a system with no rtc?
o presumably jailed systems rely on the host time; yet they seem to have their own TZ which needs setting. Correct?
XPost: comp.unix.bsd.freebsd.misc
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
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..........
Mike Scott wrote:
if the clock is far enough wrong, dns lookups seem to fail.
never known DNS to depend on a clock
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?
get an rtc clock.
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 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.
I've just been porting everything off an old i386
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".
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.
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.
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.
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.
Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
I've just been porting everything off an old i386
"Something" has gone wrong (obviously you know that..). Figuring it out
might take a lot of time & effort. Unless you enjoy that, and unless you
MUST have Freebsd (seeing as you x-posted to cubf.misc, I guess you do want that), I suggest starting with a fresh copy of the standard Raspberry Pi OS (with or without desktop), 64-bit if it's a Pi3B+ or Pi4. SD cards are relatively cheap so you could try with a new card and pop the old one back
in if you don't like it.
[Removed the freebsd group since this isn't about that]
I have installed and looked at the rpi os; I might even have switched
over, as other boxes here at home are all linux (mint). /But/ I'm of the impression that the linux firewall is missing features - for what I need
- cf the bsd's pf firewall. I'm /not/ trying to start a flame war here,
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).
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..........
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.
As I've noted elsewhere, data from gpsd isn't reliable on the pi.
| Sysop: | deepend |
|---|---|
| Location: | Calgary, Alberta |
| Users: | 240 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 09:49:35 |
| Calls: | 1,464 |
| Calls today: | 2 |
| Files: | 3,372 |
| Messages: | 360,448 |