Package source leads to failed flashing on Jetson Orin NX

I am looking to reflash my Jetson Orin NX using Ubuntu 22.4 Host Machine and SDK-Manager. Upon completion the SDK-manager outputs an error related to apt.

E: The repository ‘https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/amd64 Release’ does not have a Release file.
N: Updating from such a repository can’t be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

that extract is also found in the sdk manager logs. The URL does indeed not lead to anything and I am looking to use the arm64. Why does SDK manager pick false sources and how can I change it accordingly for my system?

full log below:

sdkm-2024-03-15-08-05-56.log (1.5 MB)

Manually changing the URL in the apt sources list fixed that particular issue. Even though SDK Manager insists on using the amd64 list I simply changed the URL to source the arm64 driver instead.

sudo nano /etc/apt/sources.list.d/cuda-ubuntu2204-amd64.list

I don’t know if there is something else going on, but when you flash there are packages for the host PC, plus there are packages for the Jetson. The host PC can only use amd64 packages, and the Jetson can only use arm64 packages. If you add arm64 to the host PC, then those will fail or break. If you add amd64 to the Jetson, then those will fail or break. There is a mix because amd64 tools are being used to add arm64 software to the Jetson (such as through QEMU). You might want to say explicitly which one you used that edit on…Jetson or host PC.

I edited /etc/apt/sources.list.d/cuda-ubuntu2204-amd64.list on the hostpc which should have amd architecture.
The target device had arm64 which caused the conflict. Its not elegant and it might cause issues but it was the way I fixed it.

It is ok to add the amd64 to the host PC list. However, it only supplies packages for the host PC. For example, adding CUDA to the host PC would use that. If you use JetPack/SDK Manager, then there is a strong possibility that one of the host PC downloads would in fact use exactly that repository. Your fix is in fact the recommended fix.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.