nvidia-smi 失效排查
一次 nvidia-smi 失效排查:自动升级后的 Driver/library version mismatch
2026 年 5 月 28 日,我们排查了一台 Ubuntu GPU 服务器上 nvidia-smi 无法查看 GPU 的问题。表面现象很简单:
$ nvidia-smi
Failed to initialize NVML: Driver/library version mismatch
NVML library version: 535.309
这类报错通常不是 GPU 硬件坏了,而是 NVIDIA 用户态库和内核模块版本不一致。
现场现象
服务器上,nvidia-smi 已安装在 /usr/bin/nvidia-smi,但执行失败。进一步检查发现:
当前内核中已加载的 NVIDIA 模块: 535.288.01
磁盘上的 DKMS NVIDIA 模块: 535.309.01
用户态 NVML 库版本: 535.309
也就是说,系统上的 NVIDIA 包已经升级到了 535.309.01,但内核里仍然运行着旧的 535.288.01 模块。
服务器运行时间也很能说明问题:
up 110 days
System restart required
什么时候发生的?
查看 /var/log/apt/history.log 和 /var/log/dpkg.log 后,时间线非常明确:
2026-05-22 06:10:33
Commandline: /usr/bin/unattended-upgrade
nvidia-driver-535: 535.288.01 -> 535.309.01
nvidia-dkms-535: 535.288.01 -> 535.309.01
nvidia-utils-535: 535.288.01 -> 535.309.01
也就是说,2026 年 5 月 22 日清晨,系统通过 Ubuntu 的 unattended-upgrade 自动升级了 NVIDIA 驱动相关包。
为什么升级后会坏?
NVIDIA 驱动由两部分组成:
- 用户态库,例如
libnvidia-ml.so,nvidia-smi会调用它; - 内核模块,例如
nvidia.ko,它在内核中实际驱动 GPU。
自动升级会替换磁盘上的用户态库和 DKMS 模块,但已经加载进内核的旧模块不会自动变成新版本。于是出现了这样的状态:
nvidia-smi / NVML: 535.309.01
kernel module: 535.288.01
版本不一致时,NVML 初始化失败,就会报:
Driver/library version mismatch
这是个普遍问题吗?
Ubuntu 的自动安全升级机制本身很普遍。官方文档说明,unattended-upgrades 用于自动安装安全更新,并可根据配置更新指定来源的软件包。
这台服务器上的配置也启用了每日自动升级:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
NVIDIA 535.309.01 也确实已经进入 Ubuntu Jammy 的 security/restricted 和 updates/restricted 仓库。因此,类似配置的 Ubuntu 22.04 GPU 服务器都有可能自动升级到该版本。
但这并不意味着“全世界所有机器同一天升级”。是否升级取决于系统版本、仓库源、是否启用 unattended-upgrades、是否锁定驱动版本,以及机器是否在线运行了 apt 定时任务。
如何修复?
最稳妥的修复方式是安排维护窗口重启:
sudo reboot
重启后验证:
nvidia-smi
cat /proc/driver/nvidia/version
预期用户态库和内核模块都会变成 535.309.01,nvidia-smi 恢复正常。
不建议在多人共享 GPU 服务器上随意热卸载 NVIDIA 模块,因为可能影响图形会话、CUDA 任务或其他用户进程。重启虽然朴素,但最干净。
如何避免再次发生?
GPU 服务器上建议考虑以下策略:
sudo apt-mark hold nvidia-driver-535 nvidia-dkms-535 nvidia-utils-535 libnvidia-compute-535
或者在 /etc/apt/apt.conf.d/50unattended-upgrades 中将 NVIDIA 相关包加入黑名单,例如:
Unattended-Upgrade::Package-Blacklist {
"nvidia-.*";
"libnvidia-.*";
};
更稳健的方式是:允许安全更新,但对 GPU 驱动这类强依赖内核模块的包设置维护窗口,在升级后立刻重启验证。
参考
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐


所有评论(0)