Jetpack 3.1 for TX1 installation is stuck at "determining the IP address of target..."

I just got the issue in the post installation of JetPack 3.1 for TX1.
What is to do next? Please advise

How is the Jetson connected to the host? E.g., wired to switch and the host acting as router, versus both wired to a router.

Yes, they are.

Which method is used to connect the host and Jetson?

Jetson is connected to both host and router. host is also conneted to router and Jetson

host is connected to the host by usng a programing cable

There is only one wired ethernet…I am interested in knowing the physical cable layout (this changes how addresses are provided).

As I said, both host and jetson are connected to the router by LAN cable, and Jetson is connected to the host with programming cable.

I just followed this instruction

Ok. The USB cable is used for flash, but is not used for networking. The software install stage (after flash completes) uses only the wired ethernet cable. Because you have an external router you’ll want to check the router to see what address it assigned to the Jetson. This is the address you’ll need to enter manually.

Do be sure your host has the “ssh-askpass” package installed…once you get an address entered it may use that for a password pop-up (or it may ask in the console of the Jetson).

Yes, the host has the “ssh-askpass” package installed, however it just stucks at determining the IP address, so I can’t go further.
What is to do?

Does JetPack offer a chance in the console or elsewhere to either (a) enter a password, or (b) enter an address manually? The router will be the source of knowing the address if you can’t login locally to the Jetson (or you can login over serial console and run ifconfig…or if you have a local monitor and keyboard, just run ifconfig from the local console).

TX1 does also not recognize any local monitor nor keyboard nor mouse.
I have been trying 6 times and always stuck by determining the IP address
I can use ifconfig to check for the IP address, but don’t get the request to define it manually yet

Serial console would be ideal to log in to the Jetson and see what the address is, but the router would also do. Check if you can ping the address, then check if ssh works.

Can you provide me any manual for the installtion, that leads me step-by-step such as preparation for the installtion till checking up after installtion?
I really appreciate for that. It is really frustrated to search for the right answer in this forum

Once you get to the stage where it asks for an address…or gets stuck there…the flash has already been completed. The stage it is now at is for further software install (using ethernet instead of USB). This can be run at any time, so even if you reboot both host and Jetson you can continue or append whatever steps you want. The issues you are currently at won’t require a complete flash.

The Jetson uses DHCP to get its address. The address is assigned by the router. It is possible for the host PC to act as a router if the host and Jetson are connected via a switch instead of an actual router appliance.

In the case where the Jetson has just been flashed there is a mechanism for the first boot to report its wired network address to the host (WiFi won’t work). If for some reason this cannot complete you may need to manually tell JetPack what the address is. Many things can get in the way of this since it is typical networking. Your router and local network are custom to you, so only general statements are possible, e.g., suggesting a command you can try and then report back here on its results.

What I suspect is that the system is up and running, but you just can’t see it. Video configuration fails for some monitors, e.g., all monitors with a regular VGA cable will fail to auto-configure, and if you don’t know the address from the router, then you won’t know you can just ssh in. Serial console in such situations because it requires almost nothing to work right, yet it will still let you log in and see what’s going on. For information on serial console (which I recommend if ping and ssh can’t get to the Jetson to see what is going on) see either of these:

If the system is running fine, but the video is not configured for your monitor (highly likely), then flashing again won’t change things (it’ll be the same monitor). If you don’t have the serial console, then it is important to look closely at your router and check its logs or set up information to see what address the router assigned to the Jetson. Once you have this a lot can be done and you are no longer isolated without access to the Jetson. Can you log in to your router and give any information about what address the router has assigned?

I have the exact same issue as the OP in TX2. OS flashing completes, and the Post Installation hangs trying to determine target IP. Meanwhile the Target JEtson reboots, and I can find its IP address and ssh to it independently from the host.

It’ll really help if you can elaborate on the steps to manually install the rest of the JetPack components (CUDA, CuDNN, TensorRT, etc.). I was hoping to get the installation done and get on with my project, but have been stuck in this for 3 days.

Being able to automatically find the IP address is convenient, but isn’t necessary. If you watch the console window you will find a stage asking you for the address and/or name/password. Automatic address setup is only after a flash, but JetPack can run for many packaging reasons without flash and is done routinely.

Uncheck flash (you don’t need to flash again and this is what triggers a reboot in order to leave recovery mode) and just add packages you won’t need recovery mode, but you do watch the console for entering passwords and/or IP address. Try booting the Jetson normally, connecting the wired ethernet to the PC without WiFi, and running JetPack with only the package installs checked. Watch the console (somehow I hear the voice of Yoda when I say “use the console”).

Thanks for the prompt response. It turns out, changing the Ethernet setting of my host VM to bridged and retrying a couple of times worked. (In one of those trys, the console window gave me two options, and I chose to manually enter the IP address. But it closed shop quietly without doing anything. Looks like it’s safe to say this feature has some stability issues.)

VMs are specifically not supported…VM setup really requires something better than current VM handling of devices being dynamically added/removed for ethernet and especially USB. This part is something flash software can’t help (VMs are “flakey” at best)…often it is assumed that a VM is just like a regular computer, but at the USB and ethernet end it isn’t due to incorrect handling of disconnect/reconnect/enumeration (you can work around that if you fiddle with it, but this is a case of needing knowledge and human intervention).

The mechanism to determine IP address (and to handle failures) after flash and in preparation of software package installs could probably be improved. On the other hand, this isn’t as easy as it sounds when dealing with ethernet. The current mechanism is self-removing after the first reboot, so you basically get one chance. After that recovery is purely from human intervention. Once you mix in a VM config not passing something through automated mechanisms are gone. If someone mistakes the lack of video for a failed flash and reboots too soon then this pretty much guarantees even more confusion.

I do think something is probably being actively worked on to improve this though. I say this because of the OTG port on R28.2 now automatically becomes a device when connected via the micro-B USB to a host (this is new behavior…it’s basically the Linux gadget framework, but setup isn’t complete). I suspect the reason for this is an unfinished effort to eliminate the need for separate wired connections for package install versus flash. If NVIDIA takes it a step further, then it may lead to the same USB cable which is used for flash also becoming the ethernet connection. Since USB devices have distinct IDs which remote ethernet connections do not have (which includes a vendor and device ID) there could be a future software install system which is truly reliable without any kind of hack for IP address reporting. The future will tell!