Unable to install Jetson SDK from Jetpack 4.2.2 rev1 on both Host and TX2

Hi,

I have been trying unsuccessfully to install the Jetson SDK components on both my offline host machine and my TX2.

Downloaded SDK Manager from the nvidia site: 0.9.14.4961

Machines:
Main PC Windows, running Ubuntu 18.04.3 in VM (online)
Ubuntu Laptop running 18.04.3 (offline only)
Jetson TX2 (offline only)
Both Ubuntu installs are brand new, clean installs.

  1. Used SDK Manager on Ubuntu VM to download all packages for 4.2.2 rev1.
  2. Copied items to Ubuntu Laptop.
  3. Installed SDK Manager on Ubuntu Laptop (after installing required libraries, such as pigz and lbzip2)
  4. I am able to successfully flash the TX2 with the OS image

I am unable to install the SDK components on the host machine (Ubuntu Laptop). I run into a situation where it requires two versions of libdrm-amdgpu1 to be installed at the same time (=2.4.91-2 and >= 2.4.94).

  • libgl1-mesa-dri -> libdrm-amdgpu >= 2.4.97
  • libdrm-dev -> libdrm-amdgpu = 2.4.91-2

I also tried to install the SDK components on the Ubuntu VM (with internet access) but ran into the same issue where multiple versions of libdrm-amdgpu1 are required

I am also unable to install the SDK components on the Jetson because the cuda-samples-10-0 package requires ‘libxmu-dev’ and ‘libxi-dev’, neither of which have packages for the arm architecture on any repositories.

Any help is appreciated.

Thanks

Keep in mind that many of the SDK components require CUDA, which in turn requires an NVIDIA GPU. If the AMD libraries are being requested, then I have to wonder if the host has the required hardware to use CUDA. You can deselect install of components on the host PC and just install to the Jetson if you like.

Btw, VMs often fail. There are connection issues where the PC host to the VM often fails to reconnect USB to the VM as USB disconnects/reconnects.

Hi linuxdev, thanks for your response.

Regarding the Host and VM Installs:
If the SDK requires CUDA which requires an NVIDIA GPU, does that mean that it is impossible to install the SDK and/or compile the examples if the machine does not have an NVIDIA GPU? I can understand not being able to install some of the profiling or visual tools.
Also, I never tried to install to the Jetson from the VM - the Jetson is only connected to the Host machine. Just to clarify, the Host machine is a bare metal Ubuntu Laptop.

Regarding the Jetson Installs:
I did unselect the host and only attempt to install the components on the Jetson TX2, and that still fails due to the dependency issue I noted above - while trying to manually run through the package installs to find the packages that are failing; since aptitude gives no additional information when a package fails other than something was amiss with a dependency. I had to go at least 3 levels lower than the cuda-toolkit-10-0 in order to find that issue.

Is it not possible to actually do an offline install of the SDK to the Jetson? It is surprising to me that the JetPack components includes an image but does NOT include libraries which are actually needed to do the install (see the two noted above: libxmu-dev and libxi-dev, which seem to not have arm64). It is one thing for this to be true of the host, which is unknown hardware, but the TX2 is a known component.

Thank you.

Hello all, update.

I was able to install the SDK components on the Host Laptop Ubuntu 18.04.3 after adding the ‘bionic-updates’ repositories as an option to download packages. This fixed the dependency version collision issue related to libdrm-dev.

See the bionic-updates lines at the following link: https://help.ubuntu.com/lts/serverguide/configuration.html

Copied here for posterity:

deb http://us.archive.ubuntu.com/ubuntu/ bionic-updates universe
deb-src http://us.archive.ubuntu.com/ubuntu/ bionic-updates universe
deb http://us.archive.ubuntu.com/ubuntu/ bionic-updates multiverse
deb-src http://us.archive.ubuntu.com/ubuntu/ bionic-updates multiverse

EDIT: May need to include the ‘main’ and ‘restricted’ groups as well.

As far as installing the SDK on the Jetson itself, I am still unable to do that due to missing the following packages:
libxmu-dev
libxi-dev

Thanks.

