NVIDI掉驱动修复

声明
为和GLM-5.1对话debug的记录总结而来
以下为GLM-5.1总结原文，GLM总结的好颠啊哈哈哈

深度学习服务器修仙指南：断电/重启后 NVIDIA 驱动离线终极排查与修复

对于跑在内网环境下的深度学习服务器来说，最怕的不是代码 Bug，而是“意外断电重启后，nvidia-smi 罢工，CUDA 找不到显卡”。
最近，由于机房供电不稳和内核自动更新，我连续遭遇了三起不同表现的 NVIDIA 驱动离线事故。本文将这三次“灾难”复盘，总结出一套从现象匹配、根因定位到彻底修复的标准流程，并补充了深度学习服务器必须做的防御性配置。

---

1. 问题描述：三大经典“翻车”现场

遇到以下三种情况，说明你的驱动和内核已经“失联”或“打架”了：

• 症状 A（模块丢失）： nvidia-smi 报错 NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver.；系统日志（dmesg 或 journalctl）出现 modprobe: FATAL: Module nvidia not found in directory /lib/modules/6.8.0-111-generic。
• 症状 B（版本打架）： 系统日志出现 NVRM: API mismatch: the client has the version 535.309.01, but this kernel module has the version 535.288.01.。表现往往是开机能用，过半天突然不能用了。
• 症状 C（DKMS 编译失败）： 使用 apt 重装驱动时，DKMS 报错 Bad return status for module build on kernel，或者编译日志中出现 unrecognized command-line option ‘-ftrivial-auto-var-init=zero’。
  万恶之源： 99% 的原因是系统后台自动升级了 Linux 内核，而 NVIDIA 闭源驱动的内核模块没有跟着重新编译。意外断电只是强迫你重启，让你“恰好”进入了没有驱动的新内核。

---

2. 环境检查：定位问题的三把斧

在动手修复前，先搞清楚系统到底发生了什么。

2.1 查询内核升级日志（寻找案发时间）

检查是不是内核偷偷升级了：

grep -E "linux-image-$(uname -r)|linux-headers-$(uname -r)" /var/log/dpkg.log

如果输出显示安装时间在你重启/断电之前，实锤了：内核升级导致驱动未编译。

2.2 判断驱动安装方式（决定修复路线）

# 检查是否是官方 run 文件安装
ls -l /var/log/nvidia-installer.log
# 如果文件存在，说明是用 .run 包安装的
# 检查 apt 包状态
dpkg -l | grep nvidia-driver
# 注意看状态标识：如果是 'ii' 表示正常安装；如果是 'iU' 表示未正确配置（断电导致损坏）

2.3 检查内核模块物理是否存在

find /lib/modules/$(uname -r) -name "nvidia*.ko*"

如果只找到 nvidiafb.ko 等开源模块，找不到核心的 nvidia.ko，说明当前内核下完全没有驱动。

3. 修复方案一：官方 .run 文件重装（适用症状 A）

如果确认是 .run 包安装，且内核模块丢失，必须重新执行 run 包让其为当前内核编译驱动。
操作步骤：

1. 找到之前下载的 .run 文件（如 NVIDIA-Linux-x86_64-535.xx.run）。
2. 关键参数： 必须加上 --dkms，这样以后内核更新时，系统才能自动重新编译驱动，避免再次掉坑。

   chmod +x NVIDIA-Linux-*.run
   sudo sh NVIDIA-Linux-*.run --dkms

3. 重启系统：sudo reboot。

---

4. 修复方案二：APT 包管理器重装（适用症状 B）

如果是通过 apt 安装的驱动，出现 API mismatch（版本不一致），通常是用户态库升级了，但内核态模块没升级。
操作步骤：

# 重新安装驱动包，强制触发 DKMS 为当前内核编译
sudo apt install --reinstall nvidia-driver-535 # 替换为你的版本
sudo reboot

4.1 填坑指南：APT 状态损坏（断电后遗症）

如果执行上述命令报错 E: Internal Error, No file name for nvidia-driver...，且 dpkg -l 显示状态为 iU，说明断电打断了 apt 的升级过程，包管理器卡死了。
修复方法：

