Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NTP Time ? #5

Open
JacoFourie opened this issue Dec 4, 2017 · 13 comments
Open

NTP Time ? #5

JacoFourie opened this issue Dec 4, 2017 · 13 comments

Comments

@JacoFourie
Copy link

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
Copy link

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
Copy link

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
Copy link

pl31 commented Mar 19, 2018

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
Copy link

pl31 commented Mar 19, 2018

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
Copy link

pl31 commented Mar 19, 2018

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
Copy link
Contributor

mamoit commented Apr 18, 2018

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
Copy link
Contributor

mamoit commented Apr 18, 2018

@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
Copy link

@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
Copy link
Contributor

mamoit commented Apr 18, 2018

@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
Copy link
Contributor

mamoit commented Apr 18, 2018

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

@marcin-sielski
Copy link

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
Copy link
Contributor

mamoit commented Apr 19, 2018

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
Copy link
Contributor

kohlerdominik commented May 1, 2018

I can confirm @mamoit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants