So … turns out JetPack 3.2 breaks updates on the host system just like 3.1! Will you PLEASE fix this issue? And, PLEASE, don’t add “arm64” architecture to the host system! There is no need for it!
More broadly, can you please pare down the ridiculously bloated JetPack installer system? Why can’t a developer just get a tar/gzip file?
Normal embedded systems can be flashed simply by, 1. putting the device in recovery mode, and 2, running a script.
Hi michaelbdevine,
The JetPack bundles all of the developer tools required to develop for the Jetson platform, usually there are some dependencies between those SDK, and need to install together to ensure them work well.
You could refer to install guide to see if could resolve your issue:
[url]http://docs.nvidia.com/jetpack-l4t/index.html#developertools/mobile/jetpack/l4t/3.2/install.htm[/url]
Or could elaborate more about the problem you met, then we could understand what might be the the cause, and how to improve it.
Thanks
The problem is that JetPack installed dependencies to the update system that cannot be successfully satisfied at this time, resulting in a failure of the entire update system! This was a known problem with 3.1 as well. The only way a developer can unblock system updates is to run the following two commands (on the host computer) to remove the improper multiarch configuration that JetPack installs:
sudo apt-get remove .*:arm64
sudo dpkg --remove-architecture arm64
After that, I can successfully run updates (either from the Ubuntu UI or command line).
For your reference, the issue can be observed when running the Ubuntu update ui. Launch the “Software Updater” application and the following error will be displayed:
“Failed to download repository information … Check your internet connection”
To observe the issue from the command line, run the command
sudo apt-get update
You will see many errors like the following:
“E: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-arm64/Packages 404 Not Found [IP: 91.189.91.23 80]”
My host system is an amd64 architecture machine. It cannot run arm64, at all, and as such it SHOULD NOT be set up as a multi-architecture platform supporting arm64. Even cross compilers for arm64 that run on my machine are amd64 architecture binaries. Please explain this to your installer team.
In short, again, your installer team has broken system-wide updates on host machines on which JetPack has been installed.
Hi michaelbdevine,
Thanks for providing the update, this issue was related with CUDA installer due to many considerations and needs to have comprehensive coverage for all combinations of cross packages.
It has been forwarded to relevant teams as improvement reference, we will try to resolve this problem in coming release.
Thanks
Awesome! Thanks! I especially appreciate the responsiveness of the Forum team!
THe jetpack 3.2 uninstaller doesn’t work at all. It just appears to hang at “uninstalling com.nvidia.cuda.host”. I have to say that trying to get started with Jetson has been a total bomb. 2 days now unable to setup my new system. I thought I was getting close only to reach the flash phase fail. Trying to back it out now to give it one more try.
I’ll just add that the jetson component manager is a piece of garbage. Obviously never tested for anything other than the prescribed expected workflow.
You’ll find flash is over the micro-B USB and tends to work…what you are describing is that after the flash your host either hasn’t found the Jetson network address on wired ethernet, or else there is some sort of firewall or internet issue between host and the internet. This always happens with a VM, so it is important to know if it is a VM or a native Linux install on the host. Network issues depend on whether the host is acting as router or if you have a separate router appliance…so knowing what your router is will also be important.
You can run JetPack at any time and uncheck everything but the package install. If the Jetson flashed and rebooted then you should be ok once figuring out networking. It would be very useful though to see a log of anything which might identify specifically what failed. On a separate package install you’ll need to manually enter what the wired ethernet address is. Be sure to check the console in JetPack to see if it is prompting for a password. It’s also useful to install ssh-askpass in case of an ssh prompt over the GUI (“sudo apt-get install ssh-askpass”).
Thank you for the quick reply. It turned out ok. When I ran Jetpack again it prompted me for the ssh credentials and it worked fine. I think the app tries to hide a lot of the complexity. Over the course of 2 days I had several occasions where it failed for various reasons. It might be better to simply document all the steps.
Thanks again.
John
John, can you check to see if updates on your host system are working?
On your hosts system (not on the Jetson) run “sudo apt-get update”. If you see errors, then you won’t get any updates to your host system, including critical security updates!
I don’t get why NVIDIA isn’t treating this issue as a critical security flaw? Unless I’m mistaken, everyone using JetPack is no longer getting critical security updates for their host system.
We need an urgent patch for this.
Yes, the problem is that whoever builds the JetPack at NVIDIA doesn’t seem to have internalized how dpkg installation and system architectures work, and are breaking the expected rules for package management on the system.
Just because I cross-compile for aarm64/arm64, doesn’t mean that the arm64 machine architecture should be installed. Architectures are only for things the machine can actually run! If there are headers and libraries that are available for cross-compilation from x64 and self-compilation form the Jetson itself, it may be better to mark them as architecture independent! (Also, put the “dev” headers/libraries somewhere other than in the default install locations for host native libraries.)
This is not particularly rocket science, but it seems the NVIDIA installation started out being built in the wrong way, and has now jammed itself far into the place where it keeps breaking host package management whenever JetPack is installed.
A very easy test to run after installing jetpack is this:
If the release upgrade breaks because of a missing arm64/aarch64 package, then JetPack is broken.
Exactly, Snarky! Just give us a tgz with the libs, includes, toolchain, and a script to set the environment.
Given the bulk of it, the normal solution would be to use a VM so as not to corrupt the primary. But, as I, John, and I’m sure others have learned the hard way, the flashing system can’t handle a target reboot from inside a VM. Ugh!!!
A TGZ would be great, but I’d be OK with dpkg packages, too, as long as they are properly defined for the systems they are used with.
Add one more vote for fixing this sooner rather than later. Jetpack should not be breaking the host OS update. This is much more painful than it needs to be. My strong preference would be for the absolute minimum Tegra OS with everything else in an optional pkg. We end up needing to do a bunch of work to strip out all the extraneous stuff that is not needed in a purely embedded system, and this work needs to be manually repeated at every release. It’s a waste of very precious time.
You are my savior michael! Your fix worked.
And nvidia, please fix this issue ASAP
I ran into this issue as well.
And Jetpack 3.3 continues to break apt. NVIDIA will this ever be fixed?
Problem persists - unable to update from updater or CLI… Have turned off auto updating for dev machine (I mean…what’s the point of having it run if it can’t reach and download from the repositories?) and will not deploy until this is resolved and security patches can be updated.