Failure described below, but FYI, JetPack 3.1 works from this host (it’s a native install laptop Ubuntu 14.04). Deleting and restarting JetPack 3.2 pre-release does not change anything. Also, this laptop has complete internet access over wired ethernet…it has no port restrictions and no proxy complications. On other Jetson installs there is no issue with ssh access, and ssh askpass is installed.
I’m using JetPack3.2 pre-release for install of L4T and some packages (no host install) and getting an infinite timeout/wait after I click on Next in the screen where packages are picked. There is no activity on the disk after a very short time (fatrace and "sudo watch du -h -s "). The entire content of the JetPack3.2 directory never exceeds 142MB.
Sorry, this is a bit long, I’m describing the process of finding out that perhaps repository.json is not valid despite not having any “smoking gun” evidence this is the case.
I discovered (even with “NV_DEVTOOLS_FORBID_MULTIPLE_DOWNLOAD_THREADS=1 ./JetPack-L4T-3.2-linux-x64_b157.run”) there is a duplicate process of this example shown below (from looking at htop in tree view, abbreviating due to the long line, showing on multiple lines for clarity…this represents what JetPack called):
-d tx2_64bit \
-s <location> \
-c <location>/jetpack_download/repository.json \
-p 4671 \
-t /tmp/tmp4671aaaaaa \
There is one process exactly as noted above, and this has two child processes which are also exact duplicates (one parent process, two child processes, all the exact same command line). This looks like recursive calls to itself using exactly the same arguments. Even with “strace -f” it shows this is just waiting forever and never proceeding (the next menu never shows up…I’ve let it run overnight…strace goes quiet indicating something is blocking). fatrace shows there is no file access being attempted during this wait. strace shows waiting on a resource and strace output never shows more activity. The terminal has no activity and does not ask for passwords…it never gets that far. No polling is shown, just pure blocking and waiting.
If I kill the last child process from the above (kill -9…kill -15 has no effect), then the original process still has one child exactly like this, and install looks like it proceeds (the menus start allowing me to continue)…except nothing installs or downloads…all it does is let me click the Next menu button. Serial console never shows activity, the original install remains without harm, and the JetPack directory and subdirectory content does not change.
The file selectcomp.txt never appears. Perhaps nothing can proceed because the package selection list file does not exist? What does JetPack do if selectcomp.txt is named on command line, but the file does not exist?
So I simplified. I cut this down to just downloading “File System and OS” plus “Drivers”, with no flash, and no other packages…it still halts and does nothing…strace waits…the directory never gets any file access.
Under JetPack 3.2 pre-release, what is selectcomp.txt dependent on in order for it to be created (and should it be created in the user’s home directory instead of the JetPack directory)? This laptop does not have an NVIDIA graphics card, and is “puny” by many standards…dual 64-bit atom and 2GB of RAM. There is no reason to download any host packages to this laptop, but it seems to be a valid flash host for all other cases.
In repository.json I see all download URLs for all packages are missing the “http://developer.download.nvidia.com/” prefix except for some png icons (see “grep http repository.json”)…I see one png icon downloaded. If all URLs are invalid, would this cause selectcomp.txt to also not show up? Would JetPack know if a URL were invalid, or would it simply wait forever?