在启用 Secure Boot 的机器上安装 NVIDIA 驱动，如果没有注册签名密钥，内核模块就永远不会加载。akmod 构建完成了，nvidia-smi 仍会失败，内核日志报告密钥被拒绝，而 dnf 不会给出任何警告。对于 GTX 900、GTX 10 或 Volta 显卡还有第二个陷阱：当前驱动包已不支持这些 GPU，因此即使构建成功，生成的模块也无法被显卡使用。

本指南介绍如何从 RPM Fusion 在 Fedora 45 和 Fedora 44 上安装 NVIDIA 驱动、为 Secure Boot 注册 akmods 密钥，并处理 akmod-nvidia-580xx 旧卡分支。2026 年 11 月，我们在 Fedora 45 和 44 虚拟机上重新执行了安装与构建，并在 Fedora 45 上验证签名和旧卡切换；测试环境保持 Secure Boot enforcing，使用的软件包为 akmod-nvidia 615.78.08 和 akmod-nvidia-580xx 580.196.07。因此所有步骤都不需要关闭 Secure Boot。

NVIDIA 已在 upstream 发布 R620（620.70.06），但截至 11 月 4 日，RPM Fusion stable 与 testing 仓库仍提供 615 分支，因此 dnf 当前会安装 615。

如何为你的 GPU 选择 NVIDIA 驱动包

应根据 GPU 代际选择软件包，而不是照搬三年前论坛帖子中的命令。在 Fedora 45 上，RPM Fusion nonfree 提供四个驱动分支，每张显卡只应使用其中一种。

GPU 代际	示例显卡	软件包	构建的内核模块
Turing 及更新	GTX 16 系列、RTX 20 至 RTX 50、Tesla T4、A10G、L4	akmod-nvidia	Open
Maxwell、Pascal、Volta	GTX 750 Ti、GTX 900、GTX 10 系列、Titan V、Tesla V100、Quadro GV100	akmod-nvidia-580xx	在这些卡上为专有模块；Turing 及更新卡上为开放模块
Kepler	GTX 600、GTX 700（大部分）	akmod-nvidia-470xx	专有模块，仅支持 Xorg
Fermi	GTX 400、GTX 500	akmod-nvidia-390xx	专有模块，仅支持 Xorg

最容易在升级后出问题的就是 580xx 这一行。NVIDIA 在当前驱动源码中提供的 supported-gpus.json 内，将 615 源码里的 305 个条目标记为 "legacybranch": "580.xx"。GTX 980、GTX 980 Ti、GTX 1080（PCI ID 10de:1b80）和 Tesla V100 都在该列表中，这意味着当前驱动已不支持它们。Volta 也属于同一行：NVIDIA 的弃用计划将 580 标为 Maxwell、Pascal 和 Volta 的最后一个分支。

我们实际运行了当前分支和 580xx 包；470xx 与 390xx 仅按 RPM Fusion NVIDIA howto 记录，未在硬件上执行。RPM Fusion 只在当前稳定版 Xorg 服务器上支持这两个旧分支。其 howto 对 580xx 的说明同样如此，而且我们没有在 580xx 上测试 Wayland 桌面。390xx 已由 NVIDIA 结束支持，只以 best-effort 方式维护，新内核随时可能使其失效。Fedora Workstation 的 GNOME 会话仅使用 Wayland，因此应把 Fedora 45 上的 Kepler 或 Fermi 桌面视为不受支持。

GPU 的 PCI ID 与 Secure Boot 状态

后续所有步骤取决于两个事实：你使用哪张显卡，以及固件是否强制验证模块签名。系统需要是 Fedora 45 或 Fedora 44，具备 sudo 权限，并能访问 RPM Fusion 镜像。先安装 pciutils，再读取 GPU 的 PCI ID：

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

最后方括号中的 ID 就是驱动包用于匹配硬件的标识。实验中的十月 T4 GPU 主机显示为 10de:1eb8：

00:1e.0 3D controller [0302]: NVIDIA Corporation TU104GL [Tesla T4] [10de:1eb8] (rev a1)

