NTPD | Time to sync exceeds acceptable levels #1445
Comments
|
Looking at the above, it seems rather obvious now: Since the NTPD failed to update the time, I'm assuming the Pi has an older time and so the certificate appears to be valid sometime in the future... :) The question then is, why did the NTPD fail (and still does)? |
|
Manually selecting another NTP server (Europe in my case) seems to work, and I can proceed. |
|
Actually I take that back.. when going back to installing Pi-Hole, the NTPD time sync keeps failing in the same way... :-( I thought it worked. The Pi time is still incorrect (in the past). Edit: I can proceed with the installation if I set the correct date/time manually, but the reason for this issue's existence is to find out and resolve the failure of NTPD.. ;-) |
Fourdee
changed the title
Strange, we'll try to replicate. We may need to debug your system and the NTPD process, but, i'll try to verify same results locally 1st. |
Did you select Failing NTP sync depends vastly on the network performance and ntp mirror. It can take longer than 30 seconds in some cases (all we allow for before the prompt), however, in most cases, selecting Local testing is fine for me with default settings. NTPD syncs usually at the 10/30 mark during boot. |
|
@Fourdee Testing DietPi on another board (pine64), showed the exact same problem as well. I had to manually set the date/time to proceed. |
|
Thanks 👍 Any chance you can run the following and paste results: Success should result in: |
|
|
seem to happen from time to time. Fresh image RPi-Zero ( Ethernet is a USB adapter: IP-address and DNS: via DHCP
|
|
Thanks guys 👍 15+ minutes to sync 😨 1+ minute to sync Notes: Below: most likely due to Linked for reference as its the only major ntpd specific change (that I can remember 😉 ): Fourdee@cb2915a Curious if we get same results from SystemD based timesync and/or other mirrors. IPv6? Congested, deadpool (lol film)? |
|
Did either of you notice any changes/improvements when using alternative NTPD mirrors (if changed)? As I cant replicate the issue here, if you have the time, i'd appreciate it if we could try the following change: At the bottom replace all 4
atypical result: |
Fourdee
changed the title
|
@Fourdee After making the changes suggested above: ...still hasn't come back after 30 minutes |
|
Had to cancel my way out: |
What did you use on RPi-Zero?
|
|
@k-plan I've been using the same setup with DietPi for the last two years or so, only now upgraded to the latest so I had to re-flash the distro and set things up from scratch. |
|
Aside from the pool change (which you have reverted in testing), the only change I can think of is kernel version. We now use the default APT RPi kernel The only things I can suggest to try is:
|
|
@Fourdee
|
Sorry to bother, but @midwan has installed He should have a
|
|
@k-plan However, the issue with the NTPD sync failure came up before installing Pi-hole also. In fact, it stopped me from installing it, because due to the time skew the site's certificate looked invalid (had a "future" timestamp). @Fourdee
|
Thanks for testing 👍 kernel is an improvement, but still not good enough. Really don't know where to go from here as I cant replicate on any device, I can only assuming network is the factor. We rely on We've not had other reports (aside from @k-plan but thats only 1 minute, @k-plan during the prompt of NTPD failure, did the |
Yes, but by hitting
|
|
@k-plan |
nice to hear this.
👍 Well done! |
|
This happens for me on three different devices (Pine64, RPi 2 Model B, RPi Zero W), all with freshly flashed DietPi_v6.0 Stretch images. Here's the output from the Zero W, but the other devices are the same. (Installation was aborted because I Exited out of dietpi-software in order to manually run ntpd -gq) It just runs indefinitely, soliciting new pool servers. It's not network issues - I can ping randomly selected servers the ntpd is soliciting: Let me know if any further info needed. |
|
Thanks for the report 👍 Lets try switching back to server, instead of pool. Please copy and paste all, then retest with |
|
Now it gets this far and hangs (I've included the full ntp.conf): Time is still not synced. From a different ssh session: Final output from ntpd -gq when I ctrl-c'd out of it: |
|
Thanks. Can we please see results from: And also home router make/model (if known)? |
|
@midwan @infinitejones @Fourdee
|
|
tl;dr: switching to daemon+drift appears to have worked. However when rebooting, it still needs 10-15 attempts to get a response from whatever server it's soliciting, ie. I'd already generated the output to Gateway IP is correct (10.0.0.1). The modem/router is a Sagemcom F@st5535, which is the standard device provided by our main ISP here in Australia. The device hasn't changed since the last time ntpd worked for Dietpi, which was before v6 was released (the "old" v159).
|
|
not sure it's useful but I had the same thing until I edited the /etc/ntp.conf with nano - it had a bunch of /@?@? in the file just before the server list, I deleted those and everything ran normally... I have of course deleted the file, no idea if it was me that added them - or it was there already (I did look at the file fairly sure I didn't spam it and save it ) |
|
Ok, will mark this as closed for now, should be resolved with v6.9 and switch to SystemD timesyncd by default: However, should users still experience this past v6.9, please reopen and we'll restart investigations. |
Creating a bug report/issue:
Required Information:
Additional Information (if applicable):
Expected behaviour:
Selecting to install Pi-hole from the menu, should eventually leave us with Pi-hole installed.
Actual behaviour:
Pi-Hole fails to install, reporting this error:
Steps to reproduce:
Flash latest RPI image to sdcard
Boot and enter Optimized Software
Select to install Pi-hole
Begin installation process
Did you submit a
dietpi-bugreport?No
Extra details:
Additional logs:
The text was updated successfully, but these errors were encountered: