装显卡驱动这件事，在 Linux 圈子里属于那种"看起来十分钟搞定、实际能耗掉一整个下午"的活。我见过不少人是这么开始的：照着某篇帖子敲了一行命令，重启，然后屏幕黑掉，接着开始怀疑人生。也见过另一种极端：驱动装上了，nvidia-smi能出表格，但一跑图形界面就花屏，一跑计算任务就报版本不匹配。问题不在于命令本身有多难，而在于大多数教程只告诉你"敲什么"，不告诉你"为什么敲这个"、更不告诉你"敲错了怎么退回来"。
这篇东西想解决的就是这个断层。它适合三类人：第一类是刚在一台新机器上装完 Linux、桌面还在用核显跑、想把独显真正用起来的；第二类是接了计算任务、需要让显卡跑起来但不确定该用哪条安装路线的；第三类是装过一两次、出过一两次事、想把整个过程和回滚预案彻底搞明白的。全文会围绕驱动方案怎么选、系统要提前准备什么、两条主流安装路线各自怎么落地、装完怎么调优、出事怎么排查这五件事展开，中间会穿插我自己踩过的坑和一些别人不太爱写的细节，比如内核升级之后驱动为什么突然失效、安全启动为什么会让模块加载失败、笔记本双显卡的正确用法。
核心关键词：Linux 显卡驱动、驱动安装、内核模块、DKMS、CUDA、显示服务器、安全启动。这几个词后面会反复出现，弄懂它们之间的关系，整个流程就不会再是"玄学"。
1. 动手之前，先把这台机器的底细摸清楚
很多人第一步就直接敲安装命令，这是最容易翻车的起点。驱动不是一个通用的、装上去就配所有显卡的软件，它跟具体的显卡代号、内核版本、发行版仓库策略、显示服务器协议都有强绑定关系。这四样东西里有一样没对齐，后面就会以黑屏、循环登录、分辨率锁死、模块加载失败的形式还给你。
所以真正规范的做法是：在安装任何包之前，先用五条命令把机器的身份信息采集完整，存到一个文本文件里，后面排查问题的时候直接用得上。
1.1 显卡型号要看总线，别信包装盒
判断显卡型号最可靠的方式是查 PCI 总线，而不是看机器外壳上印的型号或者买的时候的订单。因为同一台机器可能插过不同的卡，笔记本的独显和核显也经常被用户搞混。
lspci -nn | grep -Ei 'vga|3d|display'输出长这样：
01:00.0 VGA compatible controller [0300]: Vendor Device [10de:2504] (rev a1) 00:02.0 VGA compatible controller [0300]: Vendor Device [8086:46a6] (rev 0c)方括号里那组10de:2504是关键。前半段是厂商 ID，10de对应的是我们要装驱动的那家厂商；后半段是设备 ID，代表具体型号。把这个十六进制串拿去查官方的支持列表，能精确对上显卡代号和需要的最低驱动分支。这比任何"我看网上说要装 550"的说法都靠谱。
顺带说一句，如果你看到两个 VGA 设备，基本可以确定是笔记本的核显加独显组合，或者台式机主板集显没关。这种情况下安装逻辑会更复杂，第 5 章会专门讲。
同时记得确认一下当前实际在用哪块卡显示：
glxinfo -B | grep -i "device\|vendor"这条需要mesa-utils包。如果输出显示的是厂商的开源驱动或者核显，说明当前独显没接管，属于正常状态，装完闭源驱动后这里会变。
1.2 发行版、内核版本、安全启动状态，三件套一次查完
cat /etc/os-release | head -3 uname -r mokutil --sb-state内核版本这条尤其重要。闭源驱动本质上是内核模块，必须针对特定内核版本编译。你的内核如果是 6.8.0-45，而驱动包里预编译的模块最高只支持到 6.8.0-40，那安装过程就会要求现场编译，这时候机器上有没有装对应版本的linux-headers就成了成败关键。
安全启动状态这条，很多人第一次装驱动时完全没意识到它的存在，结果安装脚本一路跑到最后，提示模块签名失败或者直接拒绝加载。mokutil --sb-state输出SecureBoot enabled的话，你的选择只有两个：要么关闭安全启动，要么走模块签名流程（4.4 节和 3.3 节会分别展开）。没有第三条路。
1.3 搞清显示服务器是 X11 还是 Wayland
echo $XDG_SESSION_TYPE loginctl show-session $(loginctl | grep $(whoami) | awk '{print $1}') -p Type这个信息决定了后面配置文件写到哪里、哪些选项还有效。X11 下你能用/etc/X11/xorg.conf.d/里的配置文件精细控制同步、撕裂、DPI；Wayland 下大量 Xorg 选项直接无效，驱动版本太老还会导致整个会话起不来。
实测下来，如果机器上的驱动分支比较老（比如 470 系列），在 Wayland 会话里大概率会遇到窗口闪烁或无法启动的问题，这时候切回 X11 是最省事的做法。在登录界面找齿轮图标切换会话类型，或者改/etc/gdm3/custom.conf里的WaylandEnable=false。
提示：把上面这几条命令的输出全部重定向到一个文件里，比如
~/gpu-info.txt。等你黑屏进不去系统、只能从别的机器 SSH 进来救火的时候，这个文件能省你半小时。
2. 驱动方案选型：三条路，各有各的天花板
搞清楚机器底细之后，接下来是决策环节。Linux 上装显卡驱动从来不是"一条命令"的事，摆在面前的一直是三条路：用内核自带的开源驱动、用发行版仓库打包好的闭源驱动、用厂商官网下载的.run安装包。这三条路没有绝对优劣，只有适配场景的差异，选错路线的代价往往比装错版本还大。
2.1 三条路线到底差在哪儿
我习惯用一张表把这个决策说清楚，因为文字描述太容易含糊。
| 对比维度 | 开源驱动（内核自带） | 发行版仓库包 | 官方 .run 包 |
|---|---|---|---|
| 安装难度 | 零，装系统就有 | 低，一条包管理命令 | 中高，要手动处理依赖和冲突 |
| 桌面性能 | 基础办公够用 | 接近满血 | 满血 |
| 计算能力（CUDA 等） | 基本不支持 | 支持 | 支持，版本可控 |
| 内核升级后表现 | 自动跟进 | DKMS 自动重建 | 需手动重装或配 DKMS |
| 回滚难度 | 无需回滚 | 低，卸载包即可 | 高，残留清理麻烦 |
| Wayland 兼容 | 好 | 较好 | 看版本，老版本偏差 |
| 多版本共存 | 不涉及 | 困难 | 相对灵活 |
这张表里最容易被忽略的是"内核升级后表现"这一行。它看起来只是维护便利性的问题，实际上是很多人第二次出事的根源：装完驱动用了两周一切正常，某次系统更新带了个新内核，重启之后桌面起不来了。原因就是驱动模块没有跟着新内核重新编译，内核里那个版本还是旧的，模块加载时版本校验不通过。
2.2 按场景选，别按"哪个看起来高级"选
桌面办公、看视频、写代码，显卡只负责把画面输出到屏幕：用发行版仓库的闭源包足够，甚至开源驱动也能撑一段时间。这类场景追求的是稳定和省心，不需要折腾。
游戏和图形工作站：同样推荐仓库包，但要关注版本分支，太老的驱动在新游戏上会有兼容问题。仓库包的好处是升级路径清晰，出了问题一条命令回退。
深度学习、科学计算、跑推理服务：优先考虑官方.run包或者仓库里带 CUDA 支持的版本。这类场景对驱动版本和 CUDA 运行时版本的对应关系极其敏感，一个版本号错位就是满屏的CUDA error: unknown error。仓库包的好处是版本对应关系由打包者维护好了；.run包的好处是你能精确控制驱动版本，方便和一整套工具链对齐。
服务器无头环境（不接显示器，只跑计算）：这种情况其实最适合.run包加静默安装，因为不用考虑图形界面冲突，也不担心驱动把显示管理器搞挂。
2.3 版本分支怎么挑，看显卡代号不看年份
驱动版本号不是越大越好。新分支会逐步放弃对老架构的支持，这一点在官方的支持矩阵里写得很清楚，但很多人不看。经验值是：Maxwell 及更早的架构优先选 470 系列；Pascal 到 Turing 用 535 系列比较稳妥；Ampere 及更新的架构直接上新分支。
还有一个隐性约束：分支版本和 CUDA 版本的绑定关系。大致对应关系是 470 系列对应 CUDA 11.4，535 系列对应 CUDA 12.2，550 系列对应 CUDA 12.4，更新的分支对应更高的 CUDA 版本。如果你手上的代码依赖某个特定 CUDA 版本，就得反推该装哪个驱动分支，而不是先装驱动再去找能跑的代码。
提示：驱动分支一旦选定，就别频繁跟着"最新版"跳。我见过太多人因为追新分支导致原先能跑的容器镜像全部失效，最后花两天时间才把版本关系理顺。
3. 安装前的准备：把回滚路径先铺好
这一章讲的东西，是"装之前"该做的事，而不是"装的时候"该做的事。区别在于，装的时候出问题你还能操作，装完重启黑屏你就只能靠这一章准备的东西了。经验告诉我，准备工作花二十分钟，能省掉后面两小时的抓瞎。
3.1 先给自己留一条能爬回来的路
最直接的做法是准备一个能进入系统的备用入口。三个手段，建议至少准备两个：
第一，记住从图形界面切到文本终端的方式。大多数发行版是Ctrl + Alt + F3到F6中的某一组，具体哪一组取决于显示管理器。切过去之后用账号登录，就能在纯命令行下操作。这一步在黑屏但内核还在跑的情况下特别有用。
第二，学会在启动时编辑内核参数。开机在 GRUB 菜单停留的那几秒，按e进入编辑模式，找到linux那一行，在行尾加一个空格再加nomodeset，然后按F10或Ctrl + X启动。这个参数的作用是让内核不要过早加载显卡的模式设置驱动，能让你在驱动出问题的状态下进到图形界面（虽然分辨率很低）。另一个有用的参数是systemd.unit=multi-user.target，直接进多用户文本模式。
第三，如果条件允许，把 SSH 服务开起来，用另一台机器连过来操作。这种方式最舒服，因为不需要在黑屏的机器上盲敲命令。
sudo systemctl enable --now sshd ip addr show | grep "inet "拿到 IP 地址之后，用另一台机器ssh 用户名@IP就能连进去。装驱动这种高风险操作，我个人的习惯是一定走 SSH。
3.2 清理冲突驱动，这步不能省
Linux 上一个常见故障是"装了两套驱动"。表现形式是nvidia-smi能跑，但图形界面卡顿，或者dmesg里反复报模块冲突。根源在于之前装过的.run包残留、仓库包没卸干净、或者开源驱动还在抢设备。
先查一下当前都装了什么：
dpkg -l | grep -i nvidia dkms status ls /usr/lib/modules/$(uname -r)/kernel/drivers/video/ 2>/dev/null如果是 Debian 系发行版，彻底清理仓库包的做法是：
sudo apt purge '^nvidia-.*' '^libnvidia-.*' '^cuda-.*' sudo apt autoremove --purge如果是之前用.run包装的，先用它自带的卸载器：
sudo /usr/bin/nvidia-uninstall这一步做完之后重启一次，确认系统能正常进入图形界面（这时候用的是开源驱动），再开始装新的。很多人跳过这次重启，结果旧模块还在内存里活着，新模块加载时直接冲突。
然后处理开源驱动的黑名单。这个操作的本质是告诉内核"别自动加载开源驱动"，否则它会先一步抢走显卡设备。
sudo tee /etc/modprobe.d/blacklist-nouveau.conf <<'EOF' blacklist nouveau options nouveau modeset=0 EOF sudo update-initramfs -u # Debian / Ubuntu 系 # RHEL 系用：sudo dracut --force改完必须重建 initramfs，否则黑名单不生效。这一步做完重启，用lsmod | grep nouveau确认没有输出，才说明开源驱动真的被压住了。
3.3 安全启动这关，绕不过去就得面对
安全启动开启时，内核只加载有有效签名的模块。闭源驱动模块默认没有签名，于是加载失败。这个问题在安装脚本里不一定报错，可能一路"安装成功"，重启之后发现nvidia-smi报"couldn't communicate with the driver"。
两个处理方式。第一种是进 BIOS 关闭安全启动，最省事，代价是牺牲了一层启动链保护。第二种是走模块签名流程，让 DKMS 在编译模块时自动签名，并把公钥注册到固件的 MOK（Machine Owner Key）列表里。
签名流程的关键几步：
# 生成签名密钥（一次性操作） sudo mokutil --import /var/lib/dkms/mok.pub # 设置一个一次性密码，重启时会进入 MOK 管理界面 sudo reboot重启后会出现蓝底的 MOK 管理界面，选 Enroll MOK、输入刚才设的密码、确认。之后模块就能正常加载了。这个过程看起来繁琐，但做完之后每次内核升级 DKMS 都会自动用同一把密钥签名，不需要重复操作。
注意：
mokutil --import用到的公钥路径，取决于发行版的 DKMS 配置。有些发行版在安装闭源驱动包时才会生成这对密钥，所以顺序是先装包、再注册、再重启。
3.4 装驱动前为什么要停掉图形界面
这个操作经常被教程一笔带过，但它不是仪式感。图形界面运行时，显示服务器占着显卡设备，驱动模块的加载和卸载都会受影响。.run包的安装脚本会在检测到 X 在运行时直接拒绝安装，或者用--no-x-check强行跳过之后装出一个半残的状态。
正确做法是切到多用户文本模式：
sudo systemctl isolate multi-user.target这条命令会停掉显示管理器，把当前会话切到纯文本。装完之后用sudo systemctl isolate graphical.target切回来，或者直接重启。
如果你是 SSH 连进去操作的，这一步更简单，因为你的会话本来就不依赖那台机器的图形界面。
4. 实装：两条主流路线走一遍
准备工作做完，终于可以动手。这一章把仓库路线和.run路线分别走一遍，每一步都说明它在干什么，方便你出问题时定位到具体环节。
4.1 路线A：走发行版仓库，省心但要看仓库策略
Debian 系发行版有专门的工具帮你判断该装哪个版本：
sudo apt update ubuntu-drivers devices输出会列出所有可用驱动包和推荐的版本，recommended标记的那个通常是最稳妥的选择。安装就用：
sudo apt install nvidia-driver-550注意包名里的数字就是分支版本。装完之后一定要重启，因为模块在 initramfs 里加载，不重启不生效。
RHEL 系发行版要先启用第三方软件仓库，然后装的是内核模块包而不是驱动本身：
sudo dnf install akmod-nvidia xorg-x11-drv-nvidia-cudaakmod的机制是在安装时自动编译内核模块，编译依赖kernel-devel和kernel-headers，而且版本必须和当前运行的内核严格匹配。这一步是 RHEL 系最容易出问题的地方，装之前先确认：
rpm -q kernel-devel-$(uname -r)没有输出就说明版本对不上，要补装对应的kernel-devel。装完akmod之后不要立刻重启，先等它把模块编译完，用下面的命令确认：
sudo akmods --force sudo modinfo nvidia | head -5modinfo能输出模块信息，才说明编译成功。
4.2 路线B：官方 .run 包，手上有版本控制权
从官网下载对应版本的安装包后，先给执行权限，然后进文本模式执行。
chmod +x NVIDIA-Linux-x86_64-550.xx.xx.run sudo systemctl isolate multi-user.target sudo ./NVIDIA-Linux-x86_64-550.xx.xx.run \ --dkms \ --no-x-check \ --no-nouveau-check \ --silent四个参数各自的作用：--dkms让安装器把模块注册到 DKMS，后续内核升级自动重建，这是强烈建议加上的；--no-x-check跳过显示服务器检测；--no-nouveau-check跳过开源驱动检测（前面已经手动黑名单了）；--silent走非交互模式。
如果不加--silent，安装过程中会问你几个问题，值得注意的有两个：是否安装 32 位兼容库（要跑 32 位游戏或者某些老软件就选是），以及是否自动生成 Xorg 配置文件（选了会跑nvidia-xconfig，在 Wayland 环境下建议不生成）。
安装完成后不要急着切回图形界面，先验证模块加载：
lsmod | grep nvidia cat /proc/driver/nvidia/version第一条能看到一堆nvidia、nvidia_drm、nvidia_modeset之类的模块，第二条能输出驱动版本和内核模块编译时的编译器版本。两个都有输出，才说明装成功了。
4.3 DKMS：让驱动在一次次内核升级里活下来
DKMS 的全称是 Dynamic Kernel Module Support，它的作用一句话就能说清：内核升级时自动重新编译驱动模块。没有它，每次系统更新带新内核，你就得手动重装一遍驱动。
装完之后第一件事是检查注册状态：
dkms status正常输出长这样：
nvidia/550.xx.xx, 6.8.0-45-generic, x86_64: installed后面那个内核版本号很关键。如果你机器上有多个内核，要确保当前运行的内核版本在列表里，而且状态是installed。不在的话手动加一下：
sudo dkms install -m nvidia -v 550.xx.xx -k $(uname -r)如果编译失败，大概率是缺头文件：
sudo apt install linux-headers-$(uname -r) # Debian 系 sudo dnf install kernel-devel-$(uname -r) # RHEL 系再重新执行一次dkms install。这套流程走通之后，以后内核升级只需要正常重启，模块会自动重建，除非头文件没跟着装上。
4.4 装完之后的验收清单
装完驱动绝不能只敲一条nvidia-smi就宣布完事。一张完整的验收清单应该覆盖加载状态、图形栈、计算能力三个层面。
nvidia-smi glxinfo -B | grep -E "OpenGL renderer|OpenGL version" vulkaninfo --summary 2>/dev/null | head -20 dmesg | grep -i nvidia | tail -20nvidia-smi输出里要看四样东西：驱动版本号是否正确、CUDA 版本号是多少、进程列表是否干净、温度是否正常。如果驱动版本对但 CUDA 版本比你预期低，说明装的包没带完整的计算组件。
glxinfo的OpenGL renderer应该显示你的显卡型号，如果显示的是llvmpipe之类，说明还在用软件渲染，驱动没有接管。
dmesg里的信息最值得细看，驱动加载失败、显存分配异常、电源管理有问题，通常都在这里留下痕迹。
5. 配置调优：让显卡真正开始干活
驱动装好只是"能用"，离"好用"还有一段距离。这一章讲的是把性能、稳定性、功耗三个维度调到合理水平的几个关键配置。
5.1 持久化模式和常驻服务
nvidia-smi输出里有一栏Persistence-M，默认是Off。这个开关控制的是驱动在最后一个进程退出之后，是否保留模块状态。对于计算节点，关掉它意味着每次任务起来都要重新初始化驱动，会带来几百毫秒到几秒不等的延迟。
sudo nvidia-smi -pm 1这条命令是临时的，重启就失效。持久化做法是用 systemd 服务：
sudo systemctl enable nvidia-persistenced sudo systemctl start nvidia-persistenced服务起来之后，nvidia-smi里会看到一个常驻的nvidia-persistenced进程。这个做法在跑批处理任务或者容器服务时感知特别明显，实测能把任务启动的抖动降下来。
5.2 屏幕撕裂和同步策略
桌面环境下最影响观感的不是帧率，是撕裂。X11 下的处理方式是在 Xorg 配置里开合成管线。
sudo mkdir -p /etc/X11/xorg.conf.d sudo tee /etc/X11/xorg.conf.d/20-nvidia.conf <<'EOF' Section "Device" Identifier "GPU0" Driver "nvidia" Option "ForceFullCompositionPipeline" "on" Option "TripleBuffer" "on" Option "AllowIndirectGLXProtocol" "off" EndSection EOFForceFullCompositionPipeline的作用是强制整个渲染走完整的合成流程，代价是增加不到一帧的延迟，换来的是彻底消灭撕裂。玩竞技类游戏、对延迟敏感的话可以关掉，其他场景建议开。
TripleBuffer是三缓冲，对帧率不稳定的场景有帮助。AllowIndirectGLXProtocol关掉是出于安全和性能考虑，现在基本用不到间接渲染。
注意：这段配置只对 X11 生效。Wayland 下这个文件会被忽略，同步策略由合成器自己管。
5.3 笔记本双显卡：PRIME 的正确用法
笔记本场景下，独显默认不接管显示输出，这是为了省电。需要跑重负载任务时才把它调起来。看看当前策略：
prime-select query输出on-demand表示按需切换，nvidia表示全部走独显，intel或amdgpu表示只用核显。
按需模式下，图形程序默认还是走核显。要指定某个程序走独显，用环境变量：
__NV_PRIME_RENDER_OFFLOAD=1 \ __GLX_VENDOR_LIBRARY_NAME=nvidia \ 你的程序跑计算任务（比如训练脚本）的情况不一样。计算任务用到的 CUDA 设备跟显示输出是分开的，nvidia-smi能看到显卡就说明能用，不需要 PRIME 切换。这一点很多人搞混，以为要先切到nvidia模式才能跑训练，其实没必要，反而会白白增加功耗和发热。
一个实测有用的技巧是查当前功耗上限和温度阈值：
nvidia-smi -q -d POWER,TEMPERATURE | grep -E "Power Limit|Slowdown Temp|Shutdown Temp"笔记本上的功耗墙通常设得比较保守，如果你做了散热改造，可以适当上调，但要结合Shutdown Temp留足余量，别把自己烤了。
5.4 计算场景：驱动、CUDA、容器三者对齐
跑计算任务时，真正容易出问题的不是驱动本身，是三者的版本链条：驱动版本决定了支持的最高 CUDA 运行时版本，容器镜像里打包的 CUDA 版本必须低于或等于这个上限，而代码编译时用的又是另一个版本。
查驱动支持的 CUDA 上限：
nvidia-smi | grep "CUDA Version"容器场景还需要装容器运行时插件，让容器能访问显卡设备：
sudo apt install nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker然后在跑容器时加--gpus all，进去之后nvidia-smi能出表格就说明直通成功。
有一类故障特别隐蔽：宿主机驱动版本低于镜像要求的版本，容器启动时不报错，跑到一半才出CUDA error: insufficient driver version。所以镜像部署前先在宿主机上跑一遍nvidia-smi，把输出里的 CUDA 版本记下来，跟镜像的CUDA_VERSION比对，低于镜像要求的就直接升驱动。
6. 常见故障排查实录
这一章是全文最实用的部分。下面这些故障我都实际遇到过，也见过别人反复遇到，排在前面的几个出现频率最高。
6.1 黑屏、循环登录、分辨率锁死
三种表现，根源往往是同一个：驱动模块加载了，但跟显示服务器没对上。
先判断是"内核没起来"还是"图形界面没起来"。如果显示器有信号但停在启动日志，按Ctrl + Alt + F3能切到文本终端，说明内核正常运行，问题在图形栈。如果连文本终端都进不去，那得从 GRUB 加nomodeset启动。
进到系统之后，重点看这两个地方：
journalctl -b -1 -p err --no-pager | tail -50 dmesg | grep -iE "nvidia|drm" | tail -30journalctl -b -1看的是上一次启动的日志，这个信息特别有价值，因为出问题的往往是上一次启动。日志里如果出现Failed to load module "nvidia"，说明模块没加载；出现NVRM: API mismatch，说明用户态库和内核模块版本不一致，这种要卸载重装；出现nvidia: module verification failed，是安全启动的签名问题，回到 3.3 节处理。
分辨率锁死的情况通常是 Xorg 没读到显示器的 EDID 信息。可以手动指定：
sudo nvidia-xconfig --mode=1920x1080或者更彻底地重新生成配置文件，然后重启显示管理器。
6.2 内核升级之后驱动突然失效
这是出现频率第二高的故障。症状很典型：系统更新，重启，分辨率变成 1024x768，nvidia-smi报 "NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver"。
原因就一个：新内核起来了，但驱动模块还是为旧内核编译的，版本校验不通过。先确认：
uname -r dkms status如果dkms status里当前内核版本没有对应的installed记录，直接重建：
sudo dkms autoinstall这条命令会为所有已注册的模块检查当前内核，需要的话自动编译安装。如果报缺头文件，装上前一节说的linux-headers-$(uname -r)再来一次。
顺带说个预防措施：在 Debian 系发行版上，把linux-headers-generic这类元包装上，以后内核升级会带着头文件一起升，就不会再出现这个问题。
6.3 卸载不干净导致反复失败
这种故障最折磨人，因为每次重装看起来都成功，但行为就是不对。根源是残留文件太多，新的和旧的混在一起。
彻底清理的顺序是这样的：
# 先跑自带卸载器 sudo /usr/bin/nvidia-uninstall # 再清仓库包 sudo apt purge '^nvidia-.*' '^libnvidia-.*' # 清 DKMS 记录 sudo dkms status | grep nvidia sudo dkms remove -m nvidia --all # 清残留配置 sudo rm -f /etc/X11/xorg.conf sudo rm -rf /etc/X11/xorg.conf.d/20-nvidia.conf sudo rm -f /etc/modprobe.d/nvidia*.conf # 重建 initramfs sudo update-initramfs -u sudo reboot重启之后用lsmod | grep nvidia确认没有任何输出，nvidia-smi报命令不存在，这才算干净。通常来说，卸载后进入系统时如果用的是核显或者开源驱动的软件渲染，说明清理到位了。
6.4 故障速查表
把上面这些现象和排查方向整理成一张表，出事的时候对着看，比翻日志快得多。
| 现象 | 最可能的原因 | 第一步排查 |
|---|---|---|
| 重启后完全黑屏 | 驱动与显示服务器冲突 | GRUB 加 nomodeset 启动 |
| 停在登录界面，输密码又跳回来 | 会话加载失败 | 切 F3 文本终端看 journalctl |
| nvidia-smi 报无法通信 | 模块未加载或版本不匹配 | lsmod、dkms status |
| 分辨率异常低 | EDID 未识别或驱动未接管 | xrandr、glxinfo -B |
| 容器内 CUDA 报版本不足 | 宿主驱动低于镜像要求 | 比对nvidia-smi与镜像版本 |
| 内核升级后失效 | 模块未随新内核重建 | dkms autoinstall |
| 装完提示模块验证失败 | 安全启动未签名 | mokutil --sb-state，注册 MOK |
| 图形界面卡顿、花屏 | 双驱动冲突或残留 | 彻底清理后重装 |
这张表可以保存下来，遇到问题先对表，能省掉大量"瞎试"的时间。
我个人在几十台机器上装驱动折腾下来，体会最深的一点是：这套流程真正难的从来不是命令，而是"这台机器现在到底处在什么状态"。同一行命令在干净环境和脏环境里跑，结果可以完全不同。所以我现在的习惯是，装之前先完整清理一遍，宁可多花十分钟，也不要在不确定的状态上叠加操作。另一个心得是，装完一定要重启验证，不要在没重启的情况下就宣布成功——模块没进 initramfs，重启后照样失效，这种事我吃过不止一次亏。
