I can’t flash my TX2 developer kit with SDK manager. I follow the official Nvidia SDK manager documentation. Everything is going well before I enter ‘Install Jetson software with SDK manager’. In the 3rd step, when it’s ready for SDK manager to flash my target device, I choose ‘Manual Setup’ and follow the prompted instructions to connect my device with the host and to make the device into the forced recovery mode and clicked ‘flash’ button. ‘Flashing failed’ is always shown on my screen. I ‘ve checked the device is connected with my host computer by ‘lsusb’ in the Terminal. Then I retry the whole step 3, but follow the instructions of ‘Place system in Force USB Recovery Mode’ in the quick start guide of Jetson TX2 developer kit instead of the steps shown in the prompted instructions. It doesn’t work either. Errors in the terminal tab are as follows. What should I do? BTW, should I connect TX2 with the host at step 1 ‘development environment’ or at step 3 ‘setup process’? Should I connect the display screen with TX2 when flashing?
ERROR : Could not detect NVIDIA Jetson device connected to USB. Verify that: 1. The device is connected to this host machine with a USB cable. 2. Jetson’s Ubuntu OS is up and running. 3. Ubuntu ‘System configuration wizard’ is completed on the device. This can be validated by running the ‘lsusb’ command on your host, and look for “0955:7c18” (NVIDIA Corp).
ERROR : Could not detect NVIDIA Jetson device connected to USB. Verify that: 1. The device is connected to this host machine with a USB cable. 2. Jetson’s Ubuntu OS is up and running. 3. Ubuntu ‘System configuration wizard’ is completed on the device. This can be validated by running the ‘lsusb’ command on your host, and look for “0955:7c18” (NVIDIA Corp). Or use the ‘Manual Setup’ instead.
ERROR : Flash Jetson TX2 : /usr/bin/env: ‘python’: No such file or directory
Recovery mode is used during flashing. Once flash completes, the unit reboots and “optional” packages are then installed over ssh. Recovery mode can only be via the micro-B USB, while there are options for ssh since a regular wired ethernet or a virtual wired ethernet over USB works. If flash fails, then reboot to a mode where ssh can be used won’t exist.
So we have to look first at recovery mode over USB. About 99% of the time this is from people using a VM, and VMs do not handle USB correctly without extra work. Are you using a VM? If so, then know that USB is constantly disconnecting and reconnecting during a flash, and a VM typically only has the first connection, and reconnect then fails. Similarly, using a charger cable instead of the supplied micro-B USB cable will probably have issues since third party charger cable have rather low quality and tend to fail for long data transfers.
“Python” being missing is another story. This is on host side, and there was a transition between applications using Python 2.x and then 3.x during the Ubuntu 18.04 time period. If you don’t use a VM (and even if you do), then you need to be sure you have the right Python installed (sorry, SDK Manager does not check this, but should). Does this install? sudo apt-get install python
What do you see from “which python”? Or “python --version”? “which python2” or “which python3”? (all from host PC)
Hi! linuxdev
Thanks for your instant reply!
I do flash the target device by using Ubuntu 18.04 from the VMware Workstation 15.5 Pro. I set USB to always connect to the VM first. I checked that I didn’t install Python before, then I installed Python as directed. The installed version is Python 2.7.17. At this stage, I think the Jetson OS installation is going well. After the SDK manager completed the flashing process by manual setup[Fig.1 attached], I connected the monitor with TX2 and found some information was shown on the monitor[Fig.2 attached]. It’s been 3.5h since I replied to you. And it seems continued, which makes me confused. Is there something wrong? Or it’s the normal process of SDK components installation.
Fig.1
In more recent releases one has to do the admin account setup on first boot. This is what the “start job” here is about. Can you try attaching a monitor and keyboard before the flash starts? Then look for the system rebooting just like this, except it should ask you about a user name and password to use.
About:
It is this account created at first boot which the next step (adding optional software) uses. This is why it cannot continue until the first account setup is done. I think sometimes the system does not work right if you wait until after the flash to connect the monitor/keyboard. Some people use a serial console as well for this step. However, the flash itself seems to have completed correctly and once first account setup is done it should allow everything else. Having the monitor/keyboard attached prior to flash may allow it to work correctly without any extra effort.
I retried the whole steps as directed with all external peripheral devices connected to TX2. The flashing of Jetson OS is successful and the OS login screen finally appears, but to my disappointment, Jetson SDK components installation failure is reported as follows. I login into the TX2 and find it’s a pure OS. As a novice, I truly need your help! Any feedback you can give me on this would be much appreciated.
These are some intercepted error reports.（New users can only put 3 links in a post. username@IP is substituted for asd@192.168.32.1）
• 09:45:39 INFO : hello
• 09:45:39 INFO : command finished successfully
• 09:45:39 INFO : Validated its username and password.
• 09:45:39 DEBUG : using adapter to query target component: NV_L4T_CUDA_TARGET_POST_INSTALL_COMP version: 10.2 for bundle:
• 09:45:39 INFO : Using GenericInstaller to Query NV_L4T_CUDA_TARGET_POST_INSTALL_COMP
• 09:45:39 INFO : change working directory to /tmp
• 09:45:39 INFO : exec_command: ssh -F /dev/null -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no asd@192.168.32.1"dpkg-query -W -f=‘${db:Status-abbrev} ${Version}’ cuda-toolkit-10-2"
• 09:45:40 INFO : [target] username@IP’s password:
• 09:45:40 INFO :
• 09:45:40 INFO : Target Deb package [{cuda-toolkit-10-2 10.2}] not installed; [deb_name]: cuda-repo-l4t-10-2-local-10.2.89_1.0-1_arm64.deb
• 09:45:40 ERROR : command terminated with error
• 09:45:40 DEBUG : using adapter to query target component: NV_L4T_CUDNN_TARGET_POST_INSTALL_COMP version: 8.0 for bundle:
• 09:45:40 INFO : Using GenericInstaller to Query NV_L4T_CUDNN_TARGET_POST_INSTALL_COMP
• 09:45:40 INFO : change working directory to /tmp
• 09:45:40 INFO : exec_command: ssh -F /dev/null -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no name@IP “dpkg-query -W -f=‘${db:Status-abbrev} ${Version}’ libcudnn8”
• 09:45:40 INFO : [target] username@IP’s password:
• 09:45:40 INFO :
• 09:45:41 INFO : Target Deb package [{libcudnn8 8.0.0.145-1+cuda10.2}] not installed; [deb_name]: libcudnn8_8.0.0.145-1+cuda10.2_arm64.deb
• 09:45:41 ERROR : command terminated with error
• 09:45:41 DEBUG : using adapter to query target component: NV_L4T_TENSORRT_NODLA_TARGET_POST_INSTALL_COMP version: 7.1 for bundle:
• 09:45:41 INFO : Using GenericInstaller to Query NV_L4T_TENSORRT_NODLA_TARGET_POST_INSTALL_COMP
• 09:45:41 INFO : change working directory to /tmp
• 09:45:41 INFO : exec_command: ssh -F /dev/null -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no username@IP “dpkg-query -W -f=‘${db:Status-abbrev} ${Version}’ libnvinfer7”
• 09:45:41 INFO : [target] username@IP’s password:
• 09:45:41 INFO :
• 09:45:41 INFO : Target Deb package [{libnvinfer7 7.1.0-1+cuda10.2}] not installed; [deb_name]: libnvinfer7_7.1.0-1+cuda10.2_arm64.deb
• 09:45:41 ERROR : command terminated with error
• 09:45:41 DEBUG : using adapter to query target component: NV_L4T_OPENCV_TARGET_POST_INSTALL_COMP version: 4.1.1 for bundle:
• 09:45:41 INFO : Using GenericInstaller to Query NV_L4T_OPENCV_TARGET_POST_INSTALL_COMP
• 09:45:41 INFO : change working directory to /tmp
• 09:45:41 INFO : exec_command: ssh -F /dev/null -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no username@IP “dpkg-query -W -f=‘${db:Status-abbrev} ${Version}’ libopencv”
• 09:45:41 INFO : [target] username@IP’s password:
• 09:45:41 INFO :
• 09:45:42 INFO : Target Deb package [{libopencv 4.1.1-2-gd5a58aa75}] not installed; [deb_name]: OpenCV-4.1.1-2-gd5a58aa75-aarch64-libs.deb
• 09:45:42 ERROR : command terminated with error
• 09:45:42 DEBUG : using adapter to query target component: NV_L4T_VISIONWORKS_TARGET_POST_INSTALL_COMP version: 1.6 for bundle:
• 09:45:42 INFO : Using GenericInstaller to Query NV_L4T_VISIONWORKS_TARGET_POST_INSTALL_COMP
• 09:45:42 INFO : change working directory to /tmp
• 09:45:42 INFO : exec_command: ssh -F /dev/null -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no username@IP “dpkg-query -W -f=‘${db:Status-abbrev} ${Version}’ libvisionworks”
• 09:45:42 INFO : [target] username@IP’s password:
• 09:45:42 INFO :
• 09:45:43 INFO : change working directory to /tmp
• 09:45:44 INFO : [target] username@IP’s password:
• 09:45:44 INFO :
• 09:45:45 INFO : Target Deb package [{vpi 0.2.0}] not installed; [deb_name]: vpi-lib-0.2.0-cuda10-aarch64-l4t.deb
• 09:45:45 ERROR : command terminated with error
• 09:45:45 DEBUG : using adapter to query target component: NV_L4T_DOCKER_TARGET_POST_INSTALL_COMP version: 0.9.0 for bundle:
• 09:45:45 INFO : Using GenericInstaller to Query NV_L4T_DOCKER_TARGET_POST_INSTALL_COMP
• 09:45:45 INFO : change working directory to /tmp
• 09:45:45 INFO : exec_command: ssh -F /dev/null -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no username@IP “dpkg-query -W -f=‘${db:Status-abbrev} ${Version}’ nvidia-container-csv-cuda”
• 09:45:45 INFO : [target] username@IP’s password:
• 09:45:45 INFO :
• 09:45:46 INFO : Target Deb package [{nvidia-container-csv-cuda 10.2.89-1}] not installed; [deb_name]: nvidia-container-csv-cuda_10.2.89-1_arm64.deb
• 09:45:46 ERROR : command terminated with error
• 09:45:46 DEBUG : using adapter to query target component: NV_L4T_MULTIMEDIA_API_TARGET_POST_INSTALL_T186_COMP version: 32.4 for bundle:
• 09:45:46 INFO : Using GenericInstaller to Query NV_L4T_MULTIMEDIA_API_TARGET_POST_INSTALL_T186_COMP
• 09:45:46 INFO : change working directory to /tmp
• 09:45:46 INFO : exec_command: ssh -F /dev/null -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no username@IP “dpkg-query -W -f=‘${db:Status-abbrev} ${Version}’ nvidia-l4t-jetson-multimedia-api”
• 09:45:46 INFO : [target] username@IP’s password:
• 09:45:46 INFO :
• 09:45:46 INFO : Target Deb package [{nvidia-l4t-jetson-multimedia-api 32.4.2-20200408182620}] not installed; [deb_name]: nvidia-l4t-jetson-multimedia-api_32.4.2-20200408182620_arm64.deb
• 09:45:46 ERROR : command terminated with error
• 09:45:46 DEBUG : using adapter to query target component: NV_DEEPSTREAM_TARGET_POST_INSTALL_COMP version: 5.0 for bundle:
• 09:45:46 INFO : Using GenericInstaller to Query NV_DEEPSTREAM_TARGET_POST_INSTALL_COMP
• 09:45:46 INFO : change working directory to /tmp
• 09:45:46 INFO : exec_command: ssh -F /dev/null -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no username@IP “dpkg-query -W -f=‘${db:Status-abbrev} ${Version}’ deepstream-5.0”
• 09:45:46 INFO : [target] username@IP’s password:
• 09:45:47 INFO :
• 09:45:47 INFO : Target Deb package [{deepstream-5.0 5.0.0-1}] not installed; [deb_name]: deepstream-5.0_5.0.0-1_arm64.deb
• 09:45:47 ERROR : command terminated with error
.
.
.
.
09:48:37 INFO : CUDA Toolkit for L4T : E: Failed to fetch https://repo.download.nvidia.cn/jetson/t186/dists/r32.4/main/binary-arm64/Packages.gz File has unexpected size (8232 != 8483). Mirror sync in progress? [IP: 202.194.101.19 443]
• 09:48:37 INFO : CUDA Toolkit for L4T : Hashes of expected file:
• 09:48:37 INFO : CUDA Toolkit for L4T : - Filesize:8483 [weak]
• 09:48:37 INFO : CUDA Toolkit for L4T : - SHA256:66c32a51878f7522a72b8e3726e90d4b4cee25b86da375029442a023eafc092e
• 09:48:37 INFO : CUDA Toolkit for L4T : - SHA1:8bf3c5113a60564b12d0883c2156e6ac0fe12afc [weak]
• 09:48:37 INFO : CUDA Toolkit for L4T : - MD5Sum:f2388ca95064a024fe4a298a2d71a745 [weak]
• 09:48:37 INFO : CUDA Toolkit for L4T : Release file created at: Tue, 16 Jun 2020 10:02:50 +0000
• 09:48:37 INFO : CUDA Toolkit for L4T : E: Some index files failed to download. They have been ignored, or old ones used instead.
• 09:48:37 INFO : CUDA Toolkit for L4T : Unhandled error when running sudo apt-get -y update
• 09:48:37 ERROR : CUDA Toolkit for L4T : [exec_command]: /bin/bash -c scp -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no /tmp/tmp_NV_L4T_CUDA_TARGET_POST_INSTALL_COMP.sh username@IP:~; ssh -t -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no username@IP “~/tmp_NV_L4T_CUDA_TARGET_POST_INSTALL_COMP.sh && rm -f ~/tmp_NV_L4T_CUDA_TARGET_POST_INSTALL_COMP.sh”; [error]: exit status 1
• 09:48:37 INFO : CUDA Toolkit for L4T : [ Package Install Finished with Error ]
• 09:48:37 INFO : CUDA Toolkit for L4T : [ 348.00 KB used. Disk Avail: 34.34 GB ]
• 09:48:37 INFO : CUDA Toolkit for L4T : [ NV_L4T_CUDA_TARGET_POST_INSTALL_COMP Install took 2m48s ]
• 09:48:37 ERROR : CUDA Toolkit for L4T : [error]: dpkg install on target failed; [exec_command]: safe_apt_install “sudo dpkg -i /opt/nvidia/deb_repos/cuda-repo-l4t-10-2-local-10.2.89_1.0-1_arm64.deb” 5; sleep 5; ; safe_apt_install "sudo apt-get -y install cuda-toolkit-10-2 " 5; sudo apt-get purge -y cuda-repo-l4t-10-2-local-10.2.89; [deb_path]: /home/asd/Downloads/nvidia/sdkm_downloads/cuda-repo-l4t-10-2-local-10.2.89_1.0-1_arm64.deb
• 09:48:37 INFO : CUDA Toolkit for L4T :
• 09:48:37 ERROR : CUDA Toolkit for L4T : command terminated with error
• 09:48:37 ERROR : CUDA Toolkit for L4T : Install ‘CUDA Toolkit for L4T’ failure, command < using adapter to install NV_L4T_CUDA_TARGET_POST_INSTALL_COMP@JETSON_TX2 to /home/asd/nvidia/nvidia_sdk/JetPack_4.4_DP_Linux_DP_JETSON_TX2 > terminated with error.
• 09:48:37 ERROR : Unavailable components detected, please check log
• 09:48:37 ERROR : cuDNN on Target : cuDNN on Target Skipped. Due to its dependencies fail to install: CUDA Toolkit for L4T,
• 09:48:37 ERROR : TensorRT on Target : TensorRT on Target Skipped. Due to its dependencies fail to install: CUDA Toolkit for L4T,
• 09:48:37 ERROR : OpenCV on Target : OpenCV on Target Skipped. Due to its dependencies fail to install: CUDA Toolkit for L4T,
• 09:48:37 ERROR : VisionWorks on Target : VisionWorks on Target Skipped. Due to its dependencies fail to install: CUDA Toolkit for L4T,
• 09:48:37 ERROR : VPI on Target : VPI on Target Skipped. Due to its dependencies fail to install: CUDA Toolkit for L4T,
• 09:48:37 ERROR : NVIDIA Container Runtime with Docker integration (Beta) : NVIDIA Container Runtime with Docker integration (Beta) Skipped. Due to its dependencies fail to install: CUDA Toolkit for L4T,
• 09:48:37 ERROR : Multimedia API : Multimedia API Skipped. Due to its dependencies fail to install: CUDA Toolkit for L4T,
• 09:48:37 ERROR : DeepStream : DeepStream Skipped. Due to its dependencies fail to install: CUDA Toolkit for L4T，
It is useful to know that flash never adds those optional components, and that flash was successful. The components are added only after the Jetson reboots and is fully operating. Furthermore, the additions are over ssh, and so you have to have completed the one time first boot setup of an account, and provided the name/pass of that account prior to JetPack/SDKM proceeding with optional components.
In addition to the account being added before proceeding on to extra component install there needs to be ethernet access. This can be done in a number of ways, but the default is that the micro-B USB provides a virtual wired ethernet to the host PC. In that case the IP address of the Jetson is 192.168.55.1, and this is what you would direct the host PC to use (along with that earlier user name/pass). The host PC will have an address of 192.168.55.100 (useful for debugging). Optionally, ethernet could be provided by your router to the wired ethernet connector. If that is the case, then you must tell SDKM that address (plus login name/pass).
What sometimes gets in the way is the host PC’s security. You may have to allow it to use that virtual wired ethernet.
You do not have to flash again to install those components. You can simply uncheck flash and just tell it to install components. I recommend against having it install samples until all else is in place because the samples are cross compiled on the host PC, and this in turn requires adding those tools to the PC. Just make sure all the other content you want is in place, and then go back and install the samples if you want them.
Check this:
For debugging, log in to the Jetson. Run “ifconfig”. Do you see address “192.168.55.1” on one of them? You should.
If that cable is connected to the PC, run “ifconfig” on that. Do you see address “192.168.55.100”? You should.
Or, has eth0 been assigned an address from your router? If so, write that down for when you tell the host PC the address.
Whichever IP address is visible, if you are on the host PC, can you “ping” that address? Example, from host PC, “ping 192.168.55.1”.
If you can ping, can you log in to your account from the host PC to that address with your new user name and pass? Example, if your account name is “nvidia”: “ssh nvidia@192.168.55.1”.
If you can ssh to the Jetson from the host PC, then SDKM can succeed. If not, then extra components cannot be added until networking is corrected. Ubuntu may just need you to accept the MAC address of the virtual ethernet over USB. To see the MAC address, on the PC, monitor “dmesg --follow”. Plug in the micro-B USB, and some information should show up. The MAC address is in that. The normal network setup control style app of Ubuntu should allow you to tell it to use that MAC address, and after doing so, ping and ssh should work.
I followed all your instructions. All was going quite well, but failed again.My operations are shown in time order as follows.
[1] I had completed the one time first boot setup of an account last time I contacted you. This time I boot the TX2 with all external peripheral devices connected except the micro-A to B USB cable. I input the pass and log into the OS. I think the Jetson is fully operating. Is this what you mean ‘fully operating’?
[2] I shut down the TX2 and disconnected the power supply. Then connect TX2 with the host PC with micro-A to B USB cable. Connect power supply, boot TX2 and run “ifconfig" in Jetson. The address ‘‘192.168.55.1’’ do exist. Run “ifconfig" in PC and ‘‘192.168.55.100’’ do exist. I “ping 192.168.55.1 ” on PC and it shows two devices are connected. After ping, I check ’ssh zsj@192.168.55.1 on the host PC. It shows
zsj@zsj-virtual-machine:~$ ssh zsj@192.168.55.1
zsj@192.168.55.1's password:
Welcome to Ubuntu 18.04.4 LTS (GNU/Linux 4.9.140-tegra aarch64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
This system has been minimized by removing packages and content that are not required on a system that users do not log into.
To restore this content, you can run the 'unminimize' command.
140 packages can be updated.
140 updates are security updates.
Last login: Sun Jun 21 22:56:42 2020 from 192.168.55.100
[3]I log out. Then I unchecked flash and only select the target components in SDKM (without TX2 in a recovery mode). Input the username and pass. The installation failed with the prompt.
The intercepted errors in terminal.
23:41:20 INFO : hello
23:41:20 INFO : command finished successfully
23:41:20 INFO : Validated its username and password.
23:41:20 DEBUG : using adapter to query target component: NV_L4T_CUDA_TARGET_POST_INSTALL_COMP version: 10.2 for bundle:
23:41:20 INFO : Using GenericInstaller to Query NV_L4T_CUDA_TARGET_POST_INSTALL_COMP
23:41:20 INFO : change working directory to /tmp
23:41:20 INFO : exec_command: ssh -F /dev/null -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no zsj@192.168.55.1
“dpkg-query -W -f=‘${db:Status-abbrev} ${Version}’ cuda-toolkit-10-2”
23:41:20 INFO : [target] zsj@192.168.55.1’s password:
23:41:20 INFO :
23:41:20 INFO : Target Deb package [{cuda-toolkit-10-2 10.2}] not installed; [deb_name]: cuda-repo-l4t-10-2-local-10.2.89_1.0-1_arm64.deb
23:41:20 ERROR : command terminated with error
23:41:20 DEBUG : using adapter to query target component: NV_L4T_CUDNN_TARGET_POST_INSTALL_COMP version: 8.0 for bundle:
23:41:20 INFO : Using GenericInstaller to Query NV_L4T_CUDNN_TARGET_POST_INSTALL_COMP
23:41:20 INFO : change working directory to /tmp
23:41:20 INFO : exec_command: ssh -F /dev/null -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no zsj@192.168.55.1 “dpkg-query -W -f=‘${db:Status-abbrev} ${Version}’ libcudnn8”
23:41:21 INFO : [target] zsj@192.168.55.1’s password:
23:41:21 INFO :
23:41:21 INFO : Target Deb package [{libcudnn8 8.0.0.145-1+cuda10.2}] not installed; [deb_name]: libcudnn8_8.0.0.145-1+cuda10.2_arm64.deb
…
… SEVERAL SIMILAR ERRORS OCCURED
…
…
23:42:37 INFO : CUDA Toolkit for L4T : E: Failed to fetch http://cn.archive.ubuntu.com/ubuntu/dists/bionic/main/binary-arm64/Packages 404 Not Found [IP: 91.189.91.38 80]
23:42:37 INFO : CUDA Toolkit for L4T : E: Some index files failed to download. They have been ignored, or old ones used instead.
23:42:37 INFO : CUDA Toolkit for L4T : Unhandled error when running sudo apt-get -y update
23:42:37 ERROR : CUDA Toolkit for L4T : [exec_command]: /bin/bash -c scp -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no /tmp/tmp_NV_L4T_CUDA_TARGET_POST_INSTALL_COMP.sh zsj@192.168.55.1:~; ssh -t -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no zsj@192.168.55.1 “~/tmp_NV_L4T_CUDA_TARGET_POST_INSTALL_COMP.sh && rm -f ~/tmp_NV_L4T_CUDA_TARGET_POST_INSTALL_COMP.sh”; [error]: exit status 1
23:42:37 INFO : CUDA Toolkit for L4T : [ Package Install Finished with Error ]
23:42:37 INFO : CUDA Toolkit for L4T : [ 120.00 KB used. Disk Avail: 34.30 GB ]
23:42:37 INFO : CUDA Toolkit for L4T : [ NV_L4T_CUDA_TARGET_POST_INSTALL_COMP Install took 1m9s ]
23:42:37 ERROR : CUDA Toolkit for L4T : [error]: dpkg install on target failed; [exec_command]: safe_apt_install “sudo dpkg -i /opt/nvidia/deb_repos/cuda-repo-l4t-10-2-local-10.2.89_1.0-1_arm64.deb” 5; sleep 5; ; safe_apt_install "sudo apt-get -y install cuda-toolkit-10-2 " 5; sudo apt-get purge -y cuda-repo-l4t-10-2-local-10.2.89; [deb_path]: /home/zsj/Downloads/nvidia/sdkm_downloads/cuda-repo-l4t-10-2-local-10.2.89_1.0-1_arm64.deb
23:42:37 INFO : CUDA Toolkit for L4T :
23:42:37 ERROR : CUDA Toolkit for L4T : command terminated with error
23:42:37 ERROR : CUDA Toolkit for L4T : Install ‘CUDA Toolkit for L4T’ failure, command < using adapter to install NV_L4T_CUDA_TARGET_POST_INSTALL_COMP@JETSON_TX2 to /home/zsj/nvidia/nvidia_sdk/JetPack_4.4_DP_Linux_DP_JETSON_TX2 > terminated with error.
23:42:37 ERROR : Unavailable components detected, please check log
23:42:37 ERROR : cuDNN on Target : cuDNN on Target Skipped. Due to its dependencies fail to install: CUDA Toolkit for L4T,
23:42:37 ERROR : TensorRT on Target : TensorRT on Target Skipped. Due to its dependencies fail to install: CUDA Toolkit for L4T,
23:42:37 ERROR : OpenCV on Target : OpenCV on Target Skipped. Due to its dependencies fail to install: CUDA Toolkit for L4T,
23:42:37 ERROR : VisionWorks on Target : VisionWorks on Target Skipped. Due to its dependencies fail to install: CUDA Toolkit for L4T,
23:42:37 ERROR : VPI on Target : VPI on Target Skipped. Due to its dependencies fail to install: CUDA Toolkit for L4T,
23:42:37 ERROR : NVIDIA Container Runtime with Docker integration (Beta) : NVIDIA Container Runtime with Docker integration (Beta) Skipped. Due to its dependencies fail to install: CUDA Toolkit for L4T,
23:42:37 ERROR : Multimedia API : Multimedia API Skipped. Due to its dependencies fail to install: CUDA Toolkit for L4T,
23:42:37 ERROR : DeepStream : DeepStream Skipped. Due to its dependencies fail to install: CUDA Toolkit for L4T,
In [2] you should not shut down the Jetson. USB is hot plug, and we want to know the system is fully functional at the moment we have the micro-B USB cable connected from Jetson to host PC. If the system once again fully booted though, then you can ignore what I just said. If you are worried about something shorting out while connecting cables I understand, but the USB side is quite happy to attach/detach either while running or while powered off…it won’t care.
The existence of those IP addresses says that the USB virtual wired ethernet is functioning correctly. Do beware that I see a VM, and a VM can have extra reasons to fail (such as not only requiring the host o/s to pass through networking and USB, both host o/s and guest o/s must not interfere with security settings…I don’t know if this is the case, but I am just mentioning it…life with a native Ubuntu install is generally simpler).
The ability to ssh in to 192.168.55.1 implies all should be ready.
I’m not sure about the “local” apt settings issue. This might depend on whether there was software being installed to the VM or to the Jetson since JetPack/SDKM can do both. Possibly the Jetson was working perfectly well and the message is for host side, e.g., there may be apt operations which would fail on the host PC (and host PC does need internet access for file downloads).
The arm64 “.deb” file is definitely one failing on the Jetson side. The CUDA toolkit is rather basic as a requirement for most of what runs, and so without this I suspect a number of packages will fail install. If CUDA failed, then I would expect most installs following this to fail. What we don’t know is if the failure was due to the host PC not downloading this content, or if it was due to an install issue at the Jetson side despite having the full download content.
Do both your host PC and the Jetson have outside internet access during this? Can the host PC “ping nvidia.com”? Can the Jetson “ping nvidia.com”?
I reinstall from the first step, somehow, the installation is finished successfully!!! Thank you for providing me with so much help！Much appreciation for your patient guidance!!!
I successfully flash TX2 last time with random. I think if I do grasp how to flash the target device, it’s reasonable to finish the whole flashing multiple times. I do more attempts and find out the failure is directly related to the target OS version. Every time I install Jetpack 4.4DP, the same failures always come up. While, if I choose Jetpack 4.3, I can finish the whole flash following the prompt instructions shown on the interface without effort.
If only 4.4DP fails, and other JetPack4.x works, then there might be a failure NVIDIA needs to look at. Possibly something as simple as a stale server cache could cause this (which would be a temporary failure since different places in the world use different servers). You would need to carefully log your steps and results while keeping in mind what you see above (and you would need to do so without a VM) to have the JetPack4.4 failure debugged.
The nature of how the Jetson disconnects and reconnects during a flash can change with release, and the VM rarely “just works”. You already know that other releases of JetPack4.x work for you, and so anyone looking at this will be suspicious of the VM.
You should file a new topic on this, along with the version of JetPack/SDKM, and logs of the failure message. There are cases where not having both python2 and python3 causes issues, and you have both, but we have no context of what occurred to say whether or not python matters.
