在 Fedora 45 / 44 上安装 CUDA 与 NVIDIA 容器工具链

本文的目标是在 Fedora 45 / 44 上搭建一套完整的 CUDA 环境：由 RPM Fusion 提供 NVIDIA 驱动，NVIDIA 仓库提供 CUDA Toolkit，并使用 NVIDIA Container Toolkit 生成 CDI 规格，让 rootless Podman、Docker 与 Ollama 容器访问 GPU。

测试过程中首先遇到的是仓库地址问题：NVIDIA 还没有发布 fedora45 的 CUDA 仓库树，沿用按 $releasever 展开的仓库配置会在下载任何软件包之前返回 404。可将 Fedora 44 的仓库用于 Fedora 45，前提是避免 NVIDIA 仓库中的驱动包与 RPM Fusion 驱动发生混装。以下操作在 2026 年 10 月于 AWS 的 Fedora 45 云实例上完成，实例带一块 NVIDIA A10G，SELinux 处于 enforcing 模式。

Fedora 上 CUDA 与容器的分层

这套环境由三个仓库构成，其中只有一个负责驱动。RPM Fusion 使用 akmods 构建内核模块，NVIDIA CUDA 仓库提供 nvcc 与 /usr/local/cuda 下的库，NVIDIA 容器仓库提供生成 CDI 规格的工具。容器本身完全不需要 CUDA Toolkit，它们只需获得 CDI 规格列出的设备节点与驱动库，因此主机即使未安装 Toolkit，容器也能运行 CUDA 13 代码。

图中的红框标出最初的问题：使用 $releasever 的仓库解析为 fedora45，但该路径不存在。测试机器各层对应的组件如下：

层级	软件包	仓库	测试版本
内核模块与驱动	`akmod-nvidia`、`xorg-x11-drv-nvidia-cuda`	RPM Fusion nonfree	615.78.08
编译器与库	`cuda-toolkit`	NVIDIA cuda-fedora44	13.4.3（nvcc V13.4.92）
CDI 规格生成	`nvidia-container-toolkit`	NVIDIA libnvidia-container	1.20.1
容器引擎	podman、docker-ce	Fedora、Docker CE	6.1.3、29.9.2
主机编译器	gcc	Fedora	16.2.1

开始前的硬件准备

测试实例为 g5.xlarge：4 个 vCPU、16 GB 内存、24 GB 显存的 A10G，以及 80 GB 根磁盘。磁盘空间容易低估，仅 Toolkit 就需要约 8 GiB：

Fedora 45 或 44，x86_64 架构，具备 sudo 权限
lspci 能识别的 NVIDIA GPU
根分区至少有 15 GB 空闲空间，供驱动、Toolkit 和若干镜像使用
Secure Boot 已关闭，或已为 akmods 注册 MOK 密钥

AWS 实例关闭了 Secure Boot，因此无需签名。启用 Secure Boot 的工作站必须注册 akmod 模块密钥，否则模块无法加载。先确认内核能识别显卡：

sudo dnf install -y pciutils
lspci | grep -i nvidia

g5 实例中的 A10G 显示为 PCI 总线上的 3D 控制器：

00:1e.0 3D controller: NVIDIA Corporation GA102GL [A10G] (rev a1)

如果没有任何输出，说明存在显卡直通或插槽问题，后续步骤无法修复。应先解决硬件识别，因为即使没有可见显卡，驱动仍可能安装成功，只在重启后失败。

从 RPM Fusion 安装 NVIDIA 驱动

选择 RPM Fusion 是因为其 akmod 会在每次 Fedora 内核更新后重新构建模块，这能避免安装一个月后内核升级导致驱动失效。NVIDIA 仓库也能提供驱动，但混用两套驱动栈会引发冲突。先更新系统；若下载了新内核，应重启：

sudo dnf upgrade -y --refresh

测试镜像已是最新状态。随后启用 RPM Fusion 的 free 与 nonfree 仓库：

sudo dnf install -y \
  https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm \
  https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

安装 akmod 与 CUDA 用户态库。xorg-x11-drv-nvidia-cuda 会在主机上提供 nvidia-smi 与 libcuda.so，即使是无图形界面的服务器也不能省略：

sudo dnf install -y akmod-nvidia xorg-x11-drv-nvidia-cuda

测试事务耗时 1 分 55 秒，即使在云镜像中也带入 PipeWire 和 upower 依赖。dnf 会先返回，但 akmod 构建仍在后台运行约 90 秒。应等待 modinfo 能读取模块后再重启：

for i in $(seq 60); do
  modinfo -F version nvidia 2>/dev/null && break
  sleep 10
done

模块构建完成后会输出驱动版本：

615.78.08

重启系统，让新模块替代 nouveau：

sudo reboot

恢复后使用以下命令检查显卡：

nvidia-smi

测试中的 7.2 内核显示如下：

NVIDIA-SMI 615.78.08   KMD Version: 615.78.08   CUDA UMD Version: 13.4
GPU: NVIDIA A10G   Memory: 23028 MiB

“KMD Version”是内核模块版本，“CUDA UMD Version”是该驱动支持的最高 CUDA 运行时版本。后面的 Toolkit 与容器镜像都不能超过 13.4。

在 Fedora 45 上使用 fedora44 CUDA 仓库

检查时 NVIDIA 下载服务器只有 fedora43 和 fedora44 的仓库树，没有 fedora45。添加仓库前可先探测：

for r in fedora45 fedora44 fedora43; do
  echo == $r
  curl -sI https://developer.download.nvidia.com/compute/cuda/repos/$r/x86_64/repodata/repomd.xml | head -1
done

测试结果中只有 fedora45 缺失：

== fedora45
HTTP/2 404
== fedora44
HTTP/2 200
== fedora43
HTTP/2 200

Error: “Status code: 404 …/cuda/repos/fedora45/x86_64/repodata/repomd.xml”

仓库配置使用 fedora$releasever，或手动把 fedora44 改为 fedora45 时，会出现该错误。dnf 通常重试几次后报告找不到可用 URL：

>>> Status code: 404 for https://developer.download.nvidia.com/compute/cuda/repos/fedora45/x86_64/repodata/repomd.xml
>>> Usable URL not found

应使用 NVIDIA 官方 fedora44 仓库文件，它把发行版写死，不会展开 $releasever。Fedora 44 上这就是原生仓库；Fedora 45 上软件包虽按 Fedora 44 构建，但测试中没有依赖问题：

sudo dnf config-manager addrepo \
  --from-repofile=https://developer.download.nvidia.com/compute/cuda/repos/fedora44/x86_64/cuda-fedora44.repo

dnf5 把配置写入 /etc/yum.repos.d/cuda-fedora44.repo，每个 URL 都固定为 fedora44。仓库文件大致如下：

[cuda-fedora44-x86_64]
name=cuda-fedora44-x86_64
baseurl=https://developer.download.nvidia.com/compute/cuda/repos/fedora44/x86_64
enabled=1
gpgcheck=1
gpgkey=https://developer.download.nvidia.com/compute/cuda/repos/fedora44/x86_64/73CD9B30.pub

等 NVIDIA 发布 fedora45 仓库后，应替换仓库文件，并把下一节的排除设置应用到新的仓库 ID cuda-fedora45-x86_64。排除项与仓库 ID 绑定，不会随替换自动迁移。已安装软件包不受影响，只有后续更新来源改变。

为什么保持 NVIDIA 驱动包于仓库之外

NVIDIA CUDA 仓库不只包含 Toolkit，还提供完整的驱动栈，包括 nvidia-driver、kmod-nvidia-open-dkms、nvidia-settings 与 nvidia-persistenced，版本比 RPM Fusion 已提供的驱动落后一个点版本。测试使用 --assumeno 检查安装 nvidia-driver 会发生什么：

sudo dnf install --assumeno nvidia-driver

dnf 会拒绝，因为两套驱动栈声明互相冲突：

Problem: installed package ... requires nvidia-kmod-common >= 3:615.78.08
  - installed package xorg-x11-drv-nvidia ... conflicts with xorg-x11-drv-nvidia provided by nvidia-driver ... from cuda-fedora44-x86_64
  - conflicting requests