现在检查 Secure Boot 是否启用。这一结果决定是否需要执行后面的密钥注册步骤：

mokutil --sb-state

两台十一月测试虚拟机都通过 OVMF 启动并注册了 Microsoft 密钥，输出均为：

SecureBoot enabled

继续之前，你的机器应满足以下条件：

• PCI ID 对应上表中的某一行，并且你知道该行指定的软件包；
• 你已确认 mokutil --sb-state 显示 enabled 还是 disabled；
• 启动时能够进入控制台，因为注册密钥需要在那里按一次键。

不要为了加载驱动而关闭 Secure Boot。注册一个密钥只多一次重启，还能让 shim、GRUB 和内核在操作系统启动前保持防篡改验证，并叠加内核锁定；实验中的 Fedora 45 虚拟机读取 /sys/kernel/security/lockdown 时显示 [integrity]。也要明确它不能阻止什么：akmods 私钥就在本机磁盘上，已经取得 root 权限的进程可以用它为自己的模块签名。这就是 RPM Fusion 将保护密钥列为强制要求的原因，下文会处理密钥保护。

RPM Fusion 与最新内核

驱动位于 RPM Fusion nonfree，该仓库同时需要 free 仓库。如果你已在 Fedora 上为多媒体编解码器启用两个仓库，即 dnf repolist | grep rpmfusion 同时列出 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

安装任何软件包前，先确认仓库实际提供的版本。该检查可判断 R620 是否已经进入仓库：

dnf list --available akmod-nvidia akmod-nvidia-580xx

Fedora 44 从 rpmfusion-nonfree-updates 显示相同的两个版本。Fedora 45 的当前分支和旧卡分支都来自 rpmfusion-nonfree：

随后完整更新系统，并在同一次操作中安装 akmods 工具。只有 Secure Boot 环境需要 mokutil 和 openssl，但保留它们没有坏处。在精简 Fedora 45 cloud 镜像上，这一步共安装 81 个软件包：

sudo dnf upgrade -y --refresh
sudo dnf install -y akmods mokutil openssl
sudo systemctl reboot

不要跳过重启。akmod 会针对已安装的最新 kernel-devel 构建；如果升级带来了新内核，模块会装给新内核，而当前运行内核仍然没有。我们有意在 Fedora 44 虚拟机上跳过重启：新内核已安装但未启动，驱动模块为该内核构建，modinfo 直到下次重启前都找不到当前内核的模块。重启还会让 akmods keygen 服务生成签名密钥，这发生在安装 akmods 后的首次启动。

Secure Boot 下的 akmods 签名密钥

Secure Boot enforcing 时，内核只加载由受信任密钥签名的模块。akmods 使用 /etc/pki/akmods/ 中的本机密钥签名每次构建的模块，因此该密钥必须一次性加入 MOK 列表。在 Fedora 45 虚拟机上，akmods-keygen@akmods-keygen.service 在启动时创建了以主机名命名的密钥，并通过 public_key.der 符号链接指向当前证书。该目录只允许 root 和 akmods 组读取，因此要用 sudo：

sudo ls -l /etc/pki/akmods/certs/

应看到一个证书和指向它的符号链接：

total 8
lrwxrwxrwx. 1 root akmods   55 Nov  4 16:18 public_key.der -> /etc/pki/akmods/certs/rpm-lab01_1793809105_98da2c08.der
-rw-r-----. 1 root akmods 1577 Nov  4 16:18 rpm-lab01_1793809105_98da2c08.der

如果目录为空，可用 sudo kmodgenca -a 手工生成密钥；这也是 RPM Fusion Secure Boot howto 给出的命令。私钥位于相邻的 /etc/pki/akmods/private/，任何能读取它的人，包括 root，都能签发固件信任的模块。RPM Fusion 建议加密根文件系统，以便关机时保护密钥；也可把密钥保存在外部存储或硬件令牌中。无论采用哪种方式，都应让 akmods 组中没有普通用户。先确认固件尚未信任该密钥：