# 1. 强制配置未完成的包
sudo dpkg --configure -a
# 2. 修复破损的依赖
sudo apt --fix-broken install
# 3. 如果依然报错，手动清理崩溃残留（报错 Errno 17 File exists 时）
sudo rm /var/crash/nvidia-kernel-source-*.crash
# 4. 如果 dpkg 彻底卡死，强制剔除错误记录（终极手段）
sudo dpkg --remove --force-remove-reinstreq nvidia-driver-535
sudo apt --fix-broken install

完成包管理器修复后，再执行正常的重装命令。

5. 修复方案三：升级 GCC 编译器（适用症状 C）

在 Ubuntu 22.04 上，如果内核升级到了 6.8.x，使用 DKMS 编译 535 等老版本驱动时，极大概率会遇到这个报错：
cc: error: unrecognized command-line option ‘-ftrivial-auto-var-init=zero’
原因： 6.8 内核为了安全，强制开启了变量自动初始化选项，该选项需要 GCC 12 支持。而 Ubuntu 22.04 默认的 GCC 是 11，导致编译器“看不懂”内核的编译指令。
解决方法 A：升级 GCC（必须死磕老驱动时使用）

sudo apt install gcc-12 g++-12
# 将 GCC 12 设为系统默认编译器
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-12 100 --slave /usr/bin/g++ g++ /usr/bin/g++-12
# 然后重新执行 dpkg --configure -a 或 apt reinstall

解决方法 B：直接升级驱动大版本（强烈推荐，一劳永逸）
对于深度学习环境，将驱动从 535 升级到 550 完全不影响现有的 CUDA 程序，反而能省去折腾 GCC 的麻烦。

sudo apt purge nvidia-\* nvidia-driver-535
sudo apt autoremove
sudo ubuntu-drivers autoinstall # 自动安装适配 6.8 内核的新版驱动
sudo reboot

---

6. 深入理解 DKMS：防止再次发病的疫苗

DKMS (Dynamic Kernel Module Support) 是 Linux 的一个框架。NVIDIA 闭源驱动是内核模块，每次内核更新，模块就得重新编译。如果没有 DKMS，你只要一更新内核重启，显卡就会罢工。

6.1 安装与依赖

无论用哪种方式装驱动，务必确保 DKMS 和当前内核的头文件已安装：

sudo apt install dkms build-essential linux-headers-$(uname -r)

6.2 状态确认

装完驱动后，检查 DKMS 是否成功注册并编译了模块：

sudo dkms status

正常输出应该包含： nvidia/535.xxx, 6.8.0-111-generic, x86_64: installed
如果显示 added 但没有 installed，说明编译失败了，需要查日志。

---

7. 终极防御：锁定内核版本

深度学习服务器追求的是极致的稳定。内核更新带来的微小性能提升，远比不上驱动崩溃导致训练中断的损失。因此，关闭内核的自动更新是内网服务器的标准操作。
使用 apt-mark hold 将内核版本“钉死”：

# 锁定当前内核镜像和头文件（替换为你的 uname -r 输出）
sudo apt-mark hold linux-image-generic linux-image-6.8.0-111-generic
sudo apt-mark hold linux-headers-generic linux-headers-6.8.0-111-generic
# 查看已锁定的包
apt-mark showhold

这样系统在执行 apt upgrade 时，会自动跳过内核更新。未来如果确实需要升级内核，只需用 sudo apt-mark unhold 解锁即可。

8. 补充章节：深度学习服务器最佳实践

除了锁定内核，以下操作也能大幅提升服务器的“存活率”：

1. 关闭图形界面 (GDM)： 跑训练的服务器不需要桌面环境。桌面环境不仅占用显存，还容易在驱动状态波动时卡死。sudo systemctl disable gdm，全靠 SSH 管理。
2. 禁用休眠与睡眠： 防止内网机器因闲置自动休眠导致 SSH 断开、训练终止。

   sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

3. 定期备份重要配置： /etc/modprobe.d/ 下的黑名单配置、/etc/environment 里的 CUDA 环境变量等，建议定期快照备份。
   总结： 意外断电只是压垮骆驼的最后一根稻草，内核与驱动的版本不匹配才是真正的病因。掌握 DKMS 机制、确保编译环境 (GCC/Headers) 完整、并果断锁定内核，是让炼丹炉长久稳定运行的不二法门。