You can try to add to command line:
  --allowerasing ...

拒绝是安全结果。不要添加 --allowerasing，它会移除 RPM Fusion 驱动与 akmod。更隐蔽的风险来自升级：CUDA 仓库中的 nvidia-settings、nvidia-persistenced 和 nvidia-modprobe 使用与 RPM Fusion 相同的名称和 epoch，一旦 NVIDIA 构建较新，普通 dnf upgrade 可能从错误仓库拉取它们。因此应把排除项作为安装流程的一部分：

sudo dnf config-manager setopt \
  cuda-fedora44-$(uname -m).exclude=nvidia-driver*,cuda-drivers*,nvidia-modprobe,nvidia-persistenced,nvidia-settings,nvidia-libXNVCtrl*,nvidia-xconfig,nvidia-open,nvidia-imex,nvidia-kmod-common,libnvidia-fbc,kmod-nvidia-*-dkms,nvidia-fs*,nvidia-gds*,xorg-x11-nvidia*

dnf5 将此设置写入仓库配置，不直接修改原始 .repo 文件。每次 NVIDIA 驱动发布后，建议先执行 sudo dnf upgrade --assumeno，检查 nvidia 软件包来源，再决定是否应用。

安装 cuda-toolkit 而不是 cuda

应安装 cuda-toolkit，不要安装 cuda。两者在当前环境中相差 cuda、cuda-13-4 和 cuda-runtime-13-4 三个包，其中 cuda-runtime-13-4 会引入驱动依赖。虽然 RPM Fusion 软件包可以满足该依赖，但没有理由让驱动依赖进入 Toolkit 事务。Toolkit 体积较大：

sudo dnf install -y cuda-toolkit

磁盘较小时先执行 dry-run，把 -y 替换为 --assumeno：

sudo dnf install --assumeno cuda-toolkit

测试摘要如下：

Transaction Summary:
 Installing:        75 packages

Total size of inbound packages is 4 GiB. Need to download 4 GiB.
After this operation, 8 GiB extra will be used (install 8 GiB, remove 0 B).

在 eu-west-1 下载并安装耗时 8 分 41 秒，几乎全部用于下载，同时导入 NVIDIA“Kitmaker (Fedora 44)”签名密钥。安装结果位于 /usr/local/cuda-13.4（5.2 GB），/usr/local/cuda 是指向当前版本的选择链接，因此以后可并存 13.5。软件包还会在 /etc/ld.so.conf.d/ 写入 000_cuda.conf，ldconfig -p 已能解析 libcudart.so.13，无需设置 LD_LIBRARY_PATH。仅需补充 PATH：

echo 'export PATH=/usr/local/cuda/bin:$PATH' | sudo tee /etc/profile.d/cuda.sh
source /etc/profile.d/cuda.sh
nvcc --version

nvcc 显示 13.4，与驱动的 UMD 上限一致：

Cuda compilation tools, release 13.4, V13.4.92

新的登录 shell 会自动读取 profile.d，source 仅对当前会话生效。

使用 nvcc 与 GCC 16 编译 CUDA 内核

Fedora 45 提供 GCC 16，而许多 CUDA 版本会拒绝比测试版本更新的主机编译器。CUDA 13.4 已将上限提升到 16，可查看 nvcc 检查的头文件确认：

grep -n __GNUC__ > /usr/local/cuda/targets/x86_64-linux/include/crt/host_config.h

第 135 行只会在 GCC 高于 16 时报错：

135:#if __GNUC__ > 16
139:#endif /* __GNUC__ > 16 */

要验证完整工具链，可编译一个向量加法程序：把两个各有 100 万个 float 的数组传到 GPU，在内核中相加，再回传并在主机逐项比较。创建 ~/vecadd.cu：

vi ~/vecadd.cu

内容如下：

#include <cstdio>
#include <cmath>
#include <cuda_runtime.h>

#define CHECK(call) do { cudaError_t e = (call); if (e != cudaSuccess) { \
    fprintf(stderr, CUDA error: %s at %s:%d\n, \
            cudaGetErrorString(e), __FILE__, __LINE__); \
    return 1; \
} } while (0)