sudo mokutil --test-key /etc/pki/akmods/certs/public_key.der

新密钥会报告尚未注册：

/etc/pki/akmods/certs/public_key.der is not enrolled

将密钥加入待注册队列。mokutil 会要求输入一次性密码两次；固件界面还要再输入一次，那里键盘固定为 QWERTY，因此密码应简短，非 QWERTY 布局下避免使用符号：

sudo mokutil --import /etc/pki/akmods/certs/public_key.der

以 root 身份检查待处理请求。普通用户运行 mokutil --list-new 不会输出且退出码为 0，看起来像导入失败，十一月测试机也出现了相同现象：

sudo mokutil --list-new | grep -E "^\[key|SHA1 Fingerprint|Subject:|Not After"

记下指纹，稍后与固件界面比较：

[key 1]
SHA1 Fingerprint: 0c:ca:e0:c2:d8:59:83:d7:a2:f0:68:cc:8f:5e:dd:5d:23:dc:32:96
            Not After : Nov  1 16:18:26 2036 GMT
        Subject: O=rpm-lab01, OU=rpm-lab01/emailAddress=akmods@rpm-lab01, L=None, ST=None, C=US, CN=rpm-lab01_1793809105_98da2c08

重启并留在控制台。Shim 在打开 MokManager 前会显示短暂的“Press any key”倒计时，错过并非无害。十一月测试机倒计时结束时，启动继续且请求消失，mokutil --test-key 再次显示未注册，只能重新导入。以下 MokManager 截图来自十月 Secure Boot 测试机，那次成功按键进入：

• 倒计时期间按任意键，然后选择 Enroll MOK；
• 选择 View key 0，将 Fingerprint 与 mokutil --list-new 的输出比较；
• 按 Enter 返回，选择 Continue，在“Enroll the key(s)?”处回答 Yes 并输入密码；
• 选择 Reboot。

第一张图是 MokManager 菜单，待处理请求位于 Enroll MOK 后面：

不要跳过 View key 0。这是确认即将信任的密钥确由 akmods 生成的唯一环节。下图的 Fingerprint 属于十月测试机，并与该机自身的 mokutil 输出一致；你的指纹必须与自己的输出一致，而不是与本文示例一致：

回到十月测试机的 Fedora 后，密钥已在 MOK 列表，内核在启动时成功加载：

该虚拟机没有 GPU，因此 modprobe 仍会失败，报 could not insert 'nvidia': No such device，dmesg 记录 NVRM: No NVIDIA GPU found.。这一对信息反而证明签名已通过：内核接受了模块，随后驱动去查找硬件。RPM Fusion 建议先注册密钥再安装 kmod，本文也按该顺序执行。我们曾先构建驱动再注册密钥，已有模块无需重建即可加载，因为它已经用同一密钥签名。固件升级可能清空 MOK 列表；如果升级后驱动不再加载，重新执行相同的 mokutil --import。

安装 NVIDIA 驱动并等待 kmod 构建

对于 Turing 或更新的 GPU，安装 akmod 和 CUDA 用户态库。-cuda 包也包含 nvidia-smi。GTX 900、GTX 10 和 Volta 用户应直接使用后面的 580xx 章节。如果驱动是作为其他软件包的依赖被安装，随后运行 sudo dnf mark user akmod-nvidia，否则未来的 dnf autoremove 可能连同编译器一起移除 akmod。

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

安装数量取决于现有环境。以下是两台十一月测试虚拟机的情况，二者都是已安装 akmods 的精简 cloud 镜像：

• Fedora 45 安装 244 个软件包，dnf 用时 3 分 6 秒；
• Fedora 44 安装 281 个软件包，dnf 用时 3 分钟；
• 两者都拉取了编译工具链、kernel-devel 和一批 Workstation 通常已有的桌面库。

dnf 返回时内核模块可能还不存在。akmod 会在后台构建，如果此时重启，下次启动的内核仍没有模块；由于 nouveau 已加入黑名单，构建完成前 GPU 完全没有驱动。使用循环等待最新已安装内核的模块，也能覆盖安装期间拉入新内核的情况：

