@waiss which version of Ubuntu are you using? … not getting to the stage of being able to even flash. The Netplan comment I left earlier was my attempt to assign a configuration to the nvidia USB devices when they connect (normally ie not recovery mode)
Just FYI, flash itself occurs only over USB with the Jetson in recovery mode. Once this is complete (or if you install only packages and don’t flash), then the Jetson must boot to Linux. The two stages are completely independent. During package addition stages the Jetson cannot be in recovery mode, and communications is done over ethernet. One trick is that now the USB can appear to also be an ethernet device which the host can talk to in place of a real wired ethernet, but you must watch options closely during install. At this step the Jetson must be fully/normally booted.
The host might require enabling the USB ethernet device which will be visible after the Jetson boots if this is the configuration you are using.
Nick, are you still unable to flash Jetson manually? If so, the following may help:
For flashing to succeed, it is necessary for lsusb to show the Jetson device. However, lsusb alone is not sufficient. 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.
In practical terms, this means that every single time you are about to flash Jetson, either using SDK Manager or manually using L4T’s flash.sh, you must force Jetson to re-enter recovery mode by following one of these sets of steps:
-
If Jetson is powered off:
1a) Press and hold the recovery button
1b) Power on Jetson
1c) Wait a second
1d) Release the recovery button -
If Jetson is already powered on (even if lsusb shows Jetson as being in recovery mode):
2a) Press and hold the recovery button
2b) Wait a second
2c) Press and release the reset button
2d) Wait a second
2e) Release the recovery button
@stephen have attempted that so many times on my Ubuntu 18.04.2 host … many others stopping to at this point I understand
Recovery mode is needed only for flashing. After flashing and Jetson device booting up, usb-device mode is up . The expected results at this stage are:
- 192.168.55.1 is assigned to Jetson device, and
- 192.168.55.100 is assigned to host machine.
Could you please confirm if the two conditions are true on your Jetson device and your host PC?
Any update on this guys?
What a train wreck of an install process.
Again, I can flash the OS from recovery mode 100% of the time without fail.
I’ve now tried a host Intel NUC running Ubuntu 18 and now I’ve dropped it down to 16.
The l4tbridge adapter on the TX2 is showing the 192.168.55.1 address.
lsusb from the host machine doesn’t show any Nvidia anything.
From network connections I have no option to enable USB.
I’m about a week in and now mildly regretting I even went down the Jetson route. If I can flash the OS I should be able to manually install the damn SDK components.
Or I should be able to configure my ethernet connections to the appropriate 192.168.55.x addresses and it should talk over that.
Instead, from my interpretation of the log files, it’s demanding nvidia show up in lsusb, which it only does in recovery mode, not when it’s actually been flashed and fully configured and sitting at a desktop.
Really frustrating. I was planning to buy a few of these TX2s.
Hi jlangone,
I’m sorry for the inconvenience. Intel NUC is not officially supported by SDK Manager. SDK Manager is only supported on a normal PC. However, we may check more to see if there is any workaround with it.
Will the below method solve your problem?
https://devtalk.nvidia.com/default/topic/1048660/jetson-tx2/i-can-t-install-jetpack-4-2-sdk-on-my-tx2/post/5327925/#5327925
No. So I just laid down Ubuntu 16 on a Dell laptop I had lying around. Exact same problem. It’s almost like it’s not enabling usbnet or something. I don’t know. But about done trying with this platform. I’ve tried from a NUC, which flashes perfectly fine but doesn’t install SDK components, because (I think) there’s no USB network device on the host therefore no USB network device on the host to self-assign the 192.168.55.100 address.
The USB network device on the TX2 is fine and I see it self assigning 192.168.55.1 to the l4tbridge connection. I also see USB0 listed.
I see neither on the host machine.
I’ve tried having the USB cable going to the little USB dongle on the TX2 plugged into both ends during boot. I’ve tried plugging it in after login. It doesn’t matter.
It never shows in dmesg on the host nor in lsusb on the host for the SDK installation part. Works just fine for the flash the OS part.
Wishing I had bought the much cheaper Jetson platform that doesn’t use this SDK installation method now.
Is it possible to edit the SDK install script to use ethernet and 192.168.55.x?
I’ve spent more time working on an install than playing with Tensorflow.
NUC was up and running in an hour.
So, I’ve manually copied over everything in the SDK folder from host to TX2 and manually installing everything using gdebi and chugging along.
I did have to set LD_LIBRARY_PATH and PATH to include /usr/local/cuda/bin
LD_LIBRARY_PATH is meant for the location of dynamically loadable libraries. None will be found in a bin directory. There are various “lib” directories this might apply to, but “bin” is not one of them. Library path will be for libs of the target architecture. For example, “arm64/aarch64” versus “lib64”, and for the particular libraries you are interested in.
jlangone,
Can you please do a few things to help us debug the USB network issues:
Plug in the USB flashing cable between Jetson and your PC.
Boot Jetson from cold power on.
Run “dmesg > dmesg.txt”, and send us dmesg.txt.
After Jetson is booted, run “journalctl -u nv-l4t-usb-device-mode > service.txt” and send us service.txt.
Run “hexdump -C /proc/device-tree/serial-number” and send us the output. (You may need to install hexdump first by running “sudo apt install bsdmainutils”.)
Run the following commands:
sudo /opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode-stop.sh
sudo bash -x /opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode.sh > start.txt 2>&1
… and send us start.txt
Run:
cat ‘/sys/devices/external-connection/external-connection:extcon@1/extcon/extcon0/state’
… and send us the output.
Note: If “USB=1” is not present, then this indicates a problem with your USB cable or USB connector. Try replacing the cable, and/or reseating it in the micro USB connector. The “VID” feature of the cable is required for USB Ethernet to operate correctly, but not for recovery mode (flashing) to operate correctly.
Thanks!
Guys still have no instruction on how to make sure the Ubuntu 18.04.2 LTS host is configured properly to flash the Jetson TX2 with the latest Jetpack … is there an ETA to resolving this flash issue with the NVIDIA SDK???
nick.hortovanyi,
I don’t know why you’re having this problem. It is odd. Could you try flashing from a different host PC, using a different USB port on the PC, and using a different USB cable for the Jetson flashing port? Do you have a USB hub between your PC and Jetson; if so, perhaps try connecting Jetson directly to your PC.
Finally, perhaps if you run the following command it will give us more clues what is failing, although the failure is so early on this may not help:
sudo bash -x ./flash.sh jetson-tx2 mmcblk0p1
… and then send us the output from that command.
@stephen there is nothing wrong with the USB cable (and not using a hub). If I just boot the tx2 up, the USB Ethernet appears … I think the scp fails when in recovery mode … how should the host networking be configured?
Hi nick,
It’s fine and preferable to flash without a hub. We just want to understand the environment. USB cable sometimes does make difference. It’s not barely metal. At least I met similar issue before, i.e., couldn’t flash manually, and changing a usb cable finally solved the issue.
@edward it’s talking when not in recovery mode over the USB cable … am not using a hub… I do have a rtx2080 with latest cuda/cnn on that machine… the scp command isn’t working, that’s why I keep asking about network configuration. How can we determine that the network is set up correctly before the flash command?
So it seems that I also have this exact same issue.
I have a laptop running Ubuntu 18.04.2 LTS and after a successful flash to my TX2 using sdkmanager, it fails to load the sdk components.
I believe it is failing as the USB network on the host machine is missing.
On the TX-2 if i run ip addr, i get an l4tbr0 with an ip of 192.168.55.1
On the host machine if i run ip addr, i only have the ethernet connection.
The frustration is that i upgraded the laptop to 18.04 from 16.04 as the 4.2 jetpack would only run on 18.04…
any advise on how to get the usb network interface running on the host ??
Hi nick, aschofield,
Both Ubuntu 16.04 and 18.04 host environment are supported to run JetPack.
After Jetson device is flashed and booted, usb-device mode is automatically up and running, it is expected that
- 192.168.55.1 is assigned to jetson device
- 192.168.55.100 is assigned to one of the usb-ethernet port on host machine.
For your issue, if I understand correctly, 192.168.55.100 is not assigned to your host, only 192.168.55.1 is assigned to TX2. Please use below workaround.:
- Manually run “sudo ifconfig 192.168.55.100”, make sure you can ssh connect to 192.168.55.1 with this ethernet port.
- Continue with the JetPack installation.