__global__ void vecAdd(const float *a, const float *b, float *c, int n) {
    int i = blockIdx.x * blockDim.x + threadIdx.x;
    if (i < n) c[i] = a[i] + b[i];
}

int main() {
    const int n = 1 << 20;
    size_t bytes = n * sizeof(float);

    cudaDeviceProp prop;
    CHECK(cudaGetDeviceProperties(&prop, 0));
    printf(Device: %s (compute capability %d.%d)\n,
           prop.name, prop.major, prop.minor);

    float *a = (float *)malloc(bytes);
    float *b = (float *)malloc(bytes);
    float *c = (float *)malloc(bytes);
    for (int i = 0; i < n; i++) {
        a[i] = 1.5f * i;
        b[i] = 2.0f * i;
    }

    float *da, *db, *dc;
    CHECK(cudaMalloc(&da, bytes));
    CHECK(cudaMalloc(&db, bytes));
    CHECK(cudaMalloc(&dc, bytes));
    CHECK(cudaMemcpy(da, a, bytes, cudaMemcpyHostToDevice));
    CHECK(cudaMemcpy(db, b, bytes, cudaMemcpyHostToDevice));

    int threads = 256;
    int blocks = (n + threads - 1) / threads;
    vecAdd<<<blocks, threads>>>(da, db, dc, n);
    CHECK(cudaGetLastError());
    CHECK(cudaMemcpy(c, dc, bytes, cudaMemcpyDeviceToHost));

    float maxErr = 0.0f;
    for (int i = 0; i < n; i++) {
        maxErr = fmaxf(maxErr, fabsf(c[i] - (a[i] + b[i])));
    }
    printf(Added %d elements, max error: %g\n, n, maxErr);
    printf(%s\n, maxErr == 0.0f ? PASS : FAIL);

    cudaFree(da);
    cudaFree(db);
    cudaFree(dc);
    free(a);
    free(b);
    free(c);
    return maxErr == 0.0f ? 0 : 1;
}

使用 GCC 16 编译并运行：

nvcc -arch=sm_86 -o ~/vecadd ~/vecadd.cu
~/vecadd

测试输出显示 A10G 的计算能力为 8.6，100 万个元素的最大误差为 0，并打印 PASS。-arch=sm_86 对应 A10G；其他 GPU 应根据计算能力调整，例如消费级 Ada 架构可用 sm_89。若不指定架构，nvcc 可能生成兼容构建，但不一定匹配当前设备。

如果使用的 CUDA 版本尚未支持 GCC 16，host_config.h 会拒绝当前编译器。可选择安装更旧版本的 CUDA，或使用 Fedora 提供的 GCC 15 兼容编译器：

sudo dnf install -y gcc15-c++
nvcc -ccbin g++-15 -arch=sm_86 -o vecadd vecadd.cu

测试中 GCC 15 作为主机编译器也通过了。优先使用 -ccbin，而不是 -allow-unsupported-compiler，后者只是关闭版本检查，后续模板错误更难排查。

### Error: “CMAKE_CUDA_ARCHITECTURES is not set” 构建 deviceQuery 时

NVIDIA 自带样例已从旧路径 Samples/ 迁移到 cpp/，独立构建样例不会猜测 GPU 架构，可能返回：

CMake Error at .../DetectCudaArch.cmake:2 (message):
  CMAKE_CUDA_ARCHITECTURES is not set.

A10G 的计算能力为 8.6，因此参数写为 86，不带小数点。测试中的构建耗时 4 秒：

sudo dnf install -y cmake git make
git clone --depth 1 https://github.com/NVIDIA/cuda-samples.git
cd cuda-samples/cpp/1_Utilities/deviceQuery
mkdir build && cd build
cmake -DCMAKE_CUDA_ARCHITECTURES=86 ..
make
./deviceQuery

输出顶部应看到 CUDA 驱动版本与运行时版本，底部应显示结果：

Device 0: NVIDIA A10G
  CUDA Driver Version / Runtime Version          13.4 / 13.4
  CUDA Capability Major/Minor version number:    8.6
