The online community for MiSTer FPGA enthusiasts
https://misterfpga.org/
Code: Select all
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst
# Allow only time queries, at a limited rate, sending KoD when in excess.
# Allow all local queries (IPv4, IPv6)
restrict default nomodify nopeer noquery limited kod
restrict 127.0.0.1
restrict [::1]
Code: Select all
server 192.168.54.254 iburst
# Allow only time queries, at a limited rate, sending KoD when in excess.
# Allow all local queries (IPv4, IPv6)
restrict default nomodify nopeer noquery limited kod
restrict 127.0.0.1
restrict [::1]
Code: Select all
#!/bin/bash
NTP_SERVER="0.pool.ntp.org"
i=0
while [ $i -lt 20 ]
do
if ! ntpdate -bsu $NTP_SERVER
then
if $i == 19
then
echo echo "Unable to sync after 20 attempts."
fi
sleep 1s
((i++))
else
echo "Date and time is:"
echo "$(date)"
i=20
fi
done
I also replaced the servers with my router's IP address, and it also works for me. Thanks for the idea.jlancaster86 wrote: ↑Fri Jan 28, 2022 11:25 pm If I replace those four servers with my MikroTik router's IP address, it works just fine:
Do we have a solucion to this yet? I have this exact problem, the date and date does not show up at startup and my MiSTer internet is fine. It worked before, the updates maybe messed up the things here. A brand new up to date installation does not fix this.
As a mitigation, the updater launchers now try to ntpdate if they see that date command is off. If you use downloader, reinstall the launcher to get this new version.
But this is no definitive solution and won't fix other clock usage problems in cores if you don't run any updater after booting or you don't have an internet connection. A better solution would be installing RTC add-on board, as it keeps the clock without depending on the network.
My router even has an NTPd, not sure how many do.
mightor wrote: ↑Fri Jan 28, 2022 3:07 pmSo the problem may have been introduced in the latest Linux versions. Keeping old Linux version is not an option as modern cores needs up to date Linux version. So while waiting for a fix, there are only two ways to get date/time at each boot: by manually running rtc.sh or by using your automated method to run a ntp.sh script at boot time.
jlancaster86 wrote: ↑Fri Jan 28, 2022 2:28 pmYeah, I just tried rolling back to menu_20210315.rbf, and the clock isn't updating. Looks like it's something in the Linux installation.
How many people are currently having this issue?
I guess I wasn't very clear in my original comment. Your router's DHCP service can set an NTP server as a DHCP option, which it will then pass down to the connecting clients. If it does that, a client has a hint as to which NTP server to sync from. If your router has its own NTP service on board, it's quite likely that it passes this option through its DHCP service as well. To close the gap, the client must actually make use of the information it gets handed from DHCP. If it doesn't do that, it's still useless.. but you could manually configure ntp to sync to the router's private IP address (the default gateway IP).
The Mister is using ntpd, which AFAIK pays no attention to DHCP whatever. It uses /etc/ntp.conf for configuration. In there are four lines for using pool.ntp.org servers.
If time isn't syncing, dropping to a command line, typing "ntpq", and typing "peers" will tell you a lot about the state of the daemon. If you need help interpreting, you can post that output here
Note that because it's going to pool.ntp.org by name, DNS needs to be working.
Tried to mess with the NTP settings on my router (Asus RT-AX88U) as a last resort but no dice. Maybe Sorgelig will take a look into this.
The settings on your router probably aren't what you need, and won't likely change anything.
The config file is on the Mister, /etc/ntp.conf.
One other completely random idea - you don't happen to have two MiSTers on the network at the same time, do you? By default, they all share one MAC address, which can be extremely disruptive to communications as a whole.
Nop, just one. A friend has the same issue and others on this forum also, surely this is not an isolated case.
What does your /etc/ntp.conf look like?
I'm also running a local NTP server, but I was doing that originally, so if there's a problem syncing to outside servers, I wouldn't have seen it.
edit with a random thought: if your Mister can talk to your local network but can't get outside, make sure it's getting a default route from the DHCP server. Without a default route, a machine can't leave the local network. You can check with route -n:
Code: Select all
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 A.B.C.1 0.0.0.0 UG 0 0 0 eth0
A.B.C.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0That's saying that for any global address, forward to the address A.B.C.1. (usually routers are on .1, although they don't have to be.) I believe UG means Up, Gateway. (the default route.)
Then, for every IP address from A.B.C.0 to A.B.C.255, they're connected to the Ethernet port named eth0. Any machine with one of those IPs is on the same wire, and can be spoken to directly.
If you don't have the first line, then the machine can only talk to other machines on the same wire. If you don't have the second line, the machine can't talk to anything.
If you have three or more lines, you probably have a WiFi card connected and active at the same time as Ethernet. This is almost always a bad idea, unless you understand networking well enough to make it work properly.
Also make sure your /etc/resolv.conf says something sane. It should look at least like this:
Code: Select all
domain example.com
nameserver 8.8.8.8The domain should be whatever you use locally. Nameserver can be any number with a valid DNS resolver. 8.8.8.8 is Google. 9.9.9.9 is Plan 9. I think they also run 1.1.1.1 as a nameserver. Any of those numbers should work unless your ISP is blocking them. Some do, because they want to snoop on your DNS queries.
The number could also be your router, at A.B.C.1. This is typically fine, as long as the router is working. Using all 8s or all 9s may be more reliable.
I'm going to have to spend some time on this as well. The last Linux update borked my MiSTer and now I can't run any of the scripts due to no NTP.
Use Putty to ssh into your MISTer, go to the Scripts directory, run the rtc.sh script, even if you do not have a RTC, it will update your Linux Date and Time. You can also run update_all.sh after that.