For actual flash without compiling any software there shouldn’t be any notice of clock skew. But basically here is what this is about…the example could be any project, but I’ll probably use kernel compiles as an example…
Whenever you have files in a project you will find “make” and some other tools depend on the time stamp of the files to know which one is newer than the other. There are cases where a system booting up has invalid time and the files are produced in such a way that some of them may have a time stamp in the future…something which should be impossible. But if you previously touched the files in the year 2017, but later booted when the system clock thought it was 1972, the files will be seen as invalid because they are marked in the future. In reality it is the clock which is at fault. Possibly there is a mix of problems causing files and system clock to be using two different ideas of “now” and “past” and “future”.
If you were compiling kernel source and either you couldn’t set a valid system clock, or else the system clock is correct but files were generated when the clock was wrong, you could cd to the kernel source and run this:
cd /where/ever/source/is/kernel
touch `find . -print`
One example of a possible source of a skew is if your system time is not backed up by battery or supercap, but correctly uses ntp for clock set and the network does not run until after some boot file manipulation has occurred…in that case the clock would be wrong for some files, the clock would then become correct. This isn’t a problem if the bad clock time when touching files was in the past…but if your clock was running on battery or supercap and ran fast, say 15 minutes into the future, and then ntp corrected your clock when you went to compile 5 minutes later the skew would be that the files are 10 minutes in the future and “make” would fail.
Having a log or other information stating what operation detected a skew would be a nice way to know where the recursive “touch” needs to be to fix the skew.
About your company router: Do you know if it has security which requires network assignment to know your Jetson’s MAC address before allowing it? If there is some sort of security issue the skew won’t have anything to do with not having an address. A perfectly functioning Jetson would fail.
About ping of “nvidia.com”: This requires DNS service for it to know what dotted-decimal format IP address to ping…if your network is fully functional, but DNS has not been configured (part of DHCP), then you would be unable to ping nvidia.com despite the network being functional. Router logs will typically tell you if there was a DHCP request, and if denied, a reason why.
There have been changes to how NTP is configured over the recent years. There used to be a pure init file method of dealing with this, then there is a systemd method, and then there are hybrids which mix init files and systemd configuration. You might want to try each of these just to see what happens once you know networking is up and DNS makes it possible to use named addresses:
# Two ways to query (should work without sudo...changes probably require sudo):
ntpq -p
timedatectl status
I think timedatectl is the more modern systemd method. Customization for this is in “/etc/systemd/timesyncd.conf”, but it is unlikely to be required if everything is configured correctly (you could use this for example to customize your ntp server to be something on your private network).
The “timedatectl status” can be accessed also via systemctl (systemd), e.g.:
systemctl status systemd-timesyncd.service
sudo systemctl stop systemd-timesyncd.service
sudo systemctl start systemd-timesyncd.service
sudo systemctl restart systemd-timesyncd.service