Jetpack 4.4, 4.5 and 4.5.1 SDK absolutely UN-INSTALL-ABLE ?!

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

Dear All,

sending out a distress signal - am like totally to my wit’s end.

SDK Manager-based flashing of SDK packages (Jetson AGX Xavier) screws up every time toward the end.
Always (!) managing to install the L4T (Jetson OS), but never able to complete subsequent package installation procedure. Packages (CUDA, cuDNN, etc…) either get partially installed or not at all due to dependencies of others e.g. CUDA which oftentimes failes to install.

Error messages in console/log do vary from attempt to attempt:
o .mtd wrong / corrupt
o ‘command terminated with error’ (but doesnt specify which one)
o ‘download’ timeout (everything IS already downloaded ?)
o …

→ Exemplifying .log file attached. Incl. retry of SDK install, thus, file a bit large at first glance.
sdkm.log (1.0 MB)

Host system: i5, 12GB RAM, SS-USB Port.

Target system: 32GB Jetson Xavier AGX, P2888-0004

Things tried (my time wasted on the prev. two days):

  • Host OS changed {16.04 , 18.04}, fresh, clean vanilla installs
  • JetPacks changed {4.4, 4.5, 4.5.1 w/ and w/o that new addon }
  • Installation content changed {target only, target and host}
  • Host-side: sdk folders deleted {~/nvidia, ~/Downloads/nvidia, ~/.nvsdkm}
  • Host-side: apt-get remove and purge and whatnot of everything NV {‘nvidia’, ‘nsight’, …}
  • JetsonOS/L4T Flash sequence start changed {auto (via 192.168…55.1) , manual (via two button press)}
  • SDK Component Flashing via different NICs {USB-C/Eth bridge (192.168.55.1) , WiFi stick plugged into Jetson (DHCP assigned IP)}
  • Target: User autologon feature {on, off}
  • Host-side: Changed USB ports
  • SDK manager style changed {GUI, CLI}

CLI based SDK Manager lauch command: “sdkmanager --cli install --license accept --logintype devzone --product Jetson --version 4.5.1 --targetos Linux --target P2888-0004 --flash all --staylogin true”

Host-side: To validate the network connection is good, I kept the following running in different terminals and monitored them, but to no avail, everything looking good at those ends:

  • dmesg -wH (monitor for any suspicious event (e.g. USB-C/eth connection loss))
  • ping 192.168.55.1 (see if pings fail, but nada, pings always good, connection never interrupted)

Did NOT change/downgrade from current SDKmanager revision (1.4.1.7402), for I assumed that being too lame a culprit.

In all fairness, I have to admit the USB-C is NOT (!) the original NVidia cable. However, a robust wire after all, works like a charm with my phone and always (!) manages to support full L4T flashing, also manual ssh works fine and never aborts, thus I guess we can rule out the cable.

Since, as mentioned in prev. paragraph, L4T always finishes flashing, I guess we can also safely rule out a malfunctioning target device. L4T/JetsonOS always good, log in, sudo apt update, etc… always works.

Guys, this quality of experience is far fom what I’d expected of NV’s otherwise charming tools, thus, most likely the problem onceagain sits in front of the computer… I just dont see what I might be doing wrong here ?!

SOS.

THX !

2

Hi QBus,

I had similar problems with my virtual machine running 18.04. Then I got a new ACER Aspire in my hands and installed the same 18.04 into it. After that everything worked smoothly - I don’t know why! However, now the Jetson Nano is fighting back:(

3

Sounds like you tried most of what should be tried. I do recommend Ubuntu 18.04 on host side, but as experienced by @aesk, sometimes some host ports have quirks and trying another computer will get past the issue.

Just so you know, if flash succeeded, then you do need to run the first boot account setup prior to adding packages. What isn’t obvious is that you can choose to only flash, and uncheck the rest. Then, when you are certain that is complete, and the Jetson is fully booted and accessible via ssh login, you can uncheck everything in JetPack/SDKM except for an optional package install. No need to reflash every time.

Then, if you still have errors (and hopefully have tried a different computer), you can try these manual commands from the Xavier and see what errors show up:

sudo apt update
sudo apt --fix-broken

…then see what shows up after that for error messages.

1 Like
4

Thx mate, the sudo apt update is exactly what I figured out late last night and which did the trick. After all, I must say I find that pretty ridiculous - thousands of lines’ worth of install script, full scrubbing of the entire target is accepted (both things in conjunction meaning ‘a reference install’) and I have to manually run a sudo apt update before continuing on ? Wow… somehow doesnt add up. Either way, that problem is solved – on to the next ^^

5

That’s an “Ubuntu thing”. I find Ubuntu’s packaging reminiscent of what I think of more as a database, and not so much as a complete front end application. To be fair, that is what it is actually supposed to do, but I find Fedora/RedHat RPMs to be more robust and less complicated (with its front end, “dnf”, RPMs become exceptionally reliable in comparison to the whole Debian mechanism…but that’s just opinion). So I do agree with you it is a bit of a pain, and could use change, but you’d have to convince the Ubuntu package people of that.