JetPack 4.2 Flashing Issues and how to resolve

There are known flashing issues with the Jetson TX2 platforms that NVIDIA is actively working to resolve. To provide transparency, and further support our customers, several of these issues, and where possible workarounds toward resolution, please refer to below:

Log Issues
Q1: How to export SDK Manager logs?
A: SDK Manager logs can be exported with below steps:
1. Launch SDK Manager.
2. Click on the 3 dots in the top right corner (“⋮”) and select Export Debug Logs.
3. A zip file of the logs is saved into ~/Downloads/nvidia/sdkm_downloads directory automatically.

Flash Issues
Q1: I cannot flash Jetson device with SDK Manager. What to do next?
A: Please make sure there is no environment issue. We can confirm this by manually flashing Jetson.
1. Manually reset board to clear board status.
2. Put Jetson device to recovery mode.
3. Go to JetPack install directory. For example, ~/nvidia/nvidia_sdk/JetPack_4.2_Linux_P3489/. The actual path may vary depending on the selected installation directory and selected board type.
4. cd Linux_for_Tegra
5. Run one of the below command to flash Jetson device:
- sudo ./ jetson-tx2 mmcblk0p1 // For Jetson TX2
- sudo ./ jetson-tx2i mmcblk0p1 // For Jetson TX2i
- sudo ./ jetson-xavier mmcblk0p1 // For Jetson Xavier
- sudo ./ jetson-nano-qspi-sd mmcblk0p1 // For Jetson Nano
6. Paste full log of step 5 if flashing fails.

Q2: Why manually flashing doesn’t work, although lsusb shows device is already in recovery mode?
A: lsusb alone is not sufficient. Need put device to recovery mode again. Specifically, lsusb simply shows that the Jetson device is attached to your PC and in recovery mode. However, there is a one-off setup communication that occurs between the PC and Jetson each time flashing is attempted, and once this has happened, any flash attempt will fail unless Jetson is forced back into recovery mode, even if it already appears to be in recovery mode. See comments from Stephen

Jetson SDK (target) installation issues
Q1. I cannot connect to Jetson device after flashing. I’ve created new user, and jetson device has boot up. Ubuntu desktop is shown on HDMI output. USB cable is connected between host and Jetson device. What to do next?
A: SDK Manager relies on usb-device mode to set up network connection between host and target. Please see Jetson usb-device mode issues section in this FAQ for more details.

Jetson usb-device mode issues
Q1: How to verify if usb-device mode is working?
A: After flashing and Jetson device booting up, usb-device mode is up . The expected results at this stage are

  • is assigned to Jetson device, and
  • is assigned to host machine.

Please see details

Q2: usb-device mode is already up and running, however, not assigned on host. Why?
A: One possible reason is that usb-ethernet network interface is disabled on host machine? To enable it,

  1. Disconnect and Connect the USB cable connecting the jetson and Host-PC, and check the dmesg log.
    You might see a log similar to this:
    [107833.388835] cdc_ether 2-2:1.5 usb1: register ‘cdc_ether’ at usb-0000:00:14.0-2, CDC Ethernet Device, 72:40:f7:72:c9:fa
  2. Next go to Settings->Network and check all the wired connections for the same MAC-address.
  3. In the top right corner there will be an option to enable it.
  4. Next follow the procedure as provided by the SDK manager to install the SDK components

Please see details

Q3: How to check if there is any error during starting jetson usb-device mode?
A: Use below steps:

  1. Run “dmesg” on the host and provide the full output. This might show any errors the host might have had when enumerating the Jetson USB device.
    Now, connect jetson device with a ethernet cable, get its IP address, ssh to Jetson and:
  2. Run “journalctl -u nv-l4t-usb-device-mode” to show any errors configuring the USB device mode service on Jetson, during boot.
  3. As root, run “/opt/nvidia/l4t-usb-device-mode/”. This is expected to show some errors; ignore them.
  4. As root, run “bash -x /opt/nvidia/l4t-usb-device-mode/” and provide the entire output that prints. This should
    (a) show the same errors as in (2) above, and/or
    (b) actually make L4T USB device mode work, if the reason it failed the first time was due to some missing dependency that wasn’t available right when the script ran at boot.

Please see example:

1 Like

