Hello! I have a DNS sinkhole, and notice that whenever I launch (power on) for the first time it makes a single call to www.google.com. I was just wondering why? I am sure it is minor, as it is just the one-time, but still curious. And perhaps there’s some setting I can do to stop it.
I am using a Pi 3 B+. And if needed I can get the OSMC version information (but have noticed this for a while and just posting now).
In the meantime, I keep blocking it. Thanks very much!
As the device doesn’t have a realtime clock it needs to set it’s time after a restart. As NTP can not do that if the time difference is too large OSMC makes a wget request to Google and uses the HTTP timestamp to set the time.
Ah! I was thinking it may have been time, but then there are ‘debian.pool.ntp.org’ calls following that.
Is there a non-Google time option that can be used perchance?
Any suggested site that has same “guaranteed” uptime, known through most firewalls, dns-holes “safe”
I’m curious, there are few things I feel worse about is to have to force a dependence on google on anyone. Even if it is just a http request to analyze the reply header for timestamp. It’s still award. All though, if I personally chose to depend on google, i do so informed what it means for me.
I have some plans to change this in the near future.
Hi
Hopefully the issue is now addressed with the following commit:
I’d appreciate it if you could test this and provide feedback before we potentially release this as an update to other users. To test this update:
echo 'deb http://apt.osmc.tv bullseye-devel main' | sudo tee /etc/apt/sources.list.d/osmc-devel.list
sudo apt-get update && sudo apt-get dist-upgrade && reboot
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.
Hi @sam_nazarko ,
May I know if it’s good to participant this test by enrolling the devel repo?
I’m having an odd experience during Bullseye update, which I suspect is causing by this:
Thanks,
I’m not sure how blocking Google would cause any updating issues. We use NTP to set time, and the HTTP time service is just used to give time a push in the right direction.
It would be good to know more about the problem you are experiencing and see some logs.
I’m afraid that I may not be able to easily reproduce the issue.
As mentioned in the linked post, the 2nd attempt to upgrade went smoothly hence the Vero 4K currently is running Bullseye happily. And no future reboot was blocked by network time sync service.
Looking from the thread, there is another Vero 4K users experience the same on both her/his Vero 4K:
I plan to upgrade two OSMC instances on RPI3s on my parent place to Bullseye this weekend. I will pay attention on whether it would happen there.
So the first question would be: are you blocking Google servers on your network?
I did not in my local network.
But I’m living in a region that accessing to Google isn’t straightforward.
Anyway, I had upgraded two RPi3 to OSMC Sep 22 releases smoothly and did not encounter the weird blocking by network time sync service.
Forgot to say: It’s still an awesome release and thanks a lot for you and your team’s hard work.