I’ve been away from TX1 development for a few months. Last week I installed the newest 64-bit Jetpack 2.2 over my old installation without a hitch. I was doing some kernel module development and tried installing Firefox… to make a long story short ended up with an unstable filesystem. I tried re-installing again but had multiple issues with the installer tossing errors for a number of packages… but managed to flash the TX1, though the CUDA toolkit and a number of other things never installed. Now I can’t run apt-get update because of ‘duplicate’ sources related to the binary-arm64_packages. I simply can’t find the duplicate references.
How does one prepare the host to re-install a full TK1 image without being foiled by the json database? Deleting the /tmp directory, *.json files and the update.lock file allowed me to get past the screen where you select the components to install… before doing that the update screen never presented anything.
I’m not much of an Ubuntu package guy (I use Fedora mostly), but you might try these:
sudo apt-get clean
sudo apt-get autoclean
…then try again.
No, neither of those commands work.
What I discovered is that if I open /etc/apt/sources.list and uncheck all of the Ubuntu Software repositories relating to universe and multiverse on the TX1 I can then run apt-get update without errors. Who designs a package manager that quits when confronted with ‘duplicate sources’ without at least allowing for some kind of recovery. This breaks the entire Jetpack install chain. Worse, this is how the repository list comes up EVERY time Jetpack is run so there’s no chance of installing any of the nVidia tools like CUDA, Visionworks…
Now, on the TX1 I am left with .deb files and a script to install cuda-l4t and the other applications but despite my best efforts to run the script I can’t get cuda-l4t to install.
After 2 days of trying to get my TX1 to where it was the first time I ran Jetpack 2.2 I tried one more time. The Jetpack installer wouldn’t let me do a custom install to reinstall the cuda tool and so I selected uninstall… it went ahead and informed me that (1) it was going to install everything and that (2) everything was installed correctly after running all of the install scripts on the target… of course, when I logged into the target none of that happened because… the /etc/apt/sources.list breaks apt-get…
Since I use a Fedora host I can’t use JetPack, my ability to test is limited. It sounds strange that there would be duplicate sources between default repos and universe/multiverse. I’m betting it is a bad/misleading error message since one package is not expected to ever be in two separate repos. To avoid having to figure out a difficult issue, I’d suggest flashing the JTX1 once without JetPack, which should avoid issues…if it still fails after that then the configuration on host side is probably the culprit. If the issue is fixed, then JetPack can be used to continue just on packages such as CUDA.
Basically, just grab the driver package and sample rootfs. Unpack driver package, go to the rootfs and unpack the sample rootfs with sudo. cd to the parent of rootfs and find “apply_binaries.sh”, run:
sudo ./apply_binaries.sh
Make sure the Jetson is connected to host with the correct micro-USB cable, put it in recovery mode, and on host “sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1”. The same instructions would be correct regardless of version being R23.2, or R24.1 (32-bit or 64-bit).
After that see if JetPack works for just CUDA install without flash. This will determine which side (host versus JTX1) had the error. Note that you do not need ethernet or anything special attached to JTX1 for flash.sh to work…just the USB cable. Additional connections are for JetPack to install other things. Regular flash does not do all of the ssh and network setup, so this may also need changes if you just do flash.sh (default is to try to use dhcp so this is fine for most people…ssh keys could change though, and your host might expect the previous ssh keys, thus refuse ssh connect if this is the case).
The components JetPack installs can be separated as two parts, host components and target components. Host components installed by JetPack will be saved into a local json database. So when you reinstall with JetPack, it only contains target components by default. The status of host components is “no action”, meaning that you don’t need install this component again.
For your case, I suggest you run JetPack again, leave the components selected by default, and do the installation. This will flash the device again, and reinstall all components on target.