Date error on TX2 prevents a proper first time flash.

Hi, im new to linux and the Jetson system. Ive been having trouble with the first setup of the TX2.
I have a fresh install of Ubuntu 14.04 on my host and have flashed the jetson like 4 times already.

at the end of the flash, i get a few warnings saying:
“make[1]: warning: clock skew detected. Your build may be incomplete”

I have googled for this warning and some forums say to just ignore it but others say it may cause errors if something is not built properly. I saw this post

but the resolv.conf file has the company router and also the google DNS. “nameserver”

I try to ping and host as the post specifies and it provides a response.

In the end I try to stop the NTP service but i get the following message:
"Failed to stop ntp.service: Unit ntp.service not loaded.

Im not sure what to do. I am very new to linux. Could anyone help me with this, can I adjust my time and use make again? (i dont know where nor what to “make”)

Should I install ntp on the jetson and retry to flash the OS? (im guessing this doesnt work since it just overwrites the partition)

Or is to manually uninstall and reinstall these packages?

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 “”: 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 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

you were right on this. I checked ntp wiki. it specifies it works though port 123. I went to IT and asked them to open it for me. After that i reinstalled the software using the JetPack Installer (running the file) and I unchecked everything except the “install on target” files. After that I had no warnings from make.

Thank you!

When I was installing Jetpack 3.2 it somehow got in an infinite loop while compiling stuff in ~/tegra_multimedia_api/samples with messages about the timestamp being in the future. I was able to SSH to the board and set the time with the command

sudo date --set="2018-04-06 17:13:00"

and then the installation finished with the warnings mentioned by the original poster.

If files are dated in the future an application which pays attention to date will do this. Most of the time it is because your system clock was not set…but sometimes it is because you unpacked something preserving its date stamp and that package was itself packed when date was invalid.

NTP is Network Time Protocol and is what is used for setting date on the Jetson. Typically this will be a problem if the router isn’t forwarding NTP. When using DHCP for setting the IP address this should be set up by default. There are a number of places this might break so I’d suggest that next time you see the error run the command “date” on that machine and see if the clock is correctly set…and then use “ls -l” on some of the files and see if their date is in the future versus system date.