getting correct time when rpi boots up freebsd

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.

never known DNS to depend on a clock

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

There are I2C RTC modules that go on a Pi:

many versions from different vendors, many <$10)

FreeBSD can then be configured to use it:

is possible this is now simpler, I haven't tried it)

Theo

dns is not dependent on the time.

get an rtc clock.

here's one. there are others:

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

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.

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.

On Tue, 19 Apr 2022 09:31:33 +0100, Mike Scott snipped-for-privacy@scottsonline.org.uk.invalid> declaimed the following:

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).

-=-=-=- 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:~$

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

On Tue, 19 Apr 2022 21:22:46 -0000 (UTC), Jim Jackson snipped-for-privacy@franjam.org.uk>

declaimed the following:

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...

Am 19.04.22 um 14:24 schrieb nospam:

compute the_result and use #date -s the_result

(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.

:-}

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.

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".

Thanks for commenting.

"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]

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.

On Wed, 20 Apr 2022 08:12:33 +0100, Mike Scott snipped-for-privacy@scottsonline.org.uk.invalid> declaimed the following:

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.

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.

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.

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

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.

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, it may well just be a case of "what you're familiar with is best" or that I've missed something vital completely (entirely possible). But given familiarity, along with that I've a significant number of scripts that use pf, I decided to stick with what I was already using.

Sure, to each their own. I can't help with your choice since I know next to nothing about the differences between pf and other firewalls (iptables, I guess). I leave it to my modem/router to do all ipv4/6 firewalling. Your requirements are probably more complex.

Just in general, I made that choice a few times myself to go with the latest default install and cut back on sysadmin tinkering. Definitely feels like giving up something at first, but in the end it is almost always adequate and frees up time for things that are more fun.