I have been trying to install Dietpi on a restricted network where the NTP server is only accessible from an internal IP/url. But what I noticed is that DeitPi when it tries to do an automated install still searches for timesync for 60 seconds, fails and proceeds again. This happens a total of 3 times The NTP_MIRROR has been configured correctly and once the system is fully setup the timesyncd.conf has the correct time servers listed. How can I prevent the timesync from costantly failing for 60 seconds during the install ?
Did you set ntp server within dietpi.txt before initial first boot?
Yes that was setup the current config looks like this
CONFIG_NTP_MODE=2
CONFIG_NTP_MIRROR=172.17.12.XXX
I can see that in the last phase of the runonce config the NTP server is set correctly. The issue is only with the automated setup phase.
Looking into Journalctl after the successful boot it seems that DietPi is still trying to contact he Debian pool addresses. But after a few reboots then syncs up with the correct NTP Server
Oct 05 23:29:11 systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
Oct 05 23:29:11 systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
Oct 05 23:29:51 systemd-timesyncd[369]: Timed out waiting for reply from 198.71.50.75:123 (2.debian.pool.ntp.org).
Oct 05 23:30:02 systemd-timesyncd[369]: Timed out waiting for reply from 204.2.134.163:123 (2.debian.pool.ntp.org).
Oct 05 23:30:15 systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
Oct 05 23:30:15 systemd[1]: systemd-timesyncd.service: Deactivated successfully.
Oct 05 23:30:15 systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
Oct 05 23:30:16 systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
systemd-timesyncd[810]: Contacted time server 172.17.12.XXX:123 (172.17.12.XXX).
systemd-timesyncd[810]: Initial clock synchronization to Sat 2024-10-05 23:30:16.344345 CDT.
systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
systemd[1]: systemd-timesyncd.service: Deactivated successfully.
systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
ok I have done some tests and can confirm your behavior. First the DHCP assigned time server (or global fallback) is used before the custom settings are applied. Here I need to talk to the developer if we can change the behavior to set the time server earlier.
Ping @MichaIng
Right, time sync mode and mirror are applied during dietpi-software phase of first run setup, but we could actually set it in dietpi-firstboot instead. … ah, one problem is that the function to change the mode as well installs e.g. systemd-timesyncd if not installed yet, and more importantly dbus in case daemon mode was selected, which is not pre-installed, hence requires network 
.
I split the functions, so that the mirror can be applied separately during early boot script: v9.8 · MichaIng/DietPi@f2ec267 · GitHub
It makes anyway sense to be able to set the time sync mirror individually, also in our existing code: v9.8 · MichaIng/DietPi@20d5848 · GitHub
Naturally, it cannot detect/apply the current gateway as mirror, before a network connection has been established. If “gateway” is set, it will fall back to default, and apply the gateway at the later stage, when the time sync mode is applied, just as it happens with current images. We could apply the mirror also after network has been brought up, to be able to apply the gateway/router as time sync mirror in the first place, but then it would be a race condition between systemd-timesyncd syncing and us applying the mirror. We could also ship images with systemd-timesyncd disabled, and start it after applying the mirror, but it serves also as an alternative to fake-hwclock, to apply a more recent (binary built time) system time during early boot stage. Currently we do ship fake-hwclock, but at some point I actually want to get rid of it. Only need to find a good way to store/update the systemd-timesyncd time file on shutdown, even if it is not running (hourly/daily time sync).
I’ll generate a test image. What I am not sure about is, even that network is still down, systemd-timesyncd runs already. It might need to be reloaded, for the new config to take effect.
@bigops which hardware/SBC you use?
I’ll test on VirtualBox: DietPi-Build · MichaIng/DietPi@20d5848 · GitHub
Thanks for the response. To give some more context, I am running on a Raspberry 5. A few notes about my dietpi.txt
- DHCP is disabled and network settings are given statically.
- D-bus is enabled
Even though I have not tested based on the post from Joulinar it might work with DHCP enabled and supplying Option 42 for the timeserver. I can test it later and also post result
An RPi 5 test build is running: DietPi-Build · MichaIng/DietPi@017698e · GitHub
If DHCP is enabled, the DHCP server provides an NTP mirror, and no explicit one is applied to systemd-timesyncd config (which is the image default), then the one provided via DHCP server is used, else debian.ntp.pool.org as global fallback.
Now, the CONFIG_NTP_MIRROR setting is applied before network is brought up during earlier boot stage. As long as systemd-timesyncd load that changed setting without being explicitly reloaded/restarted, it should work. Else, we need to explicitly restart the service.