Introduction

Downgrading to CUDA 10.0 on Arch Linux is possible, but it is rarely a clean package-manager-only operation because Arch moves forward quickly and old NVIDIA stacks age out. The first decision is whether you truly need CUDA 10.0 on the host system, or whether a container or dedicated older environment would solve the compatibility problem with less risk.

Decide Whether You Need a Host Downgrade

If the goal is just to build or run one older project, a container is often safer than changing your entire Arch graphics stack.

Example with a CUDA 10.0 image:

docker run --rm --gpus all nvidia/cuda:10.0-cudnn7-devel-ubuntu18.04 nvcc --version

This keeps the host OS modern while giving the project an older userspace. If your tooling must run directly on the host, then a native downgrade becomes necessary, but it is the higher-risk option.

Inspect the Current Stack First

Before removing anything, record the currently installed CUDA and NVIDIA packages.

pacman -Q | rg 'cuda|cudnn|nvidia'
nvcc --version
nvidia-smi

You need to know what is present because CUDA compatibility depends on more than the cuda package alone. Toolkit, driver, and any libraries such as cuDNN must form a compatible set.

Use Cached or Archived Packages

On Arch, the easiest downgrade path is from your local package cache. Check whether the old packages are still present.

ls /var/cache/pacman/pkg | rg '^(cuda|cudnn|nvidia)'

If the required versions are cached, install them directly:

sudo pacman -U /var/cache/pacman/pkg/cuda-10.0*.pkg.tar.* \
  /var/cache/pacman/pkg/cudnn-7*.pkg.tar.*

If they are not cached, you usually need the Arch Linux Archive, a manual package source, or an AUR helper designed for downgrades. At that point, the exact package names and driver pairing matter enough that you should verify them carefully before replacing core graphics packages.

Remove Conflicting Packages Deliberately

Do not blindly remove the NVIDIA driver unless you know the replacement version you are about to install. But you should remove conflicting toolkit packages before installing an older toolkit.

sudo pacman -Rns cuda cudnn

If the downgrade also requires an older driver, plan that as one coordinated change window. An old CUDA toolkit on top of a mismatched or unsupported driver is a common failure mode.

Pin the Packages After Downgrading

Arch will otherwise upgrade the packages again on the next full system update. Add the downgraded packages to IgnorePkg in /etc/pacman.conf.

IgnorePkg = cuda cudnn nvidia nvidia-utils

Do not pin packages casually forever, but if you intentionally freeze an older CUDA environment, you need to stop pacman -Syu from undoing it immediately.

Validate the Result

After the downgrade, verify both the compiler and runtime view.

nvcc --version
nvidia-smi

Then compile a minimal CUDA program:

1#include <cstdio>
2
3__global__ void hello() {
4    printf("hello from GPU\n");
5}
6
7int main() {
8    hello<<<1, 1>>>();
9    cudaDeviceSynchronize();
10    return 0;
11}

Compile it with:

nvcc -o hello hello.cu
./hello

If compilation works but execution fails, the mismatch is often between toolkit and driver rather than the compiler itself.

Know When to Stop

Running CUDA 10.0 on a rolling distribution eventually becomes an ecosystem problem, not just a packaging problem. New kernels, new glibc versions, and modern NVIDIA packages are not designed around preserving very old CUDA workflows indefinitely.

If the host downgrade turns into a driver and kernel compatibility fight, the pragmatic answer is usually:

• use Docker or Podman with NVIDIA runtime support
• move the workload into a VM or older machine
• use a project-specific development container instead of freezing the host

That approach is often less work than pinning an old GPU stack on Arch for months.

Common Pitfalls

The biggest mistake is downgrading only the cuda package and ignoring driver compatibility. CUDA is a stack, not one file.

Another mistake is running a full system upgrade afterward without pinning the relevant packages. The downgrade appears to work and then disappears on the next update.

Developers also assume the package cache contains the needed version, only to discover too late that it was already cleaned. Verify availability before removing the current working setup.

Finally, do not treat host downgrade as the default answer. On Arch, an isolated container is often the cleaner and safer solution for legacy CUDA requirements.

Summary

• First decide whether you really need CUDA 10.0 on the host or whether a container is enough.
• Check the current CUDA, cuDNN, and NVIDIA driver packages before changing anything.
• Prefer installing old packages from the local pacman cache when possible.
• Keep toolkit and driver compatibility aligned, not just the cuda package version.
• Pin the downgraded packages in pacman.conf or Arch will upgrade them again.