K=$(rpm -q --qf "%{VERSION}-%{RELEASE}.%{ARCH}\n" kernel-core | sort -V | tail -1); until modinfo -k $K nvidia >/dev/null 2>&1; do sleep 5; done; date +%T; echo $K; modinfo -k $K -F version nvidia; modinfo -k $K -F license nvidia; ls /var/cache/akmods/nvidia/

在 4 vCPU 的 Fedora 45 虚拟机上，dnf 返回 76 秒后模块已存在。构建日志和生成的 kmod RPM 位于 /var/cache/akmods/nvidia/，日志会记录构建的是哪一种模块。截图中是我们最初运行等待循环的结果，带有 echo newest= 标签和普通 modinfo 输出；当最新内核就是当前内核时，两种写法结果相同：

RPM Fusion 给出的正常构建上限是五分钟。如果循环远超此时仍未结束，构建已经失败，日志位于 /var/cache/akmods/。安装完成后，两个 Fedora 版本的启动参数都会黑名单内核自带驱动：nouveau，以及面向较新 NVIDIA GPU 的 Rust 驱动 nova_core：

sudo grubby --info=DEFAULT | grep ^args

两个名称各出现两次，一次用于 initramfs，一次用于运行系统：

args="ro rootflags=subvol=root no_timer_check console=tty1 console=ttyS0,115200n8 systemd.firstboot=off rootflags=subvol=root rd.driver.blacklist=nouveau,nova_core modprobe.blacklist=nouveau,nova_core"

如果密钥尚未注册，此时会暴露问题。十一月测试机导入仍待完成时，sudo modprobe nvidia 在签名检查处报“Key was rejected by service”，文末错误章节会介绍修复方法。

验证驱动与 CUDA 可用

模块出现后重启一次，因为运行中的内核只会在下次启动时加载新模块并应用黑名单。

sudo systemctl reboot

十一月测试虚拟机没有 GPU，因此本节输出来自十月 Tesla T4 云主机和上一版 615 构建；它仍属于 RPM Fusion 当前提供的分支。重启后，nvidia、nvidia_modeset、nvidia_drm 和 nvidia_uvm 应已加载，nouveau 未加载，nvidia-smi 能识别 GPU：

615 分支改变了表头，现在显示 KMD Version 和 CUDA UMD Version，而 580xx 仍显示 Driver Version 和 CUDA Version。依赖旧标签的脚本需要更新。

nvidia-smi 正常不能证明 CUDA 可用。无需安装 CUDA toolkit，运行一个直接调用 CUDA 驱动 API 的简短 Python 脚本即可验证。创建：

vim ~/cuda-check.py

粘贴以下内容。它会在每个 GPU 上创建上下文并分配 256 MiB 显存：

import ctypes
cuda = ctypes.CDLL("libcuda.so.1")
assert cuda.cuInit(0) == 0
n = ctypes.c_int(); cuda.cuDeviceGetCount(ctypes.byref(n))
v = ctypes.c_int(); cuda.cuDriverGetVersion(ctypes.byref(v))
print(f"CUDA driver API {v.value // 1000}.{(v.value % 1000) // 10}, devices: {n.value}")
for i in range(n.value):
    dev = ctypes.c_int(); cuda.cuDeviceGet(ctypes.byref(dev), i)
    name = ctypes.create_string_buffer(100); cuda.cuDeviceGetName(name, 100, dev)
    mem = ctypes.c_size_t(); cuda.cuDeviceTotalMem_v2(ctypes.byref(mem), dev)
    ma, mi = ctypes.c_int(), ctypes.c_int()
    cuda.cuDeviceGetAttribute(ctypes.byref(ma), 75, dev); cuda.cuDeviceGetAttribute(ctypes.byref(mi), 76, dev)
    ctx = ctypes.c_void_p(); rc = cuda.cuCtxCreate_v2(ctypes.byref(ctx), 0, dev)
    free, total = ctypes.c_size_t(), ctypes.c_size_t(); cuda.cuMemGetInfo_v2(ctypes.byref(free), ctypes.byref(total))
    ptr = ctypes.c_uint64(); arc = cuda.cuMemAlloc_v2(ctypes.byref(ptr), 256 * 1024 * 1024)
    print(f"GPU {i}: {name.value.decode()}, compute {ma.value}.{mi.value}, {mem.value // 2**20} MiB, context rc={rc}, 256 MiB alloc rc={arc}")
    cuda.cuMemFree_v2(ptr); cuda.cuCtxDestroy_v2(ctx)

以普通用户运行，不要用 root，这样 /dev/nvidia* 的权限问题会在此暴露，而不是在第一个真实任务中才发现。

python3 ~/cuda-check.py

两个返回码都必须为 0，因为上下文和内存分配是所有 CUDA 程序最先执行的操作。否则说明用户态库与内核模块不一致，请先用 rpm -qa "*nvidia*" 确认 -cuda-libs 包与 kmod 来自同一分支，再排查显卡。

CUDA driver API 13.4, devices: 1
GPU 0: Tesla T4, compute 7.5, 14927 MiB, context rc=0, 256 MiB alloc rc=0

自带 CUDA runtime 的工具，例如 PyTorch 的 pip wheel，只需此驱动。编译 CUDA 代码还需额外安装 NVIDIA toolkit。长期运行的 GPU 主机应接入 DCGM、Prometheus 与 Grafana 监控。nvidia-persistenced 已安装但默认禁用；在无头计算节点上，若希望任务之间保持 GPU 初始化，可运行 sudo systemctl enable --now nvidia-persistenced。

实验 GPU 主机是无显示输出的数据中心显卡无头云实例，因此没有测试 GNOME 或 KDE 会话。实际验证的是内核模块、nvidia-smi 和上述 CUDA 路径。

开放或专有内核模块：akmod 如何选择

安装时不能选择模块类型。RPM Fusion 的 kmod spec 同时包含 kernel 与 kernel-open 源码树，并在构建时运行检测脚本。脚本读取 lspci，将所有 NVIDIA PCI ID 与开放模块不支持的 GPU 列表比较：匹配则构建专有模块，否则构建开放模块。构建后检查自己的机器：

