SDKManager fails to create image


I’m trying to flash the Jetson TX2 developer kit with SDK Manager v0.9.13.4763 from a Ubuntu 18.04 within a virtual machine that is getting its internet access through a proxy. The proxy is configured in the SDK Manager as well as in the apt.conf.

I can download successfully, but while installing I get an error at 5.88% progress

ERROR : install 'Bzip2 Patch Setup In Target Image' failure, UBUNTU_BZIP2_PATCH_IN_TARGET_IMAGE install timeout

If I choose to ignore this error, there will be more errors down the line, e.g. in Nsight graphics. Ultimately, if I ignore all of them, installation fails. I have tried several times, it always fails at the same point.

Is this a known problem? Is there a workaround to create the image outside of the SDK Manager?


You might be seeing a bug in a recent bzip2 update on the host PC. See:

Thanks, that does look similar, however downgrading bzip2 and did not solve the problem for me. The timeout still happens. I can’t rule out a network issue either within my company network. I’ll try to run past all errors and get the log.

From the logs, I’m guessing it may be a problem of the proxy server in my company network.

What’s the alternative to using the SDK manager? I don’t really see a clear documentation on what else I can download and manually flash, at least a OS first, from which I can then manually add the components (CUDA, OpenCV etc.) later if I choose to do so.

You can download and flash on command line, but extra package install is only available through SDKM. The R32.2 content (which is what SDKM/JetPack4.2.1 installs, but only after flash completes) is here:
(you’ll have to go there, log in, and then go there again since redirects don’t work)

You’ll want the “L4T Driver Package” and “Sample Root Filesystem”. You’d unpack the driver package (do not use sudo), cd into the “Linux_for_Tegra/rootfs/” directory, unpack the rootfs (use sudo), cd back to the “Linux_for_Tegra/” directory, and then run “sudo ./”. You only need to do this once. After this you are free to flash on command line.

To flash on command line make sure the TX2 is in recovery mode and the micro-B USB cable is connected. You will know this is working if you see output from “lsusb -d 0955:7c18”. Then:

sudo ./ jetson-tx2 mmcblk0p1

If you need to use SDK Manager for package download from that computer, then you’ll have to get the IT guys to set up the proxy for it. As you mentioned, you can add extra packages at any time (just uncheck flash). If you run JetPack/SDKM from another computer and check only to install TX2 extra packages, then you might be able (with some difficulty) to use the downloaded packages from “~/Downloads/nvidia/sdkm_downloads/” to install the “arm64” and “all” (architecture independent) packages to the Jetson.

Thanks a lot, that looks great! It may be the best workaround if the SDK Manager has problems with the proxy.

Meanwhile, I hope that Nvidia may release a Windows version of the SDK Manager because many companies (unfortunately) use Windows development machines… which would get rid of the workaround to use a VM for Linux.

A Windows version isn’t really a practical possibility. The flash program itself is a binary executable compiled for Linux, and Windows can’t handle that. You might be thinking that it could just be recompiled, but there are a number of features in the Linux environment which Windows itself can’t handle (and building those features custom would be a massive effort).

As an example, Windows does not understand the ext4 file system. Without this it isn’t possible to format an image for Linux since Windows does not understand Linux file permissions. Now if you did talk Microsoft into native support of ext4, you’d still need to add loopback device support. Then you’d need to make sure open source or free compilers capable of cross compile and cross linking are added; this can be done, but you’re already exceeding the effort of just installing Linux. There are a number of smaller issues you’d run into.

VMs will work for this after a bit of a learning curve to give the VM control of USB and perhaps networking. VMs are not supported due to a number of headaches, but they do tend to work with enough effort, and this effort is far far lower than porting to Windows.

Understood, I was not really serious about the Windows version. Since I cannot install Linux, I will continue with the VM.

I can confirm now that the manual installation within the VM worked. So I would summarize for VM usage within Windows:

  • If you have direct internet connection, the SDK Manager is probably the best way to go
  • If you need to access the internet from the VM via a proxy server, the manual installation as described in the L4T development guide may be a better approach. Just please note that USB connections may be sketchy. I searched for some tricks on this forum to get it working, e.g. this page