...
deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 13.4, CUDA Runtime Version = 13.4, NumDevs = 1
Result = PASS

驱动与运行时版本一致说明安装正常。若运行时版本高于驱动支持版本，应升级驱动，而不是降级 Toolkit。

安装 NVIDIA Container Toolkit 并生成 CDI 规格

容器不需要 CUDA Toolkit，因此这一部分只安装了驱动的机器也可以执行。NVIDIA 提供适用于所有 RPM 发行版的仓库文件：

curl -s -L https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo |
  sudo tee /etc/yum.repos.d/nvidia-container-toolkit.repo
sudo dnf install -y nvidia-container-toolkit
nvidia-ctk --version

测试中安装四个软件包，总大小 11 MiB，耗时 4 秒：

NVIDIA Container Toolkit CLI version 1.20.1
commit: dffc40b4f820ce5c512633bac9e0418d0e05a2ee

安装内容除了 CLI，还包括 CDI 所需组件：

nvidia-container-toolkit-base 提供的 nvidia-ctk
preset 自动启用的 nvidia-cdi-refresh.path 与 .service
udev 规则 99-nvidia-cdi-refresh.rules
覆盖配置 /etc/nvidia-container-toolkit/nvidia-cdi-refresh.env

许多教程要求手动执行 nvidia-ctk cdi generate，但 Toolkit 1.18 起已启用 nvidia-cdi-refresh.path，安装事务运行期间就会生成 /var/run/cdi/nvidia.yaml。该文件会在 Toolkit 或驱动安装、升级及重启时刷新，但驱动被移除时不会自动清理，因此卸载后需要手动重新生成。查看已发现的设备：

nvidia-ctk cdi list

一块 GPU 会显示索引、UUID 和 all 三个名称：

nvidia.com/gpu=0
nvidia.com/gpu=GPU-0b18b197-4ea9-4e4d-71bd-739e2e3bf67a
nvidia.com/gpu=all
time=... level=info msg=Found 3 CDI devices

无图形界面的服务器日志可能包含找不到 nvidia_drv.so、libglxserver_nvidia.so 等 X11 文件的警告，这是正常的，计算用途的规格仍完整。不要把手动生成的副本放到 /etc/cdi：驱动更新后只有 /var/run/cdi 会刷新，可能产生两份不一致的规格。确需刷新时重启服务：

sudo systemctl restart nvidia-cdi-refresh.service

在 rootless Podman 中运行 GPU 容器

Fedora Cloud 镜像自带 Podman 6.1，原生读取 CDI 规格，因此容器只需一个 --device nvidia.com/gpu=all 参数。首次 rootless 运行仍可能失败：

podman run --rm --device nvidia.com/gpu=all \
  docker.io/nvidia/cuda:13.4.3-base-ubi9 nvidia-smi

容器镜像正常拉取，命令却返回：

Failed to initialize NVML: Insufficient Permissions

设备节点已经注入，仍失败的原因在 SELinux。若加上 --security-opt=label=disable 后可以正常输出完整表格，基本可确定是 SELinux 容器策略引起的。

在 SELinux enforcing 下修复 “Failed to initialize NVML: Insufficient Permissions”

Fedora 的容器策略默认禁止受约束容器使用主机设备节点，除非启用 container_use_devices 布尔值。NVIDIA 文档建议关闭标签约束，虽然可行，但会让该容器失去 SELinux 隔离。更精确的做法是启用布尔值，使容器保留标签，同时获得设备访问权限：

getsebool container_use_devices
sudo setsebool -P container_use_devices on

之后同一 rootless 命令可输出完整 nvidia-smi 表格。也可把宿主机编译的 vecadd 挂载到一个不含 CUDA Toolkit 的容器中运行：

podman run --rm --device nvidia.com/gpu=all \
  -v ~/vecadd:/vecadd:Z \
  docker.io/nvidia/cuda:13.4.3-base-ubi9 /vecadd

失败与成功对比如下：

