Flashing Jetson TX1 on VMware – Which Ubuntu/JetPack Version & Method?

Hi,

Initially, I successfully flashed my Jetson TX1 using the flash.sh script after manually downloading the Driver Package and Sample Root File System. The flash process worked fine.

However, I later faced difficulties installing packages like OpenCV and other dependencies on the Jetson device. So, now I want these to be installed properly and compatibly during the flash process itself.

This time, I plan to use a VMware Ubuntu environment to perform the flash.
I have a few questions:

  1. Which Ubuntu version should I use in the VMware guest for best compatibility with Jetson TX1?
  2. Which JetPack version should I use (JetPack 3.3 vs 4.4)?
  3. Should I use the SDK Manager, or stick with the run installer method (like in JetPack 3.3)?
  4. Which method provides better compatibility for pre-installing libraries like OpenCV, CUDA, etc.?

Additionally, I’m wondering if it’s possible to use the SDK Manager or the JetPack run installer just to install the required libraries (like CUDA, OpenCV, cuDNN, etc.) without actually flashing the device again. If that’s possible, which version should I use for that purpose?

Thanks in advance!

A TX1 has a highest release version of L4T R32.x (JetPack 4.x flashes this). Your host PC would work if it is Ubuntu 18.04. The L4T release leads to the JetPack and other software, see this URL to find the release:
https://developer.nvidia.com/linux-tegra

Technically a VM is not supported. The most common problem is that USB has to be completely owned for that device by the VM. USB will disconnect and reconnect, and if the VM fails to pick up the reconnect, then it’ll stall and never complete.

Also, when you start JetPack via “sdkmanager” (or, to see older releases, “sdkmanager --archived-versions”…possibly “sdkmanager --archivedversions” if old enough), it isn’t usually obvious that you can uncheck flash and uncheck host PC component installs. Just be sure you use the correct matching release. Your Jetson should show its L4T release with “head -n 1 /etc/nv_tegra_release”.

JetPack 3 was for L4T R28.x, and you should stay away from that unless you very definitely need R28.x.

Note that during a flash the Jetson starts in recovery mode, and in turn, this turns the Jetson into a custom USB device. When flashing with JetPack the Jetson will automatically reboot after the flash, and at that point you would have an admin login account with ssh access. JetPack does not install the software options during flash, it waits until base flash is complete, and then expects an ssh route to the Jetson to install those other apps on the running Jetson. If you were to uncheck flash, then you would also choose to not start in recovery mode; you’d want a fully booted Jetson ready. In this way you can pick what you want to install without flashing again. I will emphasize that it is not usually obvious as to what parts you can uncheck, and you can try clicking on the item to see if it is able to be changed in the JetPack GUI.

Hi,

I’m running Ubuntu 18.04 in a virtual machine, but it frequently freezes. To recover from these freezes, I usually suspend the guest and then resume it. In order to avoid interruptions, I connect remotely via SSH and run sdkmanager --cli from the terminal to install JetPack components.

However, the freezing still happens from time to time, and I have to suspend/resume the VM again to continue working. My first question is:

  • When I suspend and resume the VM during a CLI-based SDK Manager installation, will it interrupt the download or installation process? Will SDK Manager continue from where it left off or will I need to restart the process?

Secondly, even when the system does not freeze, I still encounter frequent download failures with the SDK Manager CLI. For example, I receive errors like this:

error: Download 'CUDA on Host' failure                                                                                                                                                               
││error: Download 'CUDA on Host' failure  
││error: download failed      
││info: download https://developer.nvidia.com/assets/embedded/secure/tools/files/jetpack-sdks/jetpack-4.6.6/Jetson_466_b24/ubuntu1804/cuda-repo-ubuntu1804-10-2-local_10.2.460-450.115-1_amd64.deb     ││failed, retrying 1...                                                                                                                                                                               
 ││info: wait for 4.031 sec before retry https://developer.nvidia.com/assets/embedded/secure/tools/files/jetpack-sdks/jetpack-4.6.6/Jetson_466_b24/ubuntu1804/cuda-repo-ubuntu1804-10-2-local_10.2.460- ││450.115-1_amd64.deb                                                                                                                                                                                  
││info: start to download https://developer.nvidia.com/assets/embedded/secure/tools/files/jetpack-sdks/jetpack-4.6.6/Jetson_466_b24/ubuntu1804/cuda-repo-ubuntu1804-10-2-local_10.2.460-450.115-1_amd6 ││4.deb to /home/ubuntu/Downloads/nvidia/sdkm_downloads/cuda-repo-ubuntu1804-10-2-local_10.2.460-450.115-1_amd64.deb                                                                                   
││error: Download 'Drivers for Jetson' failure                                                                                                                                                         
││error: Download 'Drivers for Jetson' failure                                                                                                                                                        
 ││error: download failed                                                                                                                                                                               