To clarify, SDKM/JetPack can install packages on host PC or Jetson. CUDA-related apps may refuse to install on a host if the host itself does not have CUDA, which in turn could be refused if the host doesn’t have an NVIDIA GPU. Sometimes the software can be installed even if it can’t run. Software using a “.deb” package tends to check dependencies, but software which is custom compiled without a “.deb” package isn’t guaranteed to run even if it is installed. The Jetson itself won’t care.

SDK Manager is just a GUI front end to the install process. You need internet access for SDKM to download files which get copied to the Jetson for install.

I have no knowledge of the particular “-dev” components, but typically dev content could require enabling a different Ubuntu repository to get them. I don’t know which components might want those dev packages, but try this from the Jetson:

sudo apt update
sudo apt --fix-broken install
# Make sure all shows "ok" here:
sha1sum -c /etc/nv_tegra_release
# Now try installing dev packages:
sudo apt-get install libxmu-dev libxi-dev

Thank you for your info. The Jetson in my environment does not have internet access, so I am unable to directly get any packages from it. However the ‘fix-broken’ was able to help me at one point.

I was able to follow this process in order to install the SDK components on the Jetson. NOTE: I have not tested anything which I am certain needs the two libraries I had issues with.

  1. Download source for the two packages from ubuntu repo
  2. Build the packages directly on the Jetson post OS install. This may require some additional packages downloaded from a repo.
  3. Install the packages using 'make install'
  4. Create dummy packages for each to ensure that aptitude knows they are installed. See: https://askubuntu.com/questions/18192/how-to-fake-a-package-version-installed
  5. Continue with the SDK installation

Actually performing the installation required going back and forth between the machine that had internet and the Jetson in order to download the arm64 packages necessary, copy them over, and manually install - then hit ‘retry’ on the SDK Manager in order for it to continue.

In case anyone is curious, I had to download over 1000 packages for the Host and Jetson in order to do the offline install on both for 32.2.1. In order to get all of the dependencies of packages, I used a modification of the items found here: https://www.ostechnix.com/download-packages-dependencies-locally-ubuntu/

It seems this is closed now. I’ll update if I find out more. If anyone has questions, please ask.

What you describe is actually a good way to deal with it when you don’t have internet on the Jetson. During flash stage JetPack/SDKM will do any file copy needed, but after the Jetson boots up for the first time there will be parts of the Ubuntu installation which wants internet access. Further package addition from JetPack/SDKM may trigger apt to try and add missing dependencies, and if there is no internet, then the manual process you described is probably the only way to proceed.

Just a thought that if you were to figure out how to add a repository on your host PC with a mirror of all packages needed, and then add that repository to the apt configuration of the Jetson, then this might work for a production environment if you plan to repeat this many times (the host PC would be accessible even if the internet is not).

Sounds like for a production/deployment environment, we will need to dig into the actual scripts the SDK manager runs and inject some custom scripts/files in order to set up that repository.

If this sounds like the correct path, are there any resources on how that process works from a lower level, say the scripts run and the resources they need? So far I have not found anything beyond “Use the SDK Manager”. My current path is to use the SDK manager once and try to use the terminal window to look at all of the actions it performs.

I always prefer to flash on command line. So long as your host already has had the flash side set up, then there is no more need for the internet during flash. If you use a clone this is especially useful, but it depends on what you are doing.

In terms of internet access you will find a “repository.json” file. This is XML, and it shows a base URL near the top, followed by a number of packages to download from that base URL (listed by architecture). If you know the order to install, then it is just a case of copy to the Jetson and then dpkg to install.

Of course if you use a clone, and the clone had all package updates prior to cloning, then all that is complete immediately after flash. For example, account names/passwords are cloned…if you already did first boot with some standardized account, then it is all there. You could script a change to password if desired. More importantly, lets say you manufacture 100 devices at a time. Imagine the network bandwidth to do the initial apt update and apt-get upgrade when each one would take an hour…only now you are doing this with 100 at a time. A cloned unit which was updated may be slightly out of date by the time you ship, but any update would be no more than a minute or so instead of an hour or more.

Incidentally, if you check logs and see the order of package install, then that’s a short cut to figuring out dpkg install order when manually installing packages without the SDKM. One thing I’m not sure of is how you might automate any password login to the developer packages, but it shouldn’t be too hard.