We used crony before but didn’t find it very reliable.
I might look at the systemd option in the future. If I do, I’ll probably do it for new installs only and won’t directly deprecate it on existing installations.
I believe I have some notes on this.
You could just disable ntp and enable systemd implementation rather than removing the package.
I was going to try that but as systemd-timesyncd was masked I attempted to unmask it and that procedure deleted the systemd-timesyncd.service file and that’s when I attempted to reinstall and was presented with the noted issue.
Debian dependencies only allow for one of ntp, systemd-timesyncd or chrony (maybe others). Attemping to install one causes the removal of the current one installed.
As armv7-network-osmc has a hard depend on ntp, an attempt to install systemd-timesyncd or chrony triggers a removal of ntp which therefore triggers the removal of armv7-network-osmc as well as vero5-device-osmc as it depends on armv7-network-osmc .
Run the following command to add the staging repository: echo 'deb http://apt.osmc.tv bullseye-devel main' | sudo tee /etc/apt/sources.list.d/osmc-devel.list
Run the following commands to update: sudo apt-get update && sudo apt-get dist-upgrade && reboot
Your system should have have received the update.
Please see if the issue is resolved.
I also recommend you remove /etc/apt/sources.list.d/osmc-devel.list after updating.
This will deactivate the staging repository. You can do so with the following command: sudo rm /etc/apt/sources.list.d/osmc-devel.list.
Please note that we will automatically disable this update channel after 14 days on your device in case you forget to do so to ensure that your system reverts to the stable update channel.
Could you clarify why you wish to use systemd-timesyncd over NTP? I can’t really see a convincing use case… Please note this is compile tested. I have not tested the efficacy of this replacement service on OSMC personally.
I didn’t adjust for Chrony because my experiments with that in 2013-2014 weren’t great. But that may have been init based (Upstart at the time) issues. Every time you change the time setup, you change dependencies in the init system which isn’t ideal. At least with systemd-timesyncd you may have something closely coupled.
Actually I’ve been running with systemd-timesyncd instead of ntp for a few weeks now. Found that I could edit /var/lib/dpkg/status and edit the depends for the armv7-network-osmc package, replacing ntp with systemd-timesyncd | ntp, only drawback was that an apt update would sense the difference and want to update (which I didn’t do).
At any rate, no ill effects as systemd-timesyncd works just fine on all of my 'nix systems.
Main reason to switch is that systemd-timesyncd is less resource intensive and just fine for this purpose whereas ntp is like using a sledgehammer when you just need a ballpeen hammer.
Also I notice that there must not be a CMOS battery in the Vero V as the unit, when powered down, always comes up with the wrong time for a few seconds (same as before I made the switch).
And it looked some startup script was setting the time from the osmc site (unless I read the packet sniffing wrong). And this was completely unnecessary with timedatectl and timesyncd - I tested by blocking access to the osmc site on startup - and the time was promptly set properly.
The update from the dev branch went OK with a minor hitch - probably due to my local changes. The systemd-timesyncd service was masked after the reboot. Unmasking caused the service file to be deleted. But upon an apt reinstall of the service all was fine, even after removing the dev sources from apt.
Thanks much again!
Chris
As to Chrony (a bit off-topic), my only experience with that is that it’s useful if you need to run a time server in a container (example: a Samba AD DC running in the container) as it can be started with the -x switch: This option disables the control of the system clock. chronyd will not try to make any adjustments of the clock. As the container will already have the same time as the host and by default (typically) the container will not have the capabilities of adjusting the host clock anyway.
I don’t know of another NTP server that has this feature.
Same issue if I attempt to use chrony instead of ntp.