Any word on a fix?
This reproduces 100% of the time for me
It will be fixed in next release build.
Sorry for the inconvenience.
Carol, do you have an ETA for next release build?
Referring to one of my threads, AastaLLL just posted this 4 hours ago,
Hi,
FYI.
We have fixed "sudo apt-get update" error in our next release.
Please wait for our announcement and update.
Thanks.
I get the “aarm64” errors on my AMD64 host, too. Aren’t those libraries/packages only used when cross-compiling? I sure would like to fix them soon.
nVidia, are you saying we should NOT use apt or apt-get upgrade or full-upgrade on the TX2?
Hi,
For device, ‘sudo apt-get update’ error is fixed in our next release.
We can’t disclosure our schedule, please pay attention to our announcement and update.
For host, we will check the update error after setting
sudo dpkg --add-architecture arm64
From #24, sorry for the misleading.
I need to double check if ‘sudo apt-get update’ on HOST is also fixed.
Will update information here.
Hi,
About ‘sudo apt-get update’ error on host:
First, the apt-get messages are harmless warnings.
If you face any functionality fail, please let us know.
The errors come from apt (a Canonical utility) rather than nVidia but we also documented this in our CUDA FAQ section:
[url]http://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html#faq4[/url]
It’s not recommended to use --force-architecture option since it may bring other problems.
Please refer to following setup entry that shows how to restrict specific repositories to specific architectures to avoid these 404 errors.
[url]http://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html#advanced-setup[/url]
Sorry but it’s not just about the host. It’s also about the TX2 itself. Apt is used by all the Linux distros derived from Debian, which is the majority of installed Linux out there. So there are lots and lots of people who are used to virgin installs of debian-based distros, and all of these people DO NOT expect apt-errors on a virgin install. So while I note the fact that you address this in the documentation, I’d say
a) It’s still not a good look and directly impacts perceived quality of the product (feels rushed).
b) While I might tolerate a bit of this on the host, after all we’re talking x86 and ARM on the same machine, it really should NOT be happening on the TX2 itself.
Thanks.
Hi,
As mentioned in #26, apt-get update warning in tx2 is fixed in our next release.
https://devtalk.nvidia.com/default/topic/1002140/jetson-tx2/apt-get-update-errors/post/5166794/#5166794
The statement: “it will be fixed in the next release and we’re not gonna tell you when you can expect it” is extremely poor customer support. Makes customers angry, including me. If you don’t know when we can expect it, please just say so. Are you so concerned about competition? You’re telling us we can’t rely on this hardware or this software.
Just like when you guys won’t even COMMENT on the nvme drive huge problem that just might be a grounding issue.
Does nVidia not give your team enough resources, especially as the size of the customer base grows?
If you want to be offended, it’s easy to be offended. In fact, you can find easier places the a technology forum for that ;-)
NVIDIA has previously said, publicly, in this forum, that next Jetpack is planned for July timeframe. The fact that they choose to have a designated person communicate in a designated place, rather than letting all employees talk about timelines, is just reasonable corporate communications, because it’s not everybody’s job to communicate timelines that other people will rely on. Engineers are not project managers.
@snarky: PO’ed != offended.
I have the same problem on the latest Jetpack 3.1 Ubuntu 16.04 with TX1.
When is it going to be fixed finally?
In Jetpack 3.2 this was not fixed.
Hi jonathanjames,
May I ask which error are you indicating? There are two errors in this topic.
i ran again into this error when i had to reflash my jetson.
- I get the apt update error on my host because of arm64 packages
- I get apt update error on my jetson because there are no public keys for cuda-repo-9-0-local and nv-tensorrt-repo-ga-cuda9.0-trt3.0.4-20180208
Any solutions to that?
For problems on host, you may check [url]https://devtalk.nvidia.com/default/topic/1004601/jetson-tx2/after-installing-jetpack3-0-host-computer-is-not-able-to-apt-get-update/post/5247479/#5247479[/url]
For problems on Jetson R28.2, you may check [url]https://devtalk.nvidia.com/default/topic/1030831/jetpack-3-2-mdash-l4t-r28-2-production-release-for-jetson-tx1-tx2/?offset=14#5245450[/url]
[url]https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html#advanced-setup[/url]
Each repository you wish to restrict to specific architectures must have its sources.list entry modified. This is done by modifying the /etc/apt/sources.list file and any files containing repositories you wish to restrict under the /etc/apt/sources.list.d/ directory. Normally, it is sufficient to modify only the entries in /etc/apt/sources.list
An architecture-restricted repository entry looks like:
deb [arch=,]
For example, if you wanted to restrict a repository to only the amd64 and i386 architectures, it would look like:
deb [arch=amd64,i386]
It is not necessary to restrict the deb-src repositories, as these repositories don’t provide architecture-specific packages.
For more details, see the sources.list manpage.
L4T 32.2.0 installed (JetPack unknown); Ubuntu 18.04.2 LTS, Kernel Version: 4.9.140, Cuda 10.0.326
I’m seeing the same problem as in Comment#1: I try to run “sudo apt-get update” and I get:
…
W: Invalid ‘Data’ entry in Release file /var/lib/apt/lists/_var_libopencv4tegra-repo_Release
W: GPG error: file:/var/cuda-repo-8-0-local Release: The following signatures were invalid 889BEE522DA690103C4B085ED88C3D385C37D3BE
E: The repository ‘file:/var/cuda-repo-8-0-local Release’ is not signed.
…
Unclear on how to resolve as the L4T version is later than this post and yet still seeing the same issue.
Just a note…CUDA 8 is invalid with later L4T releases under Ubuntu 18.04. If you are mixing a CUDA version from an earlier release with the newer Ubuntu 18.04 I would expect this to fail. There is some integration with the o/s and the same JetPack/SDK Manager release which flashed the system should be used with the particular CUDA release.
Quite some time back Ubuntu did not make signatures mandatory. At some point they moved to require signatures. During that transition time the error started showing up until signatures were added. Newer releases should have the signature, but there were workarounds for this in those older releases. Unfortunately, those older releases are not compatible with Ubuntu 18.04 on the Jetson.