I can’t give the full answer. The basic flow though is that a manifest is downloaded based on the version of JetPack and the end product, and that from this manifest URLs for the correct architecture (remember this can be for host or Jetson and you can check or uncheck what you want installed) are used to download packages to host. Ssh (presumably scp) is used to copy packages destined to the Xavier to the actual Xavier. “sudo” is then used with standard apt commands.
The first apt command will always be a “repo” “.deb” package. This installs a repository in “/var” for that package (e.g., for CUDA) which becomes a “local” (so far as Xavier is concerned) repo and anything there can be installed via apt without going over the internet.
Because everything depends on CUDA the CUDA repo is first, then actual CUDA from the resulting local repo. Other packages could depend on another local repo being added if the required package is not in the CUDA repo. Check your “/var” on the TX2.
One of the points of using JetPack is that it understands install order dependencies. You might look through some of the files which result after a package operation. Typically you will see descriptions and URLs (including architecture specific) for packages. Look through the local.ini and repository.json files for examples. Note that a base address is given near the top of the file and each package simply appends to the base address URL.
If you see a URL in one of those files, then probably you can use “wget” to download the “.deb” file. If you lack the repo directories on your Jetson, then the named “repo” “.deb” is where you would manually download. This is essentially how the installer works…a scripted smarter wget. There are no custom port designations that I know of for the addresses wget would use.
If for some reason your host is unable to update the local manifest files this would account for stalling out.