││info: download https://developer.nvidia.com/assets/embedded/secure/tools/files/jetpack-sdks/jetpack-4.6.6/Jetson_466_b24/T210/Jetson-210_Linux_R32.7.6_aarch64.tbz2 failed, retrying 1...    
││info: wait for 4.718 sec before retry https://developer.nvidia.com/assets/embedded/secure/tools/files/jetpack-sdks/jetpack-4.6.6/Jetson_466_b24/T210/Jetson-210_Linux_R32.7.6_aarch64.tbz2           
││info: start to download https://developer.nvidia.com/assets/embedded/secure/tools/files/jetpack-sdks/jetpack-4.6.6/Jetson_466_b24/T210/Jetson-210_Linux_R32.7.6_aarch64.tbz2 to /home/ubuntu/Downloa ││ds/nvidia/sdkm_downloads/Jetson-210_Linux_R32.7.6_aarch64.tbz2 
│error: Download 'cuDNN on Target' failure                                                                                                                                        
││error: Download 'cuDNN on Target' failure                                                                                                                                         
││error: download failed                                                                                                                                                                               
││info: download https://developer.nvidia.com/assets/embedded/secure/tools/files/jetpack-sdks/jetpack-4.6.6/Jetson_466_b24/./libcudnn8_8.2.1.32-1+cuda10.2_arm64.deb failed, retrying 2...          
││info: wait for 8.805 sec before retry https://developer.nvidia.com/assets/embedded/secure/tools/files/jetpack-sdks/jetpack-4.6.6/Jetson_466_b24/./libcudnn8_8.2.1.32-1+cuda10.2_arm64.deb           
││info: start to download https://developer.nvidia.com/assets/embedded/secure/tools/files/jetpack-sdks/jetpack-4.6.6/Jetson_466_b24/./libcudnn8_8.2.1.32-1+cuda10.2_arm64.deb to /home/ubuntu/Download ││s/nvidia/sdkm_downloads/libcudnn8_8.2.1.32-1+cuda10.2_arm64.deb    

What could be the reason behind these repeated download failures?

Thanks in advance for your help.

(Using Jetson Linux R32.7.6, JetPack 4.6.6)
Instead of cuda on host failure i also get ‘CUDA Cross Compile Package on Host’ failure


I can’t answer most VM questions, I just don’t know. The cases I am aware of involve USB, and setup of the VM itself is something I’ve never worked on. Every brand of VM would require its own support from the VM manufacturer since flash software has no awareness of being in a VM. When installing software after flash (or at least while fully booted and not in recovery mode) there are checksums in the regular package system commands, and so I would think a package install would fail (and be obvious), or else succeed without corruption. dpkg itself, and apt, tend to detect errors.

In the case of failed downloads there are of course legitimate network issues which might not be part of the VM, and which would be out of its control. However, networking would tend to have a need to be verified as to whether it is the VM or something else; there simply isn’t a good answer that I know of. There have certainly been times when the NVIDIA download website has been down. If the log tells you about a web address failure, then typically you can go there with your browser and see if it works from the VM’s host, and then again from the VM itself if the host succeeded to see what happens. As an example from your log, examine this address from a log line:
https://developer.nvidia.com/assets/embedded/secure/tools/files/jetpack-sdks/jetpack-4.6.6/Jetson_466_b24/./libcudnn8_8.2.1.32-1+cuda10.2_arm64.deb

In that log line you could try simple browser access first to the domain:
https://developer.nvidia.com

Then you could see if going to the full address downloads that file. If it says something about the file missing or the web site being unreachable, then you know it isn’t the VM. If this works fine to retrieve the file on the VM’s parent, but not in the VM, then you know it is a VM setup issue. There isn’t much one can actually do from the software end if the VM is not configured since the flash software has no control over the VM.

Hi,

After downloading the BSP and Sample Root Filesystem from the following page:
Jetson Linux R32.7.6 | NVIDIA Developer
I performed a clean flash on my Jetson TX1 using ./flash.sh. When I connect the TX1 to a monitor via HDMI, I can see a Linux-based system running.

Now, I want to manually download the files listed under the “Drivers / Sources / Tools” section for TX1 (on the same page) (if they are all needed i don’t know) directly onto the board after connecting it to the internet.

Can you help me understand:

  • How to properly install these packages once they are downloaded?
  • Is there a specific order in which I need to install them?
  • After downloading, what commands should I use to proceed with the installation?

