Received my shiny new Vero V last week, so far have only done the OSMC updates and tweaked some of the config in the gui before it goes “live” to replace my Vero 4k.
Yesterday I noticed an ntp error every couple of hours in syslog, which can also be seen by checking the service status:
osmc@tim-verov:~$ systemctl status ntp.service
* ntp.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2025-04-09 18:03:03 AEST; 4 days ago
Docs: man:ntpd(8)
Process: 3136 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper (code=exited, status=0/SUCCESS)
Main PID: 3142 (ntpd)
Tasks: 2 (limit: 3659)
Memory: 1.9M
CGroup: /system.slice/ntp.service
`-3142 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 105:108
Apr 13 18:03:03 tim-verov ntpd[3142]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): expired 107 days ago
Apr 13 21:03:03 tim-verov ntpd[3142]: frequency file /var/lib/ntp/ntp.drift.TEMP: Permission denied
Apr 14 01:03:03 tim-verov ntpd[3142]: frequency file /var/lib/ntp/ntp.drift.TEMP: Permission denied
Apr 14 03:03:03 tim-verov ntpd[3142]: frequency file /var/lib/ntp/ntp.drift.TEMP: Permission denied
Apr 14 05:03:03 tim-verov ntpd[3142]: frequency file /var/lib/ntp/ntp.drift.TEMP: Permission denied
Apr 14 07:03:03 tim-verov ntpd[3142]: frequency file /var/lib/ntp/ntp.drift.TEMP: Permission denied
Apr 14 11:03:03 tim-verov ntpd[3142]: frequency file /var/lib/ntp/ntp.drift.TEMP: Permission denied
Apr 14 13:03:03 tim-verov ntpd[3142]: frequency file /var/lib/ntp/ntp.drift.TEMP: Permission denied
Apr 14 16:03:03 tim-verov ntpd[3142]: frequency file /var/lib/ntp/ntp.drift.TEMP: Permission denied
Apr 14 17:03:03 tim-verov ntpd[3142]: frequency file /var/lib/ntp/ntp.drift.TEMP: Permission denied
Ownership of directory /var/lib/ntp doesn’t look right, i.e. ntp user has no write permission:
Seeing the same thing also, so corrected permissions. Looks like the install script for OSMC/Vero-V needs correcting, so as to set the correct permissions on /var/lib/ntp
Ok it’s not realted to the built then.
So super strange. Seems to be that @sam_nazarko must use his magic powers to understand why some systems have wrong permissions
If you ordered the Vero V recently, it’s a long standing issue hence it still being present with a fairly monitor filesystem:
OSMC filesystem assembled on jenkins at Sun 02 Mar 2025 04:10:15 PM UTC using Debootstrap version 1.0.123+deb11u1
From the top of my head, it could be two problems:
Bad postinst not setting permissions probably. This was a known Debian issue in the past.
Some sort of kernel configuration missing / not set which isn’t allowing NTP to set the permissions.
It can obviously be fixed, but will need some investigation.
Anyone got a Pi up and running on latest OSMC that can quickly check if it’s an issue there too? It will be a few days before I can directly test on a PI otherwise.
On a RPi4 here with latest greatest OSMC from staging this is not an issue.
On a VeroV shipped in January with OSMC from staging the device is affected.
FWIW, here are my order details:
Order number: 71223
Date: March 25, 2025
And, just to be a little pendantic, the permissions are ok, it’s the ownership that is is wrong. The file in my example is owned by uid 129 (which does not exist in /etc/passwd, so no name shown in “ls”), and gid 104 (“messagebus” in /etc/group).
Also FWIW, I mentioned in my original post that I had “done the OSMC updates” - I would have checked for updates, but according to /var/log/apt/history.log there have been no updates applied (all I can see is that I have installed rsyslog, logrotate and rsync), i.e. the system was already “up to date” when I fired it up.
cat /etc/osmc_build_info
OSMC filesystem assembled on jenkins at Tue 28 May 2024 12:40:35 AM UTC using Debootstrap version 1.0.123+deb11u1
This is a relatively old root filesystem.
I can’t upgrade NTP:
root@osmc:/home/osmc# apt-get install ntp
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
ntp is already the newest version (1:4.2.8p15+dfsg-1).
ntp set to manually installed.
Here’s the build info from 2 of my systems wherre the filesystem ownership was wrong.
osmc@Kodi-Florida:~/.kodi/temp$ cat /etc/osmc_build_info
OSMC filesystem assembled on jenkins at Mon 07 Aug 2023 03:24:13 PM UTC using Debootstrap version 1.0.123+deb11u1
osmc@Kodi-BR:~/.kodi/temp$ cat /etc/osmc_build_info
OSMC filesystem assembled on jenkins at Mon 07 Aug 2023 03:24:13 PM UTC using Debootstrap version 1.0.123+deb11u1
osmc@Kodi-BR:~/.kodi/temp$
These were both off the same order. I have a newer Vero V from late last year. I’ll check it when I get time.
osmc@osmc:~$ cat /etc/osmc_build_info
OSMC filesystem assembled on jenkins at Mon 11 Dec 2023 02:00:44 AM UTC using Debootstrap version 1.0.123+deb11u1
@JimKnopf reports that reinstallation of ntp (sudo apt-get install --reinstall ntp) fixes the issue. So I think we can just fix ownership in network-osmc which should work for new and existing installs.
Newer versions of Debian use systemd-timesyncd, which is why this is probably not a massively reported issue. And existing installations… exist…
See
Notice the conditional, because maybe systemd-timesyncd will be sufficient enough in the next Debian release. We’ve already had requests to make it installable which is why we made it a conditional dependency here:
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.