启用布尔值后，带 root 的 sudo podman run 也能使用相同参数。若通过 Quadlet 单元启动 Podman，可在 [Container] 段添加 AddDevice=nvidia.com/gpu=all，但本文没有在该机器上验证这一配置。

Podman 其他常见错误

未提供 --device：crun: executable file nvidia-smi not found in $PATH
vecadd 未提供 --device：CUDA driver version is insufficient for CUDA runtime version
使用不存在的 GPU 编号：Error: setting up CDI devices: unresolvable CDI devices nvidia.com/gpu=1

第二条容易误认为版本不匹配，实际问题是没有注入 libcuda.so，先检查设备参数。基础 CUDA 镜像不一定包含 nvidia-smi，这也是第一条错误显示命令不存在而不是 GPU 错误的原因。多 GPU 机器可用 nvidia.com/gpu=0，或使用 nvidia-ctk cdi list 输出的 UUID 固定到某块卡。

在 Docker 中使用 CDI 运行 GPU 容器

Docker 29.9 在测试中无需配置 daemon.json。Docker CE 已提供 Fedora 45 仓库，可直接使用标准仓库文件：

sudo dnf config-manager addrepo \
  --from-repofile=https://download.docker.com/linux/fedora/docker-ce.repo
sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
sudo systemctl enable --now docker
sudo docker info

即使没有任何 Docker 配置文件，docker info 也会列出 CDI 目录与刷新服务写入的 GPU：

Server Version: 29.9.2
CDI spec directories:
  /etc/cdi
  /run/cdi
Discovered Devices:
  cdi: nvidia.com/gpu=0
  cdi: nvidia.com/gpu=GPU-0b18b197-4ea9-4e4d-71bd-739e2e3bf67a
  cdi: nvidia.com/gpu=all

CDI 参数和传统 --gpus all 都可直接使用：

sudo docker run --rm --device nvidia.com/gpu=all \
  docker.io/nvidia/cuda:13.4.3-base-ubi9 nvidia-smi -L

sudo docker run --rm --gpus all \
  docker.io/nvidia/cuda:13.4.3-base-ubi9 nvidia-smi -L

二者都输出相同的 GPU 标识：

GPU 0: NVIDIA A10G (UUID: GPU-0b18b197-4ea9-4e4d-71bd-739e2e3bf67a)

执行 sudo nvidia-ctk runtime configure --runtime=docker 会在 /etc/docker/daemon.json 添加 nvidia 运行时，但测试中配置前后的结果一致。只有仍使用 --runtime=nvidia 与 NVIDIA_VISIBLE_DEVICES 的旧镜像才需要该运行时。测试 Docker 时 container_use_devices 已因 Podman 部分启用，因此无法确认 Docker 在未启用该布尔值时是否也会遇到 NVML 权限问题。

通过 Podman 让 Ollama 使用 GPU

本地模型服务器是这套环境最常见的用途。可在 rootless Podman 中启动 Ollama，同样只需添加设备参数：

podman run -d --name ollama \
  --device nvidia.com/gpu=all \
  -p 11434:11434 \
  docker.io/ollama/ollama

podman exec ollama ollama run llama3.2:1b say hi
podman exec ollama ollama ps

重点查看 PROCESSOR 列。“100% GPU”表示所有层都卸载到显存；若出现 CPU 百分比，说明 CDI 设备未正确传入容器：

NAME           ID              SIZE      PROCESSOR    CONTEXT    RUNNER      UNTIL
llama3.2:1b    baf6a787fdff    1.5 GB    100% GPU     4096       llamacpp    4 minutes from now

Ollama 日志应包含 library=CUDA compute=8.6 name=CUDA0 description="NVIDIA A10G"，并加载 cuda_v13 后端。宿主机 nvidia-smi 中也应看到 llama-server 占用显存。测试中它占用 1738 MiB。

以后如需移除 Toolkit，可先执行 dry-run：

sudo dnf remove --assumeno cuda-*13-4*

测试中该命令列出 74 个软件包，释放约 8 GiB。检查摘要时确认不包含 rpmfusion-nonfree 的驱动包。小型的 cuda-toolkit-config-common 不匹配该通配符，会被保留；gcc-c++ 可能作为 Toolkit 依赖一并被移除，应检查后再确认。