I’m asking this because SDK Manager is having trouble connecting to the download server, so I decided to follow the manual method instead.

Thanks in advance for your help!

“Proper” download can be a number of ways, but not necessarily the same effort. By far the best method is to download JetPack/SDK Manager, run that, uncheck flash, and leave checked anything you want to add. The Jetson would not be put in recovery mode, but is fully booted, and has a network connection with the host PC. Then just run JetPack and have it install the checked components (presumably you’ve unchecked flash).

Note that you know your L4T release is R32.7.6, and you can start JetPack/SDKM like this and see particular releases if needed:
sdkmanager --archived-versions
(far enough in the past it was “--archivedversions”)

Jetsons are full Linux computers, with Ubuntu installed (L4T is just Ubuntu plus NVIDIA drivers…Ubuntu documentation applies). With a network connection you would typically update packages with:

sudo apt update
sudo apt-get upgrade

(this is just package update, not major version update)

You can find packages as well, but one problem people sometimes run into is if something was skipped in install, then sometimes one of the NVIDIA-specific repos was not enabled. More generically, even if the content is not for NVDIA-specific repos, then you might still need to enable a report to see special packages, e.g., debug packages, source code packages, so on. You might need to just check if something you want is visible or not, and if it is visible with something like “apt search <package name or key word>”, then use the Ubuntu mechanism (e.g., “sudo apt-get install <package name>”.

Some packages must only be from the Jetson repositories. GPU drivers are the most common case. The GPU is an integrated GPU (iGPU) wired directly to the memory controller, whereas the drivers you see for non-Jetson products are intended to work with discrete GPUs (dGPU) attacked indirectly via the PCIe bus.

You don’t necessarily need any of the repositories which are commented out in “/etc/apt/sources.list”, but you could examine it and look at the ones which are commented out as there might be something you are looking for not fitting in the default repo categories. If you uncomment one, then run “sudo apt update” so package searches will see the new content.

Regarding SDKM having trouble connecting to the download server, can you give some more detail?

The problem of not using sdkmanager is that you’ll have to know the package you are interested in. As an example, there might be confusion if running “apt search cuda”; in theory only compatible cuda packages would show up, but a lot which is compatible won’t be there unless the correct repo is enabled, and if you don’t know the exact name of a package, then you can spend a long time searching for it before finding it (JetPack/SDKM knows the exact package list and does not have that issue).

As long as the GPU or bootloader is not involved, then pretty much every Ubuntu arm64/aarch64 package you see in an either apt search or from an outside .deb provider will work. CUDA and GPU drivers are on the list of things which you never want to install from non-Jetson repos.

It is probably easier to fix the JetPack/SDKM issue than to search for every package name, but someone else here probably has a list, or at least repository list. If JetPack/SDKM cannot be saved (it usually can if the host PC is the correct release…login and network issues can be fixed), then it might be good to start a new topic to get the list of optional package names and their repository specs (if you have that list it is trivial to install everything without JetPack).

Hello again,

I hope this will be my final question.

First of all, I switched from VMware to VirtualBox and completely resolved the freezing issue.
I installed the NVIDIA SDK Manager and started it using the GUI. I selected the “Download now, install later” option and successfully began the download process.

I was able to download everything except for CUDA under “Host Components” and CUDA under “Jetson SDK Components”.
For both CUDA components, I’m getting a “Cuda on host” error and they won’t download.

Is it possible to manually install CUDA from within SDK Manager by guiding the installation process somehow? If so, how can I do that?

My idea is to flash the board without CUDA first, and since I know the exact SDK Manager version I’m using, I could find out which version of CUDA it tries to install. Then, I would manually install the correct version of CUDA after flashing. That way, I’d still have a clean and functional flash.

If there’s any documentation specifically about manual CUDA installation for Jetson devices, I would really appreciate it if you could share it.

Additionally, I will only have access to the board on Monday, so I’ll be able to share the detailed logs related to the “CUDA on host” failure on that day.
However, in the response I posted on July 24, the error message I received is partially visible at the bottom of the last image I attached.

Thanks in advance!

Does your host PC have (A) an NVIDIA GPU, and (B), the NVIDIA driver running it (there is a Mesa driver as well, and I don’t know if JetPack/SDKM can replace that with NVIDIA’s driver when not present)?

To start with, you can run the “download now, install later” again, and you can uncheck all operations except for CUDA under Jetson. Try to skip all host side operations first. If you have everything for the Jetson itself then you are far ahead of the game; then, later on, if you choose, you can either work on fixing the host side install or debugging it or skipping it. The real takeaway from this is that you can uncheck everything and separate into individual steps and run the process again and again; you don’t even need the Jetson attached for host side operations, and you don’t need to flash; if you do operate on a Jetson with JetPack/SDKM, then you can uncheck flash and everything except a single package to see what happens with that one package.

Incidentally, if the flash is correct, then most likely the NVIDIA repositories are installed to the Jetson. Try “apt search nvidia”. This might be too much output, and you could use “apt search nvidia | less” to get a pager. If you see a package you want, and if it isn’t already installed, then you could try “sudo apt-get install <package name>”.

You might also want to attach a copy of “/etc/apt/sources.list” from the Jetson if you don’t see what you are looking for in “apt search”. Some repositories are just commented out by default.

Regarding host side, there is a command which might be of interest, xdpyinfo (package x11-utils has this; if you don’t have it, then you can “sudo apt-get install x11-utils”). What do you see from this on the host PC (this is about host PC drivers, not Jetson):
xdpyinfo | egrep -i '(version|nvidia)'

Hello,

I’ve resolved the “CUDA on Host” error, and using the “Download Now, Install Later” option, I successfully downloaded everything. Now, I’m starting the flashing process, but it gets stuck at 99% during “Flash Jetson OS” and then stops. I couldn’t find any clear errors in the logs. I’m attaching the logs below.

Can you please help me figure out what’s going wrong?
SDKM_logs_JetPack_4.6.6_Linux_for_Jetson_TX1_2025-07-28_14-50-42.zip (131.2 KB)

At the end of the “sdkm-2025-07-28-14-49-36” file there are errors:

*** End of Install Summary ***
15:31:13.168 - info: Event: Session ended - failure
15:31:13.168 - info: Setting SessionInitialStatus with value: Download: 100. Install: 80
15:31:13.168 - info: Setting custom dimension value SessionInitialStatus - Download: 100. Install: 80
15:31:13.170 - error: completeSetup failed. Error:
15:31:13.170 - error: install process failure
15:31:13.178 - info:
********************** Completed install for bundle JetPack 4.6.6 Linux for Jetson TX1 time: 28-Jul-2025-15.31:13 is succeeded: false **********************
15:31:13.259 - info: Engine.install is complete.
15:31:13.279 - error: command error code: 123
15:31:13.279 - info: Event: - error code is: 1123
15:31:13.279 - warn: Failed to get component from group data map for
15:31:13.279 - error: command terminated with error
15:31:13.319 - error: Found unhandledrejection Promise {
“command < ps aux | grep NV_L4T_FLASH_TX1_WITH_OS_IMAGE_COMP | grep -v grep | awk ‘{print $2}’ | xargs kill -9\r > terminated with error, exitCode: 123.”
}

There are also these lines in the middle of the log file :

14:50:31.755 - debug: NV_CUDA_HOST_COMP platforms[0] filtered out: os not supported: host [ubuntu18.04], supported os [ubuntu16.04]
14:50:31.758 - debug: NV_VPI_HOST_COMP platforms[0] filtered out: os not supported: host [ubuntu18.04], supported os [ubuntu16.04]
14:50:31.758 - debug: NV_L4T_NVIDIA_NSIGHT_SYSTEMS_LEGACY_HOST_COMP platforms[0] filtered out: os not supported: host [ubuntu18.04], supported os [ubuntu16.04]

In general, I encounter too many errors with the TX1 board. Can you recommend a stable Linux for Tegra version that works reliably with minimal issues? For example, something like linux-tegra-r3276. Also, which Ubuntu version should I use on the host PC to install that specific L4T version?

Additionally, would it be more reliable to flash the board using only the “Driver Package (BSP)” and “Sample Root Filesystem” via ./flash.sh, without using SDK Manager?

These are the best solutions I can think of for now.
Thank you!

The VM is 99.999% of the time the cause of a paused flash. Technically configuring the VM to work with a USB disconnect/reconnect is the solution, but USB is hot plug, so you could try to just unplug and replug the USB cable if it stalls.

The host PC is the intersection of two requirements. JetPack/SDK Manager has a range of Ubuntu hosts it works with, and the flashed target has the other range of hosts you can flash with. Usually it is the target board type limiting what host works. A host PC with Ubuntu 18.04 will always work for JetPack/SDKM or command line flash of a TX1 developer’s kit.

For TX1 (including the original Nano) and TX2 I suggest the latest L4T R32.x. A listing of compatible releases:
https://developer.nvidia.com/linux-tegra

Note that each L4T release is coupled with a given JetPack/SDKM release. However, JetPack/SDKM can flash earlier releases as well. One would normally start JetPack/SDKM on command line like this:
sdkmanager

On older JetPack/SDKM releases one would see a wider listing of L4T releases it can flash via:
sdkmanager --archivedversions

Even semi-recent releases of JetPack/SDKM see historic releases via:
sdkmanager --archived-versions

An actual list of JetPack/SDKM releases is here:
https://developer.nvidia.com/embedded/jetpack-archive

Do expect a VM to imply failure is likely unless you’ve gone through a lot of configuration effort which the flash software has no control over.

Downloading and running via “sdkmanager” does in fact download the driver package (BSP) and sample rootfs, then it applies the NVIDIA content to the sample rootfs. It isn’t until you go to install optional software that it does something different, but that difference is applied via network ssh (a fully booted Jetson will have the flash USB cable show up as a network device to the host PC). Unchecking everything except flash is in fact that simplest case. For cases of stalling when using a VM, then it won’t matter if it is directly the BSP+rootfs or if it is flashing via JetPack, it will be the VM getting in the way far far more often than anything else. Disk space can also be an issue, so you might run “df -H -T .” (the . is important) from the “Linux_for_Tegra/” location if you see a stall to see if disk is running out of space.

However, if this is a TX1 developer’s kit, then this command line works from an L4T R32.x command line (at “Linux_for_Tegra/”):
sudo ./flash.sh jetson-tx1-devkit mmcblk0p1 (this is not for Nano, though it is similar)

You could log that flash like this:
sudo ./flash.sh jetson-tx1-devkit mmcblk0p1 2>&1 | log_flash_tx1.txt

Do note that there is an interesting utility script for use with login name/password. Normally a Jetson will go through first boot account setup after a flash, and that admin name/pass is used for installing optional software like CUDA if using JetPack/SDKM (and is still quite easy to use for command line; every flash from that content will then have the admin name/pass and first boot setup complete). That would be:
sudo ./l4t_create_default_user.sh
(this overlays the “Linux_for_Tegra/rootfs/” with the account setup and is needed only once; beware to never use this near something you are shipping to a customer unless you are intending this)

Trivia: The BSP (driver package) was the only means of flash on command line for a very very long time. JetPack only came later during the Jetson’s early life (Tegra devices have been around a lot longer than the Jetson series of Tegra devices). This did not originally have “smart networking” and was just JetPack without SDK Manager. Then SDKM was added; not sure when, maybe around L4T R27.x or 28.x. Many people thought command line was too complicated. Prior to this though it was easy to use command line on just about any Linux distribution or version so long as it had the requirements. I was strictly using Fedora back then.

I decided to switch to JetPack 3.3 — it seems to be the most efficient option for me. Everything gets downloaded, but during the flash process, it always freezes at this line. What could be the solution?


flash_os_64_tx1.log (159.6 KB)

It seems to be a normal/working flash up until then, and I don’t know why it just stops. Going back to that earlier release though some instructions are different; it wasn’t until mid L4T R32.x that flash options became more or less standardized. Most people don’t care to use Ubuntu 16.04 due to age, and I’m wondering if maybe some repository is missing (though it would not make sense since there should be a log entry about not reaching a repository). In particular, this was more or less just JetPack or command line, and SDK Manager (the smart network layer) was only starting to be thought about.

I still suspect a VM is the issue, and that going back to JetPack 3.x (L4T R28.x) won’t really fix anything.


Since I did not want to leave the topic unresolved, I am listing below the issues I encountered and resolved.

First, when flashing the board and installing the necessary packages, avoid using a virtual machine if possible.
If you must use a virtual machine, research them thoroughly. In my case, the biggest problem I encountered was the virtual machine freezing. I resolved this by using Oracle VirtualBox instead of VMware. (During the flashing process, the USB connection must remain uninterrupted; many virtual machines have issues with USB disconnections, which can be another problem you might face.)

When flashing, you can use NVIDIA SDK Manager or .run files.
If you experience problems during the flashing process—whether in loading the necessary packages or installing the operating system—I recommend manually flashing by downloading the required Driver Package and Sample Rootfs, extracting them via tar, and running ./flash.sh.

Afterward, to download the compatible libraries provided by the NVIDIA SDK Manager or .run files, run SDK Manager on your virtual machine (assuming you are using SDK Manager) and select the Download now, install later option to download the files.
Then, connect to your board remotely via SSH and transfer the downloaded files to the board using the scp method.
Extract the transferred files with tar and perform the required installations.

In this method, make sure you have also downloaded the services that the libraries depend on. Finally, note that the SDK Manager installs the libraries in a specific order. By paying attention to this, you will be able to successfully flash the device and install the required libraries.

I hope this will be helpful to anyone facing similar issues.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.