Hi everybody.
I just finished configuring a TX2 with JetPack4.2 with Ubuntu 18.04LTS on host machine and i want to share my experience.
First, i have an error during flashing the TX2 at about 14.3%. Reported error was “lost connection”. It is due to an uninstalled Python 2.7 on host as it is said in the following topic:
After I have an other error when upload SDK components: SDK manager can’t reach the TX2 via micro usb port. This is due to the fact that i use an Auvidea J130 carrier board. The usb port doesn’t appear at all on the host machine. I switched to NVIDIA carrier board and i have a new error : the famous “USB port is in recovery mode.” although the board is boot on ubuntu. The work around can be found in this post:


I need to configure ip add manually for this usb-eth link to Its logical name was: enp0s20u10i5.
At this step, SDK manager start CUDA downloading to the TX2 board. I was happy only for a short time… after about 20% it stops on a new error. In the log informations of the Terminal tab of sdk manager, i saw that TX2 try to execute apt install dependency (although SDk manager claims “download complete successfully” in the bottom of its window. Don’t belive it ! It’s a lie. TX2 trys to download packages from internet. So I configure a valide internet connection on the TX2 and the install process finally reached its end ! YESSSS

I hope that this few lines will help you

1 Like

Hi all.

i have same issue after flash OS, i get into the situation that Jetson xavier in recovery mode. my reason cause that problem is usb-Ethernet port is not created automatically by my ubuntu host, and i figure out by using an windown VM ubuntu host. just share my solution:

  1. flash os by your host(pc1) with target in recovery mode, this step you will has no problem with usb-ethernet port.
  2. use your VM(pc2) to flash the cuda and other ai tools, make sure this host machine has usb-ethernet port created automatically when you plug in your target usb port.
  3. make sure your target connect to network, otherwise it will fail during the cuda flash.

hope this could solve your jetson recovery issue. if both your pc has usb port issue, you probably need to find a working one.

have fun!

I have tried the following:

sudo ./ jetson-tx2 mmcblk0p1

L4T BSP Information:

R32 (release), REVISION: 1.0, GCID: 14531094, BOARD: t186ref, EABI: aarch64,

DATE: Wed Mar 13 07:41:08 UTC 2019


Target Board Information:

Name: jetson-tx2, Board Family: t186ref, SoC: Tegra 186,

OpMode: production, Boot Authentication: NS,

./ --chip 0x18 --applet “/home/baz/nvidia/nvidia_sdk/JetPack_4.2_Linux_P3310/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin” --skipuid --cmd “dump eeprom boardinfo cvm.bin”
/usr/bin/env: ‘python’: No such file or directory
Reading board information failed.

And it does not work?

Python 2 is required, and not tested for. Python 3 is present by default, so you have to install version 2.

1 Like


I have managed to flash the TX2 ok but failed to install the SDK. I have the host with and TX2 with the, I can ping each other all ok. I can see the L4T-README folder on the host. Except Install SDK components on your Jetson TX2 fails with the error Baz@ Permission denied (publickey.password).

I have made sure the user name and password are all correct. But keep getting this error.

Please can you advice



Following logs I have:

07:11:11 DEBUG : running command < ip addr | grep >
07:11:12 INFO : inet e[01;31me[K192.168.55.100/24e[me[K brd scope global dynamic noprefixroute ens35u1
07:11:12 INFO : command finished successfully
07:11:12 DEBUG : running command < ssh -F /dev/null -o PubkeyAuthentication=no -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ConnectTimeout=5 Baz@ echo hello >
07:11:12 INFO : Warning: Permanently added ‘’ (ECDSA) to the list of known hosts.
07:11:12 INFO : [target] Baz@’s password:
07:11:12 INFO :
07:11:14 INFO : Permission denied, please try again.
07:11:14 INFO : [target] Baz@’s password:
07:11:14 INFO :
07:11:16 INFO : Permission denied, please try again.
07:11:16 INFO : [target] Baz@’s password:
07:11:16 INFO :
07:11:18 INFO : Baz@ Permission denied (publickey,password).
07:11:18 ERROR : command terminated with error
07:11:18 ERROR : Incorrect username or password


I have managed to over come this issue looks I need to reboot the host PC and make sure VM Removal Device Nvidia is connected and rerun the SDK installation again and it worked all fine.

hi,i use linux18.04 to flash jetpack 4.2, follow #2,I really do flashed the OS ,but Jetson SDK (target) installation failed, it also failed in both linux 16.04 and 18.04 lots times.
I use carry board j120, is this the problem? by the way, my host both tried PC and laptop, all failed. I really have no idea how should I do. it gone 1 month since I decided to flash jetpack 4.2.
all situation seems like others who failed too. The key is may is contact, can I install the cuda by manual ?
o ,I cannot see the L4T-README folder in the host ,but can see in tx2.
I guess because 18.04 do not have the USB network ,if this ,how can I add the USB network ,I Google a lot, have no result .

I’ve also been having problems installing Jetpack 4.2 on the TX2.

I had two major problems that I’ve finally been able to resolve:

  1. Flashing
  2. Post flash install of SDK components.

  1. Flashing

Required me to install python and xterm first.

sudo apt-get install python
sudo apt-get install xterm

Flashing worked after I figured out how to get the TX2 into recovery mode.

As stated elsewhere, use lsusb to check that there’s an NVIDIA device connect to the host before trying to flash. It only appeared for me when I put the TX2 into recovery mode.

  1. Post flash install of SDK components

Like many, many others on these forums, I could not get the usb-device ethernet stuff to work. It showed up on the TX2 as device l4tbr0 with IPV4 address

But plugging it into the host did nothing on the host. Many, many different cables didn’t fix the problem. I’ve still not gotten the usb-device mode to work.

The solution:

a. Use ethernet cable instead of usb cable. Plug TX2 into host computer.

b. Manually setup IPV4 address for ethernet port on both TX2 and host.


For both, use a netmask of
Gateway doesn’t matter. Leave it blank.

If you need to, you can google how to set up manual IP addresses for ethernet devices in Ubuntu.

c. This is not enough. You have to disable the usb-device mode stuff on the TX2 so that it doesn’t use the address and conflict with your ethernet device.

Follow the instructions at the bottom of the README-usb-dev-mode.txt file in the L4T-README drive that is mounted on the TX2 (for me this is automatically mounted in Ubuntu on the TX2).

sudo service nv-l4t-usb-device-mode stop
sudo systemctl disable nv-l4t-usb-device-mode.service

Restart the TX2 and go back into Ubuntu.

d. Test that you can ping from the host:


If this works, then you should be able to continue the Jetpack 4.2 installation of the SDK components on the TX2. If you’ve set up manual IP addresses and ping doesn’t work, you can try restarting the ethernet devices or the computers.

e. If you like, you can re-enable the usb-device mode as follows once the SDK components are installed:

sudo systemctl enable /opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode.service
sudo service nv-l4t-usb-device-mode start

when I use sdkmanager install to flash TX2,I miss the folllowing errors:
01:26:43 ERROR : CUDA Toolkit for L4T : Warning: Permanently added ‘’ (ECDSA) to the list of known hosts.
01:28:09 ERROR : CUDA Toolkit for L4T : NV_L4T_CUDA_TARGET_POST_INSTALL_COMP command scp -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no /tmp/ nvidia@; ssh -t -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no nvidia@ “~/ && rm -f ~/” finished with error
01:28:09 ERROR : CUDA Toolkit for L4T : command terminated with error
01:28:09 ERROR : CUDA Toolkit for L4T : install ‘CUDA Toolkit for L4T’ failure, command < cd ‘/home/zhy/nvidia/nvidia_sdk/JetPack_4.2_Linux_P3310’ ; /opt/nvidia/sdkmanager/resources/app/output/installUtils/adapter -a=‘install’ -c=‘eyJpZCI6Ik5WX0w0VF9DVURBX1RBUkdFVF9QT1NUX0lOU1RBTExfQ09NUCIsIm5hbWUiOiJDVURBIFRvb2xraXQgZm9yIEw0VCIsImRlc2NyaXB0aW9uIjoiQ1VEQSB0byBiZSBpbnN0YWxsZWQgb24gdGFyZ2V0LiBDVURBIGlzIGEgcGFyYWxsZWwgY29tcHV0aW5nIHBsYXRmb3JtIGFuZCBwcm9ncmFtbWluZyBtb2RlbCBpbnZlbnRlZCBieSBOVklESUEuIEl0IGVuYWJsZXMgZHJhbWF0aWMgaW5jcmVhc2VzIGluIGNvbXB1dGluZyBwZXJmb3JtYW5jZSBieSBoYXJuZXNzaW5nIHRoZSBwb3dlciBvZiB0aGUgZ3JhcGhpY3MgcHJvY2Vzc2luZyB1bml0IChHUFUpLiIsImNvbXBUeXBlIjoidGFyZ2V0IiwiaXNWaXNpYmxlIjp0cnVlLCJsaWNlbnNlSWQiOiJOVl9KRVRQQUNLX0NVREFfRVVMQSIsImlzRGV0ZWN0YWJsZUluc3RhbGwiOmZhbHNlLCJpc0luc3RhbGxQYXRoQ3VzdG9taXphYmxlIjp0cnVlLCJ2ZXJzaW9uIjoiMTAuMCIsIm9wZXJhdGluZ1N5c3RlbXMiOlsidWJ1bnR1MTYwNCIsInVidW50dTE4MDQiXSwiaW5zdGFsbFNpemVNQiI6MCwiZG93bmxvYWRGaWxlcyI6W3sidXJsIjoiL2N1ZGEtcmVwby1sNHQtMTAtMC1sb2NhbC0xMC4wLjE2Nl8xLjAtMV9hcm02NC5kZWIiLCJmaWxlTmFtZSI6ImN1ZGEtcmVwby1sNHQtMTAtMC1sb2NhbC0xMC4wLjE2Nl8xLjAtMV9hcm02NC5kZWIiLCJzaXplIjo4ODcyMTkzNDQsImNoZWNrc3VtIjoiNWUzZWVkYzM3MDczMDVmOTAyMmQ0MTc1NGQ2YmVjZGUiLCJjaGVja3N1bVR5cGUiOiJtZDUiLCJpbnN0YWxsUGFyYW1ldGVycyI6eyJpbnN0YWxsVHlwZSI6ImNtZCIsImFkZGl0aW9uYWxQYXJhbWV0ZXJzIjp7Imluc3RhbGxDb21tYW5kcyI6W3sicmVtb3RlRXhlY0Jhc2giOlsic3VkbyBta2RpciAtcCAvb3B0L252aWRpYS9kZWJfcmVwb3MiLCJzdWRvIGNobW9kIDc3NyAvb3B0L252aWRpYS9kZWJfcmVwb3MiLCJzdWRvIHJtIC1mIC9vcHQvbnZpZGlhL2RlYl9yZXBvcy97e0ZJTEVfTkFNRX19Il19LHsidXNlckNvbW1hbmQiOiJzY3AgLUYgL2Rldi9udWxsIC1vIFB1YmtleUF1dGhlbnRpY2F0aW9uPW5vIC1vIFVzZXJLbm93bkhvc3RzRmlsZT0vZGV2L251bGwgLW8gU3RyaWN0SG9zdEtleUNoZWNraW5nPW5vIC1vIENvbm5lY3RUaW1lb3V0PTUgLXIge3tGSUxFX1BBVEh9fSAge3tUQVJHRVRfVVNFUk5BTUV9fUAxOTIuMTY4LjU1LjE6L29wdC9udmlkaWEvZGViX3JlcG9zLyJ9LHsicmVtb3RlRXhlY0Jhc2giOlsiZnVuY3Rpb24gc2FmZV9hcHRfaW5zdGFsbCB7IiwiICAgIGVjaG8gXCIqYmVnaW4gJDEsICQyXCIiLCIgICAgdG1wX2xvZz0vdG1wL2pldHBhY2tfZHBrZ19sb2cudHh0IiwiICAgIHN1ZG8gcm0gLWYgJHRtcF9sb2ciLCIgICAgc2V0ICtlOyAkMSAyPiYxIHwgdGVlICR0bXBfbG9nOyBDTURfU1RBVFVTPSR7UElQRVNUQVRVU1swXX07IHNldCAtZSIsIiAgICB3aGlsZSBbICR7Q01EX1NUQVRVU30gLW5lIDAgXTsgZG8iLCIgICAgICAgIGlmIGdyZXAgLXEgLWUgXCJpcyBsb2NrZWQgYnkgYW5vdGhlciBwcm9jZXNzXCIgLWUgXCJFOiBDb3VsZCBub3QgZ2V0IGxvY2sgL3Zhci9saWJcIiAkdG1wX2xvZzsgdGhlbiIsIiAgICAgICAgICAgc3VkbyBybSAtZiAkdG1wX2xvZyIsIiAgICAgICAgICAgc2V0ICtlOyAkMSAyPiYxIHwgdGVlICR0bXBfbG9nOyBDTURfU1RBVFVTPSR7UElQRVNUQVRVU1swXX07IHNldCAtZSIsIiAgICAgICAgICAgZWNobyBcIldhaXRpbmcgJDIgc2Vjb25kcyBmb3IgYXB0IHRvIGJlIGF2YWlsYWJsZVwiOyBzbGVlcCAkezJ9IiwiICAgICAgICBlbHNlIiwiICAgICAgICAgICBlY2hvIFwiVW5oYW5kbGVkIGVycm9yIHdoZW4gcnVubmluZyAkMVwiOyBleGl0IDEiLCIgICAgICAgIGZpIiwiICAgIGRvbmUiLCJ9Iiwic2FmZV9hcHRfaW5zdGFsbCBcInN1ZG8gZHBrZyAtaSAvb3B0L252aWRpYS9kZWJfcmVwb3Mve3tGSUxFX05BTUV9fVwiIDUiLCJzbGVlcCA1Iiwic2FmZV9hcHRfaW5zdGFsbCBcInN1ZG8gYXB0LWtleSBhZGQgL3Zhci9jdWRhLXJlcG8tKi1sb2NhbCovKi5wdWJcIiA1Iiwic2xlZXAgMiIsInNhZmVfYXB0X2luc3RhbGwgXCJzdWRvIGFwdC1nZXQgLXkgdXBkYXRlXCIgNSIsInNhZmVfYXB0X2luc3RhbGwgXCJzdWRvIGFwdC1nZXQgaW5zdGFsbCAteSBnbnVwZ1wiIDUiLCJzYWZlX2FwdF9pbnN0YWxsIFwic3VkbyBhcHQtZ2V0IC15IC0tYWxsb3ctZG93bmdyYWRlcyBpbnN0YWxsIGN1ZGEtdG9vbGtpdC0xMC0wIGxpYmdvbXAxIGxpYmZyZWVpbWFnZS1kZXYgbGlib3Blbm1waS1kZXYgb3Blbm1waS1iaW5cIiA1IiwiZ3JlcCAtcSAnZXhwb3J0IFBBVEg9LiovdXNyL2xvY2FsL2N1ZGEtMTAuMC9iaW4nIH4vLmJhc2hyYyB8fCBlY2hvICdleHBvcnQgUEFUSD0vdXNyL2xvY2FsL2N1ZGEtMTAuMC9iaW46JFBBVEgnPj5+Ly5iYXNocmMiLCJncmVwIC1xICdleHBvcnQgTERfTElCUkFSWV9QQVRIPS91c3IvbG9jYWwvY3VkYS0xMC4wL2xpYjY0JyB+Ly5iYXNocmMgfHwgZWNobyAnZXhwb3J0IExEX0xJQlJBUllfUEFUSD0vdXNyL2xvY2FsL2N1ZGEtMTAuMC9saWI2NDokTERfTElCUkFSWV9QQVRIJyA+PiB+Ly5iYXNocmMiLCJzdWRvIHJtIC1mIC9vcHQvbnZpZGlhL2RlYl9yZXBvcy97e0ZJTEVfTkFNRX19Il19XX19LCJjYWNoZWRVcmwiOiJodHRwczovL2RldmVsb3Blci5udmlkaWEuY29tL2Fzc2V0cy9lbWJlZGRlZC9zZWN1cmUvdG9vbHMvZmlsZXMvamV0cGFjay1zZGtzL2pldHBhY2stNC4yL0pFVFBBQ0tfNDJfYjE1OC9jdWRhLXJlcG8tbDR0LTEwLTAtbG9jYWwtMTAuMC4xNjZfMS4wLTFfYXJtNjQuZGViIn1dLCJ0YXJnZXRJZHMiOlsiUDMzMTAiLCJQMzQ4OS0wMDAwIiwiUDI4ODgiLCJQMzQ0OC0wMDAwIl0sImRlcGVuZGVuY2llcyI6W3siaWQiOiJOVl9MNFRfREFURVRJTUVfVEFSR0VUX1NFVFVQX0NPTVAiLCJvcGVyYXRvciI6Ij09IiwidmVyIjoiMS4wIn1dLCJleHRlcm5hbF9kZXBlbmRlbmNpZXMiOltdLCJwYXJlbnRJRCI6Ik5WX0NVREFfVEFSR0VUX0dST1VQIiwiYWN0aW9uIjoxLCJpbnN0YWxsUGF0aCI6Ii9ob21lL3poeS9udmlkaWEvbnZpZGlhX3Nkay9KZXRQYWNrXzQuMl9MaW51eF9QMzMxMCIsImRvd25sb2FkRXJyb3JzIjpbXSwidmVyaWZ5IjpmYWxzZSwiZXhlYyI6Ii9ob21lL3poeS9Eb3dubG9hZHMvbnZpZGlhL3Nka21fZG93bmxvYWRzL2N1ZGEtcmVwby1sNHQtMTAtMC1sb2NhbC0xMC4wLjE2Nl8xLjAtMV9hcm02NC5kZWIiLCJ0YXJnZXRBY2Nlc3NJbmZvIjp7InVzZXIiOiJudmlkaWEiLCJwYXNzd29yZCI6Im52aWRpYSIsImhvc3QiOiIxOTIuMTY4LjU1LjEiLCJwb3J0IjoiMjIifSwiYnVuZGxlVGl0bGUiOiJKZXRQYWNrXzQuMl9MaW51eCIsImluc3RhbGxSb290IjoiL2hvbWUvemh5L252aWRpYS9udmlkaWFfc2RrIiwiYm9hcmRJRCI6IlAzMzEwIn0=’ -i=‘NV_L4T_CUDA_TARGET_POST_INSTALL_COMP’ -v=‘10.0’ -l=‘/home/zhy/nvidia/nvidia_sdk/JetPack_4.2_Linux_P3310’ -L=‘/home/zhy/.nvsdkm/logs/JetPack_4.2_Linux’ -p=‘8258’ -t=‘P3310’ -e=‘/home/zhy/Downloads/nvidia/sdkm_downloads/cuda-repo-l4t-10-0-local-10.0.166_1.0-1_arm64.deb’ > terminated with error

successful install from sdkmanager with VirtualBox6 / Windows10 (surfacepro4)

take care to use a dock if your linux is image on an external disk…
when I shared the USB port with usb-ethernet and a disk the connection failed

the main last issue is that we can not boot headless …

hi ,
i m new to nvidia i have an ubuntu 18.04 version host system connected to a jetson tx2, i have totally installed the setup without error but unbale to find cuda and other development tools in both host and jetson tx2 since i searched for errors icame up with this blog “Install DRIVE with SDK Manager :: NVIDIA SDK Manager Documentation” Unable to find drive details in my sdk manager. kindly clarify me

Thanks & regards,
Sasikumar E

Flash itself does not install extra packages. The default checklist of what to do includes flashing and then install, but it is possible for flash to succeed and then have package install fail if the USB virtual networking is not set up correctly.

In the case where this succeeds there will be a CUDA directory within “/usr/local/”. Usually a versioned CUDA directory and then a symbolic link without version pointing at that versioned directory.

and then have package install fail if the USB virtual networking is not set up correctly

I’ve managed to flash my TX2 but i cannot get the USB networking to work with my host running 18.04

Is there any way that the SDK manager can be installed via any other means ?

i have installed the cuda in jetson tx2 but unable to view it using ls command

fldec@fldec-desktop:~$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2018 NVIDIA Corporation
Built on Sun_Sep_30_21:09:22_CDT_2018
Cuda compilation tools, release 10.0, V10.0.166

fldec@fldec-desktop:~$ ls
Desktop Downloads Pictures Videos
devel examples.desktop Public VisionWorks-SFM-0.90-Samples
Documents Music Templates

is i my setup installed correctly or do i have to change any

There are ways to use the SDK Manager downloads to manually install the repo “.deb” files, followed by the rest, but I wouldn’t recommend it if at all possible.

First, let’s be sure you are not using a VM, this causes all kinds of VM failures, and virtual USB to a VM gets to be even more of a problem.

The issue is basically that you have to tell your Ubuntu host to use the virtual NIC. Sometimes it is as simple as going to the GUI config tool for networks and enabling the virtual network adapter. Sometimes people have got to that stage and unplugged/replugged the USB, and then added the virtual adapter. Others have disabled other networking, and then used the config to add the USB virtual adapter.

FYI, much of what you will be interested in is in “/usr/local/” and won’t show up in your home directory. What do you see from “ls /usr/local”?

Its not a VM. Its a Dell Laptop. E6430.
On the Jetson i can see the usb network bridge adapter.
On the host i only have the ethernet network.
When i go to add a network in the gui on the host, i can only add a new interface using the same mac addy as the nic.
its like there are no drivers for a usb network inside the host 18.04 os…

Hi, hello. I installed the system automatically with Invida’s board. And I put my two tx2 in two sets of J120 motherboards, but something wrong happened. One j120 of fans kept running at the highest power, while the other j120 fans did not turn at all.
by the way, I can’t run the executable by double-clicking. I can only run it through the terminal. Such a mistake has never happened in 3.3.
I have sent an e-mail to the j120 official. They told me that the latest 4.2 system can be used directly without any driver files, except for the second USB port. So please don’t push duty to j120. After all, I have two sets of j120 which work normally and one is abnormal. But neither of them can run the executable directly by double-clicking.

by the way ,i did as the link says ,but show ''cannot access fan ‘’