grep -E "Runtime detection|matching graphics|Using nvidia-open|Not using" /var/cache/akmods/nvidia/*.log | tail -3

Fedora 45 虚拟机没有 NVIDIA 显卡，因此没有匹配项，最终选择开放模块；十月 T4 的结果相同：

2026/11/04 16:23:09 akmodsbuild: Runtime detection of kmod_nvidia_open
2026/11/04 16:23:09 akmodsbuild: No matching graphics card found.
2026/11/04 16:23:09 akmodsbuild: Using nvidia-open

modinfo -F license nvidia 可快速确认：开放模块报告 Dual MIT/GPL。十月之后有一项打包变化：当前 akmod-nvidia 过去携带空的排除列表，而十一月构建携带 160 个 PCI ID；我们在源码 RPM 中计数，内容与 akmod-nvidia-580xx 中的文件逐字节相同，其中包括 GTX 1080 的 10de:1b80 和 Tesla V100 的 10de:1db4。因此，GTX 1080 使用当前包时现在会得到专有模块，而不是开放模块。但这不能恢复显卡支持：615 驱动仍将它列在 580 旧卡分支下，所以最终方案仍是 580xx 包。模块类型只在构建时决定一次；更换 GPU 或迁移主机后，旧的模块类型会一直保留到运行 sudo akmods --rebuild。

面向 GTX 900、GTX 10 和 Volta 的 580xx 旧卡驱动

在干净系统上，直接安装旧卡分支，而不是当前驱动：

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

使用相同的最新内核等待循环。只有缓存目录不同，因为 580xx akmod 将日志单独存放：

K=$(rpm -q --qf "%{VERSION}-%{RELEASE}.%{ARCH}\n" kernel-core | sort -V | tail -1); until modinfo -k $K nvidia >/dev/null 2>&1; do sleep 5; done; date +%T; echo $K; modinfo -k $K -F version nvidia; modinfo -k $K -F license nvidia; ls /var/cache/akmods/nvidia-580xx/

Fedora 45 虚拟机上安装包含 224 个软件包，dnf 完成后 66 秒循环返回，580xx kmod 已为运行内核构建：

16:33:34
7.2.15-300.fc45.x86_64
580.196.07
Dual MIT/GPL
580.196.07-1-for-7.2.15-300.fc45.x86_64.log
kmod-nvidia-580xx-7.2.15-300.fc45.x86_64-580.196.07-1.fc45.x86_64.rpm

返回后再重启。如果已按旧指南安装当前驱动，特别是 GTX 1080 用户，现在可用一条命令切换。十月时 --allowerasing 会保留另一分支的 -libs 包，RPM 事务因文件冲突失败；使用十一月软件包时，事务计划安装 8 个、删除 8 个，删除两个 -libs 包，并以零冲突完成：

sudo dnf install -y --allowerasing akmod-nvidia-580xx xorg-x11-drv-nvidia-580xx-cuda

同一事务会移除当前内核的 615 kmod，因此必须先等待上方的 580xx 构建循环完成再重启，否则下次启动没有任何 NVIDIA 模块。新模块由同一 akmods 密钥签名，已注册的机器无需再次进入 MokManager。会留下一个软件包：

删除这个孤立的源码包，因为之后已没有构建依赖它：

sudo dnf remove xorg-x11-drv-nvidia-kmodsrc

切换后检查以下项目：

• rpm -q akmod-nvidia 报告未安装，只剩 akmod-nvidia-580xx；
• modinfo -F signer nvidia 显示的 akmods 密钥名称与切换前相同；
• 删除旧的 xorg-x11-drv-nvidia-kmodsrc 后，dnf repoquery --installed --unneeded | grep -i nvidia 无输出；
• nvidia-modprobe 和 nvidia-persistenced 仍保持 615 构建，这是正常的，因为 580xx 分支与它们共用。

若想从零开始，RPM Fusion 记录的 glob 仍有效：sudo dnf remove "xorg-x11-drv-nvidia*" 在虚拟机上删除 225 个包；这是在切换后移除 580xx 栈时测试的，而 akmods 与 kernel-devel 会保留。随后安装 580xx 又会装回 224 个。不要把模式扩大为 "*nvidia*"：该模式还会匹配 Workstation 安装的 nvidia-gpu-firmware，它是 nouveau 和 nova_core 使用的固件；RPM Fusion howto 警告，使用其他删除范围会移除自由驱动仍需要的包。

此前在 Fedora 44 GPU 主机上的切换还揭示了一点：T4 上 580xx 构建了开放模块，CUDA 报告的驱动 API 为 13.0，而非 13.4。真正的 Pascal 或 Volta 显卡会被检测脚本根据排除列表选择专有模块；本实验没有相应硬件可供验证。

内核升级时会发生什么

akmods.service 默认启用并在每次启动时运行。它检查当前启动内核是否已有 kmod，缺失时构建。没有任何变化的启动约一秒完成：

sudo journalctl -b -u akmods --no-pager | tail -3

Fedora 45 虚拟机安装驱动并重启后的日志显示，检查在服务启动的同一秒通过：

Nov 04 16:23:54 rpm-lab01 systemd[1]: Starting akmods.service - Builds and install new kmods from akmod packages...
Nov 04 16:23:54 rpm-lab01 akmods[700]: Checking kmods exist for 7.2.15-300.fc45.x86_64 [  OK  ]
Nov 04 16:23:54 rpm-lab01 systemd[1]: Finished akmods.service - Builds and install new kmods from akmod packages.

安装 akmod 时会为最新已安装内核构建，之后到达的内核会在首次启动时由 akmods.service 构建 kmod。风险是构建成功但模块损坏，或者构建失败。这里的 --force 与多数人的预期不同：它只重试先前失败的构建，在正常系统上只打印“Checking kmods exist”。要真正为运行内核重新编译，应使用 --rebuild：

time sudo akmods --rebuild --kernels $(uname -r)

在 4 vCPU 上，模块重新构建并安装耗时 2 分 8 秒：

Checking kmods exist for 7.2.15-300.fc45.x86_64 [  OK  ]
Building and installing nvidia-kmod [  OK  ]

real    2m8.517s
user    5m2.454s
sys 0m54.021s

至少保留一个旧内核，Fedora 默认保留三个，确保构建失败时仍有可启动回退。发行版升级也会替换内核，因此在迁移 GPU 工作站前应先规划升级路径和回退。

实验中的驱动错误及对应修复

以下问题均在测试机上出现，只有 nouveau fallback 消息来自其 unit 文件。应用修复前应匹配确切的错误文本。

modprobe: ERROR: could not insert ‘nvidia’: Key was rejected by service

Secure Boot 已启用，但 akmods 密钥尚未注册。模块已签名，然而签名密钥从未被固件见过，dmesg 会追加“Loading of module with unavailable key is rejected”。我们在十一月测试机上、导入请求仍待处理时复现了该问题：

signer 字段与 akmods 密钥名称一致，说明构建本身正常。完成 MokManager 注册并重启即可。无需重建模块，因为现有签名所用的密钥会被固件学习并信任。

modinfo: ERROR: Module nvidia not found

如果刚执行完 dnf，这通常表示 akmod 仍在后台构建，应使用等待循环。如果持续存在，比较 uname -r 与 rpm -q kernel-devel。Fedora 44 测试机安装了新内核但尚未启动，模块只存在于新内核下：

如果版本字符串来自最新内核，说明模块正在等待该内核。重启进入新内核后错误会消失，无需重建。如果最新内核仍报告同样错误，则构建失败，应查看 /var/cache/akmods/nvidia/ 中的日志。

NVIDIA kernel module missing. Falling back to nouveau

该消息来自 xorg-x11-drv-nvidia 提供的 nvidia-fallback.service。只有当内核命令行将 nouveau 加入黑名单，且 nvidia 模块未加载时才会运行：

systemctl cat nvidia-fallback.service

该 unit 会加载 nouveau 并把消息打印到启动画面。下面仅保留 unit 本身的输出：

# /usr/lib/systemd/system/nvidia-fallback.service
[Unit]
Description=Fallback to nouveau as nvidia did not load
After=akmods.service
Before=display-manager.service
ConditionKernelCommandLine=rd.driver.blacklist=nouveau,nova_core
ConditionPathExists=!/sys/module/nvidia

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=-/sbin/modprobe nouveau
ExecStartPost=-/bin/plymouth message --text="NVIDIA kernel module missing. Falling back to nouveau"

[Install]
WantedBy=graphical.target

它只是症状，不是原因。已知三类原因包括：密钥未注册、构建完成前重启，以及在当前 akmod-nvidia 上使用 GTX 900、GTX 10 或 Volta、实际需要 580xx 分支。内核日志会指出具体问题：

sudo dmesg | grep -iE "nvidia|NVRM|rejected"

十一月测试机和此前的 GPU 主机都禁用了该 unit。因此在默认安装中，加载失败通常会让 GPU 完全没有驱动，而不显示这条消息。本文的结论来自 unit 定义和状态，实验室中没有 GPU 主机发生过该加载失败。

mokutil –list-new 导入后没有任何输出

必须使用 sudo。普通用户运行不会输出且退出码为 0，这使第一次导入看起来像失败，实际请求已排队。sudo mokutil --test-key 可判断状态：“already in the enrollment request”表示重启并进入 MokManager；“not enrolled”出现在重启之后，则表示倒计时已错过，需要重新导入。

如果显卡用于游戏，后续需在相同驱动上处理 Steam、Proton、NTSYNC 与 MangoHud。对于新 Workstation 的其他配置，需要在驱动完成后继续处理桌面、多媒体和日常维护。如果机器上仍有旧的 .run 安装器，应先按 NVIDIA 手工驱动卸载步骤清理，再安装 RPM Fusion 包。