Flashing jetpack3.2 on Tx2 freeze

I am trying to flash jetpack3.2 to tx2.The process freezed after getting ip. See attached picture:

JetPack3.2 relies on the wired ethernet. The Jetson itself relies on a router…either a dedicated ordinary router appliance, or else the host PC configured to act as router. During the start of the install there is a menu to pick which you are using. Which did you pick, and is the Jetson actually connected to a router or is it connected directly to host through a switch?

After a flash the Jetson reboots. On first boot (under JetPack through 3.3) the first boot has a mechanism to try to report the IP address to the host (to JetPack). If this fails, then this is what you get. You can run JetPack again, deselect flash, and simply work on package installs; however, you have to manually enter the IP address in this case (which is how you can continue). Basically you must log in to the Jetson and run “ifconfig” to see the eth0 IP address, and then manually enter this when JetPack asks.

Thanks, linuxdev. I give up jetpack3.2. Instead, I managed to flash jetpack3.3 to my tx2.Thank god!
But I met another problem.nvgstiva-app sample always core dumped. I will start a new thread for that.

Do be aware that if you mix packages between JetPack3.2 and JetPack3.3 you can get core dumps. The two versions are incompatible and should not be mixed. If you mixed anything from a flash of one release with packages built for the other release, then I would expect that kind of failure.

Wow.I did use the same folder for downloading packages for both jetpack3.2 and jetpack3.3 to save time.I will try again with a clean folder for downloading.Thanks for your comment.

Still got core dumps after installing jetpack3.3 all over again.No mixed packages this time.But same result.

What commands result in core dumps? There are a number of ways to debug, but anyone doing so will need to reproduce the issue. If it is a custom program, then you might want to post a short code section producing the core dump. Knowing exactly how the command is run and how you are connected (local GUI, ssh, so on) would be needed for any method of debugging.

I followed the suggestion in this thread and everything is ok now: