determined to use JetPack over wifi

I am trying to use the JetPack 3.2 installer with a TX2 over wireless since my host does not have an ethernet port. I have some hope that it is possible, despite the views on the forums, based on the logic that a local network connection is used to transfer the files and thus should not need to know if wifi or wired option is used. I found one thread where it sounds like an expert admits it might be possible, but not recommended.
…It may work then, but is not as reliable over wireless.
https://devtalk.nvidia.com/default/topic/1023293/how-to-install-jetpack-3-0-by-wireless-network/

My goal is to only install the “drivers” because the CUDA samples on the TX2 are complaining that no driver could be detected. The fact that the CUDA 9 Samples are on the device shows I was able to install some content with a wireless connection. I am hoping someone can understand the logs (I wish I could attach to this message). I noticed some "/dev/null"s but I’m not sure if the log is from only the most recent attempt or all attempts and I ran Jetpack several times, getting further sometimes.

I avoided a flash on this device, and thus did not connect the USB data cable, because I am gunshy after I put a different TX2 device in an unusable state (another thread coming) when attempting to use a different host to flash that device.

I cannot include the logs. If I try, the site is broken. I tried to paste the contents of the log since I cannot find a button to attach a document to the post.

jetpack_debug.log (14 KB)
flash_os_tx2-usb3-vm-wifi.log (179 KB)

One of the issues of WiFi (I think) is the method which JetPack uses to set up a connection, and then have it reported to the host. If you have installed to the Jetson such that you can set up WiFi, and if you manually enter the IP address, then it might work. There may be other issues.

“Drivers” can be a complicated topic if you don’t know which driver in particular. Drivers which are part of the NVIDIA infrastructure which makes Ubuntu into L4T (hardware accelerated) are easy to install…but probably the GUI wouldn’t work anyway if they were not there. You can check via:

sha1sum -c /etc/nv_tegra_release

CUDA applications, on the other hand, may have been compiled for a different GPU architecture (think Kepler, Maxwell, Pascal, so on). It will be beneficial to see exact messages and to know how the application was compiled or configured.

For me JetPack3.2 does not install, so I don’t know (it’s probably an issue with a tiny laptop which doesn’t have an NVIDIA video card and can’t completely function).

NOTE: After a post is done you can hover the mouse over the quote icon in the upper right and see a paper clip icon show up…this is for attaching files to an existing post. You can also edit with the pencil icon, and paste a log…but mouse highlight it and then click on the “</>” code icon to give it scrollbars and preserve formatting.

The connection from host to target went fine using wifi. I did need to enter the IP of the target and some files were actually transferred. Some problem occurred with the drivers because I cannot run anything that uses HW acceleration.

I attached one log to the OP. The forums show it is “scanning” forever. I hope you or anyone else can look at it. It might include several attempts running JetPack. The “/dev/null” entries concern me.

The cuda samples were compiled on the TX2, so I don’t think the architecture could be wrong.

For your problem with JP 3.2, I agree that not using a computer with nvidia support could cause that problem, although it sounds like an unfortunate limitation. Perhaps disabling some steps in the installer screen can avoid the problem.

I think I see the problem. The ssh command expects a config file to exist. I will work on building this file on the host.

ssh docs:

-F configfile Specifies a per-user configuration file. The default for the per-user configuration file is ~/.ssh/config.

This would make sense. Even with wired ethernet ssh has to have succeeded once and accepted if the user will not be required to reply that “yes, the connection is legitimate, go ahead and connect”. If you can’t reply to that ssh question, then you cannot connect.

On ssh command line this is never a problem, it just asks in the same terminal you connect from…for a GUI, and for anything automated, you need a second set of software for the pop-up to make the asking of password prompt available…appropriately named via the SSH_ASKPASS environment variable. If your host has installed an askpass mechanism (multiple “brands” of this are available, depending on distribution, e.g., KDE has “ksshaskpass”, Ubuntu has “ssh-askpass”…but often these are not installed by default and must be explicitly added).

Examples for Fedora with KDE:

dnf search askpass

=============================================================== Name & Summary Matched: askpass ===
lxqt-openssh-askpass-l10n.noarch : Translations for lxqt-openssh-askpass
lxqt-openssh-askpass.x86_64 : Askpass openssh transition dialog for LXQt desktop suite
==================================================================== Name Matched: askpass ========
ksshaskpass.x86_64 : A ssh-add helper that uses kwallet and kpassworddialog
openssh-askpass.x86_64 : A passphrase dialog for OpenSSH and X
x11-ssh-askpass.x86_64 : A passphrase dialog for X and not only for OpenSSH

From a Jetson TX2 on R28.1 (some results intentionally removed as not relevant):

apt search askpass

ksshaskpass/xenial 4:5.5.5-0ubuntu1 arm64
  interactively prompt users for a passphrase for ssh-add

lxqt-openssh-askpass/xenial 0.10.0-3 arm64
  OpenSSH user/password GUI dialog for LXQt

razorqt-openssh-askpass/xenial 0.5.2-4build1 arm64
  OpenSSH helper component for Razor-qt desktop environment

ssh-askpass/xenial 1:1.2.4.1-9 arm64
  under X, asks user for a passphrase for ssh-add

ssh-askpass-fullscreen/xenial 0.3-3.1 arm64
  Under Gnome2, asks user for a passphrase for ssh-add

ssh-askpass-gnome/xenial-updates 1:7.2p2-4ubuntu2.2 arm64
  interactive X program to prompt users for a passphrase for ssh-add

But…this would be the same issue regardless of whether using WiFi or wired. It isn’t just a WiFi issue. On the other hand, this askpass must be accomplished once for every “name@host” used…if your Jetson is at 192.168.1.3, and you ssh to “ubuntu@192.168.1.3”, and if there is also an alias of “tegra-ubuntu” for “192.168.1.3”, then although this is the same connection askpass must be run on each one, and “ssh name@192.168.1.3” will be considered completely separate from “ssh name@tegra-ubuntu”.

Note that “~/.ssh/config” might not be able to override “/etc/ssh/ssh_config” to loosen restrictions…it can however always tighten restrictions. I suspet that if you want to loosen a restriction you need to test and see if it actually works. Since WiFi is not behind a router to block incoming unwanted networks you are at extreme risk to do this if you do not change passwords. Everyone knows the default install accounts and passwords for Ubuntu.

After several more attempts today trying to install drivers over wifi, there was a time when Jetpack made it seem like the drivers actually got installed. Of course running the CUDA samples still result in ‘no acceptable driver found’ error.

I finally decided to get over my fear of flashing from my first experience and tried to flash my 2nd TX2. I suspect this only requires the USB connection because I was not propted for an IP for SSH to work. I used a fresh host to avoid any state of Jetpack causing problems. I disabled the “action” of Jetpack to ONLY flash the target, and do absolutely nothing else. Jetpack told me there was a dependency with another “action” so I allowed it to also install the OS and drivers (which is what I was trying to install before).

The end result of the flash is an error message that ‘CPU Bootloader is not running on device’. A Google search led me to this post, with an identical error message.
https://devtalk.nvidia.com/default/topic/1021542/jetson-tx2-failed-to-flash-on-jetpack-3-1/

I tried to attach my logs from the flash effort. I think the magic hidden icon for attaching files on this forum stuck the flash log on my OP. Maybe you guys can make sense of it but I don’t see anything valuable in there.

I’m really at a loss about this stuff. It should not be so difficult. I bought a TX2, actually 2 of them, but I can’t use either because the HW acceleration does not work out of the box and running Jetpack always results in an error when trying to install drivers or flash. I’ve spent a month of weekends trying to get this going. How should I move forward?

flash_os_tx2-usb3-vm-wifi.log (179 KB)

You are correct that flash does not require networking, only USB is used.

The other thread’s flash command line was doing something quite different…he was working on a specific partition with customizations and not flashing as a whole.

It looked like the flash succeeded fairly far in to the process (the “CPU Bootloader is not running on device” is normal slightly prior to that point, but then the final one is not normal). Note that I cannot use JetPack3.2 pre-release, my Ubuntu laptop does not seem to agree with it (an atom laptop without an NVIDIA video card), so if this is JetPack3.2 pre-release this may be an issue. Which JetPack version are you using?

Can I verify this was not a VM host? Have you tried flashing from command line without JetPack?