MiSTer FPGA Forum

I've noticed recently that "update_all.sh" has been failing for me, and I realized today that it's because the clock is resetting to Unix epoch, breaking HTTPS.

My MiSTer is refusing to update the time via NTP unless I run rtc.sh manually every time I boot. I've tried automating it with startup scripts (in "/etc/network/if-up.d/") but it just never works (and yet the scripts will work if run manually). Am I missing something?

On a related note, rtc.sh appears to be broken now. The default NTP server ("0.pool.ntp.org") no longer responds to ping, so the script will always fail. Either the NTP server has to be set to something that will respond to ping (such as "2.pool.ntp.org"), or the ping check needs to be removed/commented out.

jlancaster86 wrote: ↑Sat Dec 18, 2021 1:13 am I've noticed recently that "update_all.sh" has been failing for me, and I realized today that it's because the clock is resetting to Unix epoch, breaking HTTPS.

My MiSTer is refusing to update the time via NTP unless I run rtc.sh manually every time I boot. I've tried automating it with startup scripts (in "/etc/network/if-up.d/") but it just never works (and yet the scripts will work if run manually). Am I missing something?

On a related note, rtc.sh appears to be broken now. The default NTP server ("0.pool.ntp.org") no longer responds to ping, so the script will always fail. Either the NTP server has to be set to something that will respond to ping (such as "2.pool.ntp.org"), or the ping check needs to be removed/commented out.

blacklistedcard wrote: ↑Sun Dec 19, 2021 7:19 pm I just checked. The rtc.sh script is running fine for me.

/media/fat/Scripts# ./rtc.sh
Syncing date and time with
0.ca.pool.ntp.org
Date and time is:
Sun 19 Dec 2021 02:18:09 PM EST
RTC set.
/media/fat/Scripts#

Bas wrote: ↑Mon Dec 20, 2021 3:53 pm It'll fail if it runs before the MiSTer has an IP.

mightor wrote: ↑Thu Jan 27, 2022 7:28 am Can you please give us some more details about how you automated this ?
By just copying the rtc.sh script in /etc/network/if-up.d/ ?
How did you manage to delay for 10 seconds ? By changing the content in the script ?

#!/bin/bash

NTP_SERVER="0.pool.ntp.org"
i=0

while [ $i -lt 3 ]
do
	echo "Waiting 10 seconds..."
	sleep 10s
	if ! ntpdate -bsu $NTP_SERVER
	then
		if $i == 2
		then
			echo echo "Unable to sync after 3 attempts."
		fi
		((i++))
	else
		echo "Date and time is:"
		echo "$(date)"
		i=3
	fi
done

sh /media/fat/Scripts/ntp.sh &

mightor wrote: ↑Thu Jan 27, 2022 12:03 pm The ntp.sh script works well when executed manually through the interface menu of the MiSTer.
But it does not execute automatically. To be sure that the boot process has enough time to enable the ethernet connexion, I increased the pause from 10 to 20 seconds.
The ntp.sh script also has execute permissions.
Please note that the name of the startup script is "_user-startup.sh"

rhester72 wrote: ↑Fri Jan 28, 2022 5:10 am No physical RTC here and very literally never had the problem described after nearly 2 years.

Bas wrote: ↑Fri Jan 28, 2022 11:00 am If scripts guard themselves against an obviously wrong clock that would fix this whole issue. There are far too many external dependencies for ntpdate to work reliably in this situation. If it does, you're mostly just lucky.

Bas wrote: ↑Fri Jan 28, 2022 11:00 am RSetting the makestep parameter in the config to 1 -1 should allow for an instant leap from epoch to the current time.

mightor wrote: ↑Fri Jan 28, 2022 2:05 pm Well well well. After an "update_all" from the fresh install of mr fusion 2.2, date/time is broken. Again.

jlancaster86 wrote: ↑Fri Jan 28, 2022 2:13 pm Are you able to roll back just the Menu .rbf to the one in Mr. Fusion 2.2? That'll help to narrow it down to either the Menu core or the Linux installation.

mightor wrote: ↑Fri Jan 28, 2022 2:23 pm

jlancaster86 wrote: ↑Fri Jan 28, 2022 2:13 pm Are you able to roll back just the Menu .rbf to the one in Mr. Fusion 2.2? That'll help to narrow it down to either the Menu core or the Linux installation.

I can do that in a next troubleshoot step but I'm pretty sure it's the Linux installation and not the menu.rbf nor MiSTer.rbf.
I'm currently testing an update using the included update.sh script instead or "update_all", starting from a fresh install of mr fusion 2.2. Everything out of the box.

mightor wrote: ↑Fri Jan 28, 2022 2:23 pm I'm currently testing an update using the included update.sh script instead or "update_all", starting from a fresh install of mr fusion 2.2. Everything out of the box.