NVIDIA 的 DKMS 模块在 PVE (Proxmox VE) 6.17 内核上编译失败了,导致每次重启后显卡驱动都会消失。
在此记录下排查和修复的完整过程。
1. 现象与报错分析
在安装或更新 NVIDIA 驱动时,你可能会注意到最关键的几行报错:
| |
这说明安装脚本已经开始给 6.17.x 的 Proxmox 内核编译模块,但 make 直接失败了,所以 dpkg 后面才报错退出。日志里有时出现的 sign-file、mok.key 只是 DKMS 的签名流程准备信息,不代表 Secure Boot 在拦截;真正失败点发生在编译阶段。
进一步检查版本发现,当前环境的包是 nvidia-kernel-dkms 550.163.01-2。根据 Debian 官方包信息显示:
trixie稳定版里的nvidia-kernel-dkms确实是550.163.01-2- 而
trixie-backports里有更新的550.163.01-4~bpo13+1
官方变更记录(Changelog)里明确写了:550.163.01-4 回移了修复,用来解决 Linux 6.17 上的内核模块构建失败问题。
2. 根因总结
现在最可能的根因就是:550.163.01-2 太旧,不适配你现在的 6.17 PVE 内核。这也和 Debian 的相关 bug 记录一致:6.17 的模块构建问题后来被修复并合并到了更新版本里。
解决这个问题最直接的做法,就是升级到 backports 里的 NVIDIA DKMS 包。
3. 修复方案
如果你的宿主机是 Proxmox 9 / Debian trixie,请优先使用以下修复方案。
1)先把 PVE 宿主机固定到 550.163.01 修复版
首先,确认当前内核头文件也在:
| |
然后,启用 backports 并升级 NVIDIA 包:
| |
原理解释:Debian 官方已经在 backports 提供了
550.163.01-4~bpo13+1,而这版的变更说明里明确包含了“修复 Linux 6.17 构建”。 详情参考:Debian Tracker News
升级完成后,验证状态:
| |
如果看到装上的版本确实是 550.163.01-4~bpo13+1,就把宿主机上的 NVIDIA 包全部锁死 (hold),防止其自动更新被回退或覆盖:
| |
检查是否成功锁定:
| |
2)Ubuntu 24 LXC 容器内配置策略
如果你的显卡透传给 LXC 容器使用,请务必记住:LXC 里不要装 DKMS,只装 550.163.01 的用户态依赖。
宿主机和 LXC 的 Debian/Ubuntu 包修订号不需要完全一样。PVE 可能是 550.163.01-4~bpo13+1,Ubuntu 24 里则是 550.163.01-0ubuntu0.24.04.1 或 .2;你真正要对齐的是 NVIDIA upstream 的主体版本号 550.163.01。
由于 Ubuntu 针对 550 系列发布过多种 transitionals 指向更新分支,不要依赖 ubuntu-drivers install 自动选版本,直接用精确版本安装更稳。
进 LXC 后,先看镜像里现在还能拿到哪个 Ubuntu 修订号:
| |
如果这个 LXC 是做 CUDA / ffmpeg / transcoding / 推理,优先走 -server 用户态。常见最小装法是从 nvidia-utils-550-server 开始,再按程序需要补同版本的 compute 包:
| |
绝对不要在 LXC 里装这些包:
nvidia-dkms-*linux-modules-nvidia-*nvidia-kernel-*
因为那是宿主机内核模块这一层的事情,LXC 自己不该再编一遍。这个结论来自于“系统容器 (system container) 共享宿主机内核”这一根本前提。
装完以后,同样把 LXC 里的 NVIDIA 包也锁死:
| |