Thank you so much. It worked (My solution is a little different than yours though, but the principle is the same). I just restarted my computer, plugged everything in again, started the board and the connections were detected automatically by Ubuntu’s network manager.
Hi Edward, yes tried that … same message that you highlighted with that command
Something is not correct with the automated setup process used by the sdk manager on ubuntu 18.0.4 … suspect its something to do with how the nvidia usb address is binding. However its beyond my knowledge.
Have seen a few people with the same issue. Then people leave comments saying it worked under ubuntu 16.04. I’ve upgraded and cant run the flash process in a VM.
So we need a better answer from Nvidia on how to flash using the new tools on Ubuntu 18.0.4 lts
If flashing also fails manually, this is not an sdk manager issue. Is your Ubuntu 18.04 installed in VM? It is known that flashing is not supported in VM.
If you are not using VM, however, it might be hardware issue. Please check if it is an issue of USB cable, usb port, or the Jetson TX2 device.
hi Edward … cables fine. Its bare metal. Ubuntu boots up ok on the Jetson TX2 device and the usb mounted LT4 drive is there when not in recovery mode. I’m getting the same errors as a few of the other posts here. Something is not right with the sdk manager scripts. Its not configuring the Ubuntu 18.04.2 lts host properly and/or there is something else we might need to run as a prerequisite before running the sdk manager. Spent so much time on this. Is Ubuntu 18.04.2 lts supported as a host by Nvidia for flashing a Jetson tx2???
@tewei.luo read them but they are for Ubuntu 16.04 and not 18.04 with netplan … keep seeing bind and unbind messages in the syslog for the usb device
In case it helps anyone, on one ubuntu 18.04 host installing jetpack4.2 on TX2s, it had a problem that I ultimately traced down to not having python installed on the host (python3 was installed but not python). The symptom was that the flash would just not succeed and an error in the terminal window said /usr/bin/env python failed.
@edward still have this issue … how are we to configure our Ubuntu 18.04.02 LTS hosts to flash Jetpack 4.2 onto a tx2 that has Jetpack 3.n installed?
Edward will update about the question regarding installing JP 4.2 when JP 3.x is installed (But I would think Jp 4.2 should just install whatever components its installing on top of your existing install).
You mentioned earlier about manual flashing also fails - If manual flash on TX2 fails - can you confirm via lsusb if you see “NVIDIA” and the last four numbers needs to be 7c18 for TX2. (Only this indicates that the board is in recovery mode and is ready for flashing).
Also how are you setting it to this recovery mode?
yes its in recovery mode
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 007: ID 0955:7c18 NVidia Corp. Bus 001 Device 005: ID 0951:16a4 Kingston Technology Bus 001 Device 003: ID 28de:1142 Bus 001 Device 006: ID 046d:c248 Logitech, Inc. G105 Gaming Keyboard Bus 001 Device 004: ID 22d4:1306 Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
JetPack 4.2 just flashes TX2, then installs everything after flashing. It doesn’t matter whether your TX2 was flashed with JetPack 3.x or any other version.
@edward that’s great but how do we ensure we have our Ubuntu 18.04.02 lts hosts configured to be able to do that???
Something is wrong with the Nvidia flash scripts… I’m not the only person who has had this issue… they respond to your questions and are not making progress with actually installing jet pack 4.2 on their tx2s
Sorry for he comment but can you please escalate internally at Nvidia so we can get some resolution. Thanks Nick
Sorry for the inconvenience. Yes, we are discussing internally about this issue. pkuttiyam is following up with you for the flashing issue you met.
Sitting here with a useless TX2. Flashed just fine with SDK Manager installed via the cable connected to a NUC running Ubuntu 18.04. Finish setup on the TX2 (configure locale, time zone, u/p, etc). Then try and install SDK and it can’t connect.
lsusb doesn’t show it either. Guessing this is the inability to configure USB networking issue (I’m not seeing any devices with 192.168.55.x).
I moved over to a TX2 from a NUC because I thought it would be easier than having to manage all this stuff. Guess not. :(
SDK Manager target components installation replies on jetson usb-device mode. If jetson usb-device mode is not supported on a NUC, target components installation will fail with NUC. When the jetson device is connected to host with USB cable and boots up, on host you will see an auto mounted “L4T-README” folder. You could follow the help documents in this folder to manually check if jetson usb-device mode can work with NUC or not.
So usb-device mode is not the same thing used during a flash then, only the SDK? Because I can flash all day every day consistently 100% of the time when I boot into recovery mode. It’s after the OS flash via SDK manager and when it goes to install the SDK components. I am doing this after completing the OS install on the TX2 and setting a username password.
Also strange in that I got this to work once a few days ago after randomly booting both devices and using a different cable (have tried that method again to no avail) but was having issues with some of my projects so decided to completely rebuild my tx2.
Now stuck here. :(
Does the L4T-README show in Recovery mode? Could you just post those documents here?
Nick - to isolate the issue, can you try to flash without SDK Manager in the picture?
Can you try:
a. put device in recovery mode, b. confirm via lsusb, c. then use sudo ./flash.sh jetson-tx2 mmcblk0p1
And please post logs from all of the above if you run into any error.
Edward will work with you regarding the error you are facing with SDK Manager (about the host interface needing to be in the 192.168.55. network as mentioned in #18 or #21)
@pkuttiyam confirmed via lsusb in recovery mode before running
sudo ./flash.sh jetson-tx2 mmcblk0p1 [sudo] password for nick: ############################################################################### # L4T BSP Information: # R32 (release), REVISION: 1.0, GCID: 14531094, BOARD: t186ref, EABI: aarch64, # DATE: Wed Mar 13 07:41:08 UTC 2019 ############################################################################### Error: probing the target board failed. Make sure the target board is connected through USB port and is in recovery mode.
pr 9 14:57:14 jam kernel: [ 277.337137] usb 1-7: new high-speed USB device number 12 using xhci_hcd Apr 9 14:57:14 jam kernel: [ 277.506115] usb 1-7: New USB device found, idVendor=0955, idProduct=7c18 Apr 9 14:57:14 jam kernel: [ 277.506119] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Apr 9 14:57:14 jam kernel: [ 277.506121] usb 1-7: Product: APX Apr 9 14:57:14 jam kernel: [ 277.506122] usb 1-7: Manufacturer: NVIDIA Corp. Apr 9 14:57:14 jam mtp-probe: checking bus 1, device 12: "/sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-7" Apr 9 14:57:14 jam mtp-probe: bus: 1, device: 12 was not an MTP device Apr 9 14:57:15 jam upowerd: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-7 Apr 9 14:59:59 jam gnome-shell: Some code accessed the property 'discreteGpuAvailable' on the module 'appDisplay'. That property was defined with 'let' or 'const' inside the module. This was previously supported, but is not correct according to the ES6 standard. Any symbols to be exported from a module must be defined with 'var'. The property access will work as previously for the time being, but please fix your code anyway. Apr 9 14:59:59 jam gnome-shell: Some code accessed the property 'WindowPreviewMenuItem' on the module 'windowPreview'. That property was defined with 'let' or 'const' inside the module. This was previously supported, but is not correct according to the ES6 standard. Any symbols to be exported from a module must be defined with 'var'. The property access will work as previously for the time being, but please fix your code anyway. Apr 9 15:00:25 jam systemd: Started Run anacron jobs. Apr 9 15:00:25 jam anacron: Anacron 2.3 started on 2019-04-09 Apr 9 15:00:25 jam anacron: Normal exit (0 jobs run) Apr 9 15:00:44 jam gnome-shell: cogl-sampler-cache.c:200: GL error (1280): Invalid enumeration value Apr 9 15:00:44 jam gnome-shell: message repeated 5 times: [ cogl-sampler-cache.c:200: GL error (1280): Invalid enumeration value] Apr 9 15:02:05 jam upowerd: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-7/1-7:1.0 Apr 9 15:02:05 jam upowerd: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-7/1-7:1.0 Apr 9 15:02:05 jam upowerd: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-7/1-7:1.0 Apr 9 15:02:10 jam upowerd: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-7/1-7:1.0
I had the same problem which you are going through. I was able to flash the Jetson board but the sdk components failed with the message “jetson is in recovery mode”.
This failure is due to the USB ethernet connection between the Host PC and Jetson board. Kindly follow these steps and your issue might be resolved.
- 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
Next go to Settings->Network and check all the wired connections for the same MAC-address.
In the top right corner there will be an option to enable it.
Next follow the procedure as provided by the SDK manager to install the SDK components