NTP Time ?

[JacoFourie]

trafficstars

After running the script the Pi will default to 3 November 2016. NTP time is also missing. So you dont have accurate date and time.

[jacobalberty]

It seems to be a dhcpcd issue, dhcpcd seems to be trying to write something before calling its exit scripts, /run/systemd/timesyncd.conf.d/ likely needs to be mounted as a tmpfs to fix /etc/dhcp/dhclient-exit-hooks.d/timesync but something else is happening to keep that from even running.

[jacobalberty]

Well, I guess maybe thats not the right hook? I'm confused there seems to be multiple hooks /lib/dhcpcd/dhcpcd-hooks/50-ntp.conf may be the right one to worry about and it does seem to be running but not working probably need at least /var/run/ /var/run/dhcpcd/ntp.conf to be on tmpfs, but so fat at least that isnt enough

[pl31]

May it is this one:

Note: The service writes to a local file /var/lib/systemd/timesync/clock with every synchronization. This location is hard-coded and cannot be changed. This may be problematic for running off read-only root partition or trying to minimize writes to an SD card.

From here: https://wiki.archlinux.org/index.php/systemd-timesyncd

[pl31]

After running the script and booting:

pi@raspberrypi:~ $ timedatectl status
      Local time: Thu 2016-11-03 18:18:49 CET
  Universal time: Thu 2016-11-03 17:18:49 UTC
        RTC time: n/a
       Time zone: Europe/Berlin (CET, +0100)
 Network time on: yes
NTP synchronized: no
 RTC in local TZ: no

Trying to reconfigure:

pi@raspberrypi:~ $ sudo timedatectl set-ntp 0

Failed to set ntp: File /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service: Read-only file system

... but no clue how to fix his bug or if it is even related.

[pl31]

Seems not to be an readonly issue:

pi@raspberrypi:~ $ sudo mount -o remount,rw / 
pi@raspberrypi:~ $ sudo service systemd-timesyncd restart
Warning: systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
pi@raspberrypi:~ $ sudo systemctl daemon-reload
pi@raspberrypi:~ $ sudo service systemd-timesyncd restart
Warning: systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
pi@raspberrypi:~ $ timedatectl status
      Local time: Thu 2016-11-03 18:28:37 CET
  Universal time: Thu 2016-11-03 17:28:37 UTC
        RTC time: n/a
       Time zone: Europe/Berlin (CET, +0100)
 Network time on: yes
NTP synchronized: no
 RTC in local TZ: no

[mamoit]

The read-only-fs.sh actually purges the fake-hwclock package. And then we loose ntp since it is recommended by that same package.

[mamoit]

@PaintYourDragon Do ntp or fake-hwclock write to any file? I reinstalled them both by booting with the jumper on and it still seems to work (correct time).

[jacobalberty]

@mamoit fake-hwclock writes to a file on shutdown, and i could have sworn when I tested it there was still a ntpd installed?

[mamoit]

@jacobalberty To be honest I ran the script on raspbian lite and did not check if the ntp package was installed prior to running it, but since I had a correct date by then I suspect that the purging of fake-hwclock took it with it. I will redo the process tomorrow and step the script one command at a time to see if it was the culprit, and which command was it. I have a feeling though, that marking the ntp package as manually installed (if it is indeed marked as a dependency of fake-hwclock) should do the trick.

[mamoit]

Aparently I'm not the only one who suspects fake-hwclock. There is already a PR for this issue @marcin-sielski #4

[marcin-sielski]

My fix has solved the issue with the incorrect time. I use it in my project https://github.com/marcin-sielski/LM15SGFNZ07/tree/master/examples/SmarThermo. Cheers.

[mamoit]

I was wrong, ntpis not installed as a dependency of fake-hwclock. If I purge fake-hwclock the clock starts drifting with every reboot (with a writable filesystem), therefore, if the system was ro I would most probably not even get a time. I don't know why, but it seems fake-hwclock, besides storing the clock between reboots, queries an ntp server, keeping it from drifting.

Therefore, I think the correct solution for this problem would be indeed to purge fake-hwclock (since /etc/fake-hwclock.data will not be writable), but install ntp so that if we have an uplink, we can have a reasonable clock.

[kohlerdominik]

I can confirm @mamoit