尚待验证的环境

云实例没有覆盖所有实际环境：

AWS 上 Secure Boot 关闭，未测试 MOK 签名流程。
仅在实际 GPU 上测试 Fedora 45，Fedora 44 使用同一仓库但未运行完整 GPU 流程。
NVIDIA 尚未提供 fedora45 CUDA 仓库，因此没有测试从 fedora44 迁移到 fedora45 仓库。
连接显示器的桌面 GPU 可能产生不同的 CDI 警告。

最值得持续关注的是驱动漂移。测试当天 RPM Fusion 比 NVIDIA 的 615 构建领先一个点版本，排除规则还没有真正发挥作用，因此无法观察 NVIDIA 仓库版本更领先时普通 dnf upgrade 的行为。排除项生效后，CUDA 仓库不再提供冲突包，理论上不会混装；仍应在每次 NVIDIA 驱动发布后执行 sudo dnf upgrade --assumeno，确认 nvidia 软件包来自 RPM Fusion 后再应用。

用一杯咖啡支持我们，我们的每一篇[文档]都经过实际操作和精心打磨，而不是简单地从网上复制粘贴。期间投入了大量心血，只为能够真正帮助到您。

CUDA Docker Fedora NVIDIA Podman

ZYF发表在Rocky Linux 9 从入门到精通002 — 系统安装
我在用ventoy工具引导安装Rocky…
木子发表在CentOS 7 迁移至 Rocky Linux 8.7 全过程
8 已经不再更新。可以看看日志看是否有报…
shingler发表在CentOS 7 迁移至 Rocky Linux 8.7 全过程
dnf -y --releasever=…
peter.liu发表在CentOS 7 迁移至 Rocky Linux 8.7 全过程
谢谢，参照此教程，花了两天时间，将一台旧…
keeper发表在在 Rocky Linux 9.x 上安装 Docker CE
感谢，刚接触docker，学到一些。7
木子发表在MySQL进阶15 — 复制技术
纯金点赞 👍👍👍
Bryan_S发表在MySQL基础04 — 配置文件
很赞，对于数据库小白而言，我有了基本的了…

登录管理

标签云

Fedora 上 CUDA 与容器的分层

开始前的硬件准备

从 RPM Fusion 安装 NVIDIA 驱动

在 Fedora 45 上使用 fedora44 CUDA 仓库

Error: “Status code: 404 …/cuda/repos/fedora45/x86_64/repodata/repomd.xml”

为什么保持 NVIDIA 驱动包于仓库之外

安装 cuda-toolkit 而不是 cuda

使用 nvcc 与 GCC 16 编译 CUDA 内核

安装 NVIDIA Container Toolkit 并生成 CDI 规格

在 rootless Podman 中运行 GPU 容器

在 SELinux enforcing 下修复 “Failed to initialize NVML: Insufficient Permissions”

Podman 其他常见错误

在 Docker 中使用 CDI 运行 GPU 容器

通过 Podman 让 Ollama 使用 GPU

尚待验证的环境

发送评论编辑评论

登 录 管 理

标 签 云

Fedora 上 CUDA 与容器的分层

开始前的硬件准备

从 RPM Fusion 安装 NVIDIA 驱动

在 Fedora 45 上使用 fedora44 CUDA 仓库

Error: “Status code: 404 …/cuda/repos/fedora45/x86_64/repodata/repomd.xml”

为什么保持 NVIDIA 驱动包于仓库之外

安装 cuda-toolkit 而不是 cuda

使用 nvcc 与 GCC 16 编译 CUDA 内核

安装 NVIDIA Container Toolkit 并生成 CDI 规格

在 rootless Podman 中运行 GPU 容器

在 SELinux enforcing 下修复 “Failed to initialize NVML: Insufficient Permissions”

Podman 其他常见错误

在 Docker 中使用 CDI 运行 GPU 容器

通过 Podman 让 Ollama 使用 GPU

尚待验证的环境

发送评论 编辑评论

推荐文章

登录管理

标签云

发送评论编辑评论