1. 先把机器摸清楚：T1000 的定位与 Ubuntu 18.04 的现实处境

在 Ubuntu18.04 上折腾 NVIDIA Quadro T1000 显卡驱动安装，难点从来不在“装”这个动作本身，而在于这张卡的身世、这套系统的年份，以及这两者凑在一起之后那一堆说不清道不明的兼容性细节。我前后在四台不同品牌的 T1000 工作站上做过这件事，有品牌整机、有自己攒的塔式机箱、也有从别人手里接过来的旧机器，每一次的坑点都不一样。所以这篇东西不讲通用的“三板斧”，而是把整个过程按我实际动手的顺序拆开，从勘察、清障、安装、验证到后期维护一条线走完。

T1000 这张卡在 NVIDIA 的产品谱系里属于入门级专业卡，跟游戏卡里的 GTX 1650 是同一个 Turing 核心家族（TU117），但因为挂着 Quadro 的前缀，它有几个对工程场景特别重要的特性：一是出厂驱动走的是 NVIDIA 专业卡分支，稳定性认证更严；二是官方没有限制并发编码会话数量，这一点在做多路视频转码或者多路摄像头接入的时候非常关键，而同样核心的消费级卡会被驱动限制在很低的并发数；三是功耗只有 50W 左右，很多型号甚至是单槽半高、不需要外接供电，工控机和 1U/2U 机箱里塞得进去。这些特点决定了它的典型使用场景：CAD、三维建模、入门级推理和感知算法调试、多路视频编解码、以及机器人/自动驾驶方向的标定与可视化工具。所以下面这套流程，默认你已经或者即将在这些场景里用到它。

至于 Ubuntu 18.04，说实话现在再去用这个版本，多数情况是“被环境绑架”——上游的依赖链锁死在这个版本上，比如某些老版本的点云库、某些只在这个 LTS 上验证过的工具链、某些必须和特定编译器版本配合的标定程序。这就意味着你不能随便升级系统，只能在 18.04 这个框子里把驱动这件事做扎实。而 18.04 的现实是：标准支持周期早就结束了，官方软件源迁移到了归档地址，社区里流传的绝大多数教程还停留在 2019 到 2020 年，里面写的驱动版本、PPA 状态、甚至命令输出都已经对不上了。照着老教程抄，轻则装完黑屏，重则把图形栈搞崩，最后连apt都进不去。所以第一件事不是敲安装命令，而是把机器和这个系统的现状彻底看清楚。

1.1 这张卡的脾气：规格、能力边界与人话解读

先把 T1000 的硬件底细摆出来，这样后面所有选择都有依据。它基于 TU117 核心，896 个 CUDA 核心，计算能力（Compute Capability）是 7.5，显存通常是 4GB GDDR5 或 GDDR6，位宽 128-bit，带宽在 128GB/s 上下，TDP 约 50W，绝大多数型号靠 PCIe 插槽供电，不需要额外接 6pin 或 8pin。计算能力 7.5 这个数字很关键，它决定了你能用哪些版本的 CUDA、哪些版本的深度学习框架、以及哪些推理引擎版本——很多老框架在编译时会检查这个值，低于要求会直接拒绝编译或者运行时抛错。

显存只有 4GB 是需要提前有心理准备的。跑大模型推理基本别想，跑中等分辨率的检测网络、做点云配准、做多路 1080p 视频解码，问题不大。如果你打算用它跑一些视觉算法，记得把 batch size 和输入分辨率降下来，或者在代码里做显存复用，否则很容易遇到运行时显存不足，然后误以为是驱动装坏了，其实跟驱动一点关系都没有。我见过不止一个人在这上面绕了好几天，最后发现只是模型太大。

还有一个特别容易被忽略的点：TU117 这颗核心用的视频编码单元是上一代的版本，不是同期 TU116、TU104 上的新一代编码器。具体表现为它可以做 H.264 和 HEVC 的硬件编码，但缺少新编码器的一些高级特性，比如编码时的双向参考帧支持就比较有限。这个差异对普通用户没影响，但如果你打算用它搭多路转码服务，就得在编码质量和码率上多做几组对比测试，别拿别人的调参参数直接套。解码侧的支持倒是够用，H.264、HEVC、VP8、VP9 这些常见格式都能硬解，老一代的 MPEG2 也没问题，但更新的编码格式它就不支持了，这是硬件代际决定的，装什么驱动都变不出来。

1.2 系统侧勘察：几条命令看清家底

动手之前，先把系统现状记录一遍，这相当于给自己留一份“装之前的样子”，出问题的时候可以对照。第一条命令看显卡有没有被识别：

lspci -nn | grep -i -E 'vga|3d|display'

正常情况下你会看到一行带[10de:1fb1]或者类似 ID 的记录，10de是 NVIDIA 的厂商 ID，后面的编号对应具体型号。如果这里压根看不到 NVIDIA 的设备，那就不是驱动问题了，先查 BIOS 里显卡是否被禁用、插槽是否识别、机器是否只启用了集成显卡。

第二条命令看当前内核和驱动挂载状态：

lspci -k | grep -A 3 -i -E 'vga|3d'

重点看Kernel driver in use:这一行。如果是nouveau，说明系统正在用开源驱动，这是全新安装后的默认状态；如果是nvidia，说明已经装了闭源驱动；如果是空的，说明谁都没挂上，可能显卡处于不可用状态。

第三条命令看系统版本和内核版本：

lsb_release -a; uname -r

把这两个信息记下来。内核版本尤其重要，因为 NVIDIA 的驱动模块是按内核版本编译的，5.4.0-xx-generic和4.15.0-xx-generic对应的模块不能混用，这是后面排查“驱动装了但不生效”最容易踩的一条线索。

第四条命令看当前的图形显示服务：

systemctl status display-manager | head -5

Ubuntu 18.04 桌面版默认用 GDM3，但不少人为了兼容性改成了 LightDM。这两个在驱动安装后的行为不一样，GDM3 对 Wayland 的尝试更多，而 18.04 上 NVIDIA 闭源驱动基本只能跑 Xorg 会话，如果显示管理器默认往 Wayland 走，就会出现登录后黑屏或者回退到软件渲染的情况。记住你用的是哪个，后面排查会用到。

第五条命令看软件源是否还活着：

sudo apt update

如果这里出现一堆 404，说明你的源地址还指向已经下线的普通镜像，需要换成归档地址或者可用的镜像站。这一步不做，后面所有apt install nvidia-*都会失败，而且报错信息往往很含糊，让人误以为是驱动包的问题。

1.3 安装路线怎么选：三种方案的真实取舍

摆在你面前的一共三条路，每条路都有明确的适用场景，选错了不一定装不上，但后期维护会很痛苦。

第一条是仓库方式，也就是通过apt从官方仓库或 PPA 安装nvidia-driver-xxx这类包。优点是全自动，内核升级后 DKMS 会自动重新编译模块，卸载干净，依赖关系由包管理器处理。缺点是 Ubuntu 18.04 上能拿到的驱动版本受仓库限制，版本偏老，而且这些老仓库随时可能下线。适合绝大多数场景，尤其是你希望这个环境能稳定跑一两年不折腾的情况。

第二条是官方 .run 离线安装包。优点是版本完全自己掌控，可以装任意一个官方还提供下载的版本，不需要联网，适合内网机器或者仓库彻底挂掉的情况。缺点是内核一升级模块就失效，得手动重装；而且它绕过了包管理器，卸载和文件追溯都麻烦。适合明确要锁死版本、且有能力自己维护的场景。

第三条是跟着 CUDA 工具包一起装。CUDA 的安装包里自带一个与之匹配的驱动，装完 CUDA 就顺带把驱动装了。优点是版本配对肯定没问题，省一次选择；缺点是 CUDA 附带的驱动通常不是最新也不是最适合桌面显示的，如果你的机器既要跑算法又要接显示器，可能会遇到显示相关的小毛病。适合纯计算节点或者容器宿主机的场景。

我的建议是：能用仓库方式就用仓库方式，把 .run 作为兜底手段，把 CUDA 自带驱动作为特殊情况处理。下面第 3 节会把三条路都完整走一遍，你可以按自己的情况对号入座。

2. 装驱动前的清障工作

很多人装驱动失败，问题不在安装命令写错了，而在装之前没清理干净。Ubuntu 默认加载的开源驱动 nouveau 和 NVIDIA 闭源驱动是互斥的，两个同时存在，轻则性能诡异，重则直接进不去桌面。再加上 Secure Boot 的签名机制、旧驱动残留、内核头文件缺失这几样，组合起来能产生十几种不同的故障现象。所以这一节的动作必须在正式安装之前完成，一步都不能省。

2.1 干掉 nouveau：不然后面全是玄学故障

nouveau 是社区维护的 NVIDIA 开源驱动，Ubuntu 安装时会自动加载。它不影响你开机，但会占用显卡这个设备，导致闭源驱动装完之后无法接管。所以第一步就是把它拉黑：

sudo tee /etc/modprobe.d/blacklist-nouveau.conf <<'EOF' blacklist nouveau options nouveau modeset=0 EOF

写完这个文件之后，必须更新 initramfs，因为这个配置是在内核启动阶段生效的：

sudo update-initramfs -u

然后重启，重启后验证 nouveau 是否真的没加载：

lsmod | grep -i nouveau

如果这条命令没有任何输出，说明拉黑成功；如果还能看到 nouveau 相关的模块，说明要检查是不是有其他配置文件在反向加载它，可以用grep -r nouveau /etc/modprobe.d/把所有相关文件找出来。我还遇到过一种情况：配置写对了，但机器用的是自定义内核，update-initramfs更新的是另一个内核的镜像，重启后自然还是老样子。所以每次改完这类配置，我都习惯用lsinitramfs /boot/initrd.img-$(uname -r) | grep nouveau确认一下，看看改动到底有没有进到当前内核的启动镜像里。

注意：拉黑 nouveau 之后如果直接重启并且驱动还没装，图形界面可能会掉到低分辨率模式。这是正常现象，不是故障，装完闭源驱动就恢复了。如果这时候你发现连图形界面都进不去，可以先切到字符终端（Ctrl+Alt+F3）继续操作。

2.2 Secure Boot 与 MOK：不想折腾就直接关

现在的机器主板基本都默认开启 Secure Boot。它要求所有内核模块必须有合法签名，而 NVIDIA 的闭源驱动模块是没有微软签名链的，DKMS 会在编译时生成一对临时密钥，你要在重启后进入一个蓝色的 MOK 管理界面手动确认注册，否则模块加载会被拒绝，表现出来就是nvidia-smi报找不到驱动。

这个流程本身不难，但麻烦在两点：一是它需要你在物理机前操作，远程 SSH 的场景根本没法点；二是很多工控机和品牌整机的 BIOS 里，关闭 Secure Boot 需要先设置管理员密码，而密码可能不在你手里。所以我的实际做法是分两种：自己完全掌控的机器，直接进 BIOS 关掉 Secure Boot，省掉所有签名环节；受管控的机器，就老老实实走 MOK 注册流程，安装nvidia-dkms的时候它会提示你设置一个一次性密码，重启后在蓝色界面里选 Enroll MOK，输入那个密码即可。

验证 Secure Boot 状态用这条命令：

mokutil --sb-state

输出SecureBoot disabled就说明关了，SecureBoot enabled就需要走签名流程。这个状态确认一遍，能省掉后面很多无意义的排查。

2.3 内核头文件、编译链与一次可回滚的备份

DKMS 编译驱动模块需要当前内核的头文件，缺了它会编译失败，而且失败信息常常藏在安装日志的角落里，终端上只显示一句很笼统的“build failed”。所以提前装好：

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

如果你用的是自定义内核或者手动编译的内核，linux-headers-$(uname -r)可能找不到对应的包，这时候需要手动指定头文件路径，或者在编译内核时就把头文件安装到标准位置。这个坑在工控机上很常见，因为厂商经常提供打过补丁的内核，而头文件包不一定在源里。

备份这件事我要单独强调。装显卡驱动是有一定概率搞坏图形栈的，尤其是走 .run 安装的时候，它会覆盖系统里的 OpenGL 库文件。所以动手前做两件事：第一，把关键配置目录打包备份，至少包含/etc/X11、/etc/modprobe.d、/etc/default/grub；第二，如果这台机器上有重要数据，做一次完整快照或者全盘备份。我自己的习惯是，只要这台机器上跑着还没提交代码的实验环境，就一定先备份，因为一次翻车可能就是两三个小时的重装时间，而这个时间成本远高于备份的几分钟。

sudo tar czf ~/backup-x11-$(date +%F).tar.gz /etc/X11 /etc/modprobe.d /etc/default/grub

3. 三条路线的完整实操

准备工作做完，就可以正式装了。这一节我把三条路线各自的完整流程、参数含义、以及每一步为什么要这么做都写清楚。你可以只挑你要走的那一条看，但我建议至少把仓库方式那一节读完，因为它是后面两条路线的参照基准，出问题时的对比分析都要靠它。

3.1 路线 A：仓库方式一步一步装

这是我最推荐的路线。先确认ubuntu-drivers-common这个工具装没装，它能自动检测显卡并推荐可用的驱动版本：

sudo apt install -y ubuntu-drivers-common ubuntu-drivers devices

输出里会给出一串候选驱动，每行后面标着recommended、distro、third-party之类的标记。优先选标recommended的那个，因为它通常是当前系统版本上验证最充分的。Ubuntu 18.04 上常见的候选是 390、410、430、440、450、460、470 这几个系列。

如果ubuntu-drivers devices输出为空，或者候选版本明显偏老、不满足你的需求，就需要加 PPA：

sudo add-apt-repository ppa:graphics-drivers/ppa sudo apt update ubuntu-drivers devices

加完 PPA 再跑一次检测，通常会多出一些更新的版本。这里有一个必须提醒的点：PPA 里显示有某个高版本号，不代表它一定为 18.04 构建过。很多新驱动早就停止了对 bionic 的构建支持，你在 PPA 页面能看到版本号，但apt install的时候会提示找不到候选包，或者装完之后模块编译失败。所以看到不熟悉的版本号，先跑一次apt-cache policy nvidia-driver-xxx看看有没有对应的安装候选。

选定版本后，可以一键安装：

sudo ubuntu-drivers autoinstall

也可以指定版本手动装：

sudo apt install -y nvidia-driver-470

安装过程中如果 Secure Boot 是开启的，终端会弹出对话框让你设置 MOK 密码，输入一个你记得住的密码，重启后会用到。装完后重启机器，重启是必须的，因为要重新加载内核模块并让 nouveau 的拉黑生效。

开机后马上验证：

nvidia-smi

能正常输出显卡型号、驱动版本、显存占用、温度、功耗等信息，就说明这条路走通了。如果报错，直接跳到第 5 节排查。

这套方式最大的好处是内核升级后会自动重建模块，你基本不用管。但要注意一点：DKMS 重建依赖新内核的头文件包，如果某次系统更新只更新了内核没更新头文件（比如你自己装了 mainline 内核），重建会静默失败，下次重启就进不了图形界面。所以我在长期运行的机器上会额外装一个linux-headers-generic保证头文件跟随内核。

3.2 路线 B：官方 .run 离线安装

这条路适合三种情况：机器不能联网、仓库和 PPA 都失效、或者你明确需要一个仓库里拿不到的特定版本。前提是你已经从官方渠道下载好了对应版本的.run文件，注意要选 Linux 64-bit 版本，并且对照官方文档确认该版本支持 Turing 架构和你当前的内核版本。

第一步，先彻底卸载系统里可能存在的驱动和相关库，避免文件冲突：

sudo apt purge -y '^nvidia-.*' sudo apt autoremove -y sudo apt install -y build-essential dkms

第二步，切到纯字符模式，不要在图形界面里跑安装程序，否则正在运行的 X 服务会占用显卡，安装程序会直接报错退出：

sudo systemctl isolate multi-user.target

如果你用的是远程登录，这一步之后 SSH 还在，但图形界面会断，属于正常现象。切过去之后确认一下没有图形进程在跑：

ps aux | grep -i xorg

有输出的话，用sudo systemctl stop display-manager停掉显示管理器再确认一次。

第三步，执行安装。基本命令是：

sudo sh NVIDIA-Linux-x86_64-470.xx.xx.run

但这里有几个参数必须搞清楚。如果你这台机器只用显卡做计算和转码，不接显示器、不需要 OpenGL 图形加速，加--no-opengl-files可以避免覆盖系统自带的 OpenGL 库，能显著降低把桌面搞崩的概率：

sudo sh NVIDIA-Linux-x86_64-470.xx.xx.run --no-opengl-files

反过来，如果你要用它接显示器跑图形界面，就不要加这个参数，否则会出现 Xorg 找不到 NVIDIA 的 GLX 扩展模块，也就是第 5 节会讲的glxserver_nvidia加载失败。这一点是 .run 安装最常见的翻车点，因为很多老教程不加区分地推荐--no-opengl-files，结果接显示器的用户装完就进不去桌面了。

安装过程中会问几个问题，我的选择是：是否注册 DKMS 模块选 Yes（这样内核升级时能自动重建），是否安装 32 位兼容库按需选择（如果不用 32 位程序可以不装），是否自动更新 X 配置一般选 No，装完之后按需手动生成配置文件。

第四步，重启回到图形模式：

sudo reboot

重启后验证方式和路线 A 一样，跑nvidia-smi和glxinfo -B。

这条路的最大风险在于内核升级。每次内核版本变化，都需要重新运行一遍.run安装程序，否则模块加载会失败。我自己的做法是在/etc/kernel/postinst.d/下面挂一个自动重装的脚本，但对大多数人来说，更省事的办法是把内核版本锁定住，不让系统自动更新内核，这一点在第 6 节会讲。

3.3 路线 C：跟着 CUDA 一起装

如果你的目标不只是让显卡跑起来，还要跑 CUDA 程序，那么直接用 CUDA 安装包是一条捷径。安装包自带一个与之配对的驱动版本，装完之后驱动和 CUDA 的兼容性基本不用操心。

下载 CUDA 的本地安装包之后，执行：

sudo sh cuda_11.x_xxxx_linux.run

安装界面里有一个驱动版本的选择项，如果你机器上已经有驱动了，把驱动那一项的勾取消掉，只装工具包；如果是全新机器，就保持勾选，让它一起装。安装完成后需要配置环境变量：

echo 'export PATH=/usr/local/cuda/bin:$PATH' >> ~/.bashrc echo 'export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc source ~/.bashrc nvcc -V

nvcc -V能输出版本号，说明工具链可用。再跑nvidia-smi，如果右上角显示的 CUDA Version 与你装的一致或更高，说明驱动部分也没问题。

这条路要注意两个细节。一是 CUDA 自带的驱动版本通常比对应的独立驱动版本要旧一些，如果你对桌面显示或者视频编码有要求，可能得在装完 CUDA 之后再用仓库方式把驱动升到较新的版本，这时候要保证 CUDA 版本不会因为驱动升级而失效——一般来说大版本向前兼容，但跨太多代就有风险，建议升级后重新跑一遍 CUDA 的示例程序验证。二是 Ubuntu 18.04 上的 CUDA 支持到 11.x 系列就停了，更新的版本官方已经不再为这个系统提供安装包，所以不要盲目去找最新的安装包，找不到对应系统版本的文件。

3.4 驱动版本怎么挑：一张对照表说清楚

版本选择是这件事里最让人犹豫的部分。选太老，缺功能；选太新，兼容性差。结合我在 18.04 上的实际经验，把常见的几个版本系列整理成下面这张表，供你参考。

选版本的核心逻辑是：以你要跑的应用的官方文档为准，而不是以驱动版本号的新旧为准。比如某个标定工具文档里写的推荐驱动是 460，那就别自作主张装 470，因为它的依赖链可能只测过那一版。反过来，如果你只是想让显卡能接显示器、能跑个 OpenCV 的 CUDA 加速，那就选ubuntu-drivers devices标了 recommended 的那个，省事又稳。我见过太多“装最新版驱动求心安”最后反而花更多时间排查的案例，这个方向上的努力收益很低。

4. 装完不算完：三层验证法

nvidia-smi能跑通，只能说明驱动模块加载成功了，不能说明图形栈、编解码、CUDA 都是正常的。我一般会做三层验证，逐层加码，这样出问题的时候能快速定位到底是哪一层坏了。

4.1 第一层 nvidia-smi：输出里藏着什么信息

这条命令的输出信息量其实很大，值得逐项看一遍。第一行右上角的 Driver Version 是你当前加载的驱动版本，如果你装的是 470 但这里显示 450，说明系统里有两个驱动，加载的是另一个。CUDA Version 表示这个驱动最高支持的 CUDA 运行时版本，不是你装的 CUDA 版本，别混淆。

中间那张表里，Temp 是核心温度，T1000 这类卡空闲时一般在 35 到 50 度之间，跑起来不超过 80 度都算正常，如果刚开机就冲到 80 度以上，要检查机箱风道或者散热器是不是装歪了。Pwr:Usage/Cap 是实时功耗和功耗墙，T1000 的 Cap 通常在 50W 左右，如果显示的是个位数，说明卡正在降频或者根本没被真正使用。Memory-Usage 是显存占用，这是排查显存泄漏最直观的指标。GPU-Util 是使用率，空闲时是 0，跑任务时会上去。

下面还有一段 Processes 列表，显示哪些进程正在占用显卡。这个在排查“显卡被谁占着”时特别有用。如果nvidia-smi报错，那就说明模块层面就出问题了，不用往下做第二三层，直接去第 5 节。

4.2 第二层 图形栈验证：OpenGL、GLX 与合成器

图形栈验证需要装一个小工具：

sudo apt install -y mesa-utils glxinfo -B

输出里重点看两行：OpenGL renderer string应该显示你的 NVIDIA 显卡型号，如果显示的是llvmpipe或者Software Rasterizer，说明当前跑的是软件渲染，显卡没有真正接管图形加速。OpenGL version string会给出当前 OpenGL 版本，配合 NVIDIA 驱动一般会显示 4.6 之类的高版本。如果这两项不对，说明驱动模块虽然加载了，但 GLX 库没有正确接入。

再检查一下显示管理器用的是 Xorg 还是 Wayland：

echo $XDG_SESSION_TYPE

在 Ubuntu 18.04 上装了 NVIDIA 闭源驱动之后，这里应该是x11。如果是wayland，那么基于 Wayland 的会话很可能会回退到软件渲染，或者干脆出现登录循环。解决方式是在/etc/gdm3/custom.conf里把WaylandEnable=false的注释去掉，然后重启显示管理器。这个文件在 Ubuntu 18.04 上是/etc/gdm3/custom.conf，不同版本路径略有差异，可以用ls /etc/gdm3/确认。

4.3 第三层 真实负载验证：NVENC 转码与显存压力测试

前两层过了，说明驱动和图形栈都正常。但我更看重第三层，也就是用真实负载压一遍，因为有些问题是低负载下发现不了的。最方便的验证方式是视频转码：

ffmpeg -hide_banner -hwaccels

这个命令会列出当前 ffmpeg 支持的所有硬件加速方式，如果列表里有cuda或者nvdec，说明编解码接口可用。再看编码器：

ffmpeg -hide_banner -encoders | grep nvenc

正常应该能看到h264_nvenc和hevc_nvenc。然后跑一次实际的转码：

ffmpeg -hwaccel cuda -i input.mp4 -c:v h264_nvenc -preset medium -b:v 4M -c:a copy output.mp4

注意：Ubuntu 18.04 仓库里的 ffmpeg 版本偏老，用的是老一代的参数命名。新版本的 ffmpeg 里编码质量档位叫p1到p7，而老版本里叫medium、slow、fast这一类。如果你从网上抄了-preset p5这样的参数在老版本上跑，会直接报参数不支持。这不是驱动问题，是 ffmpeg 版本差异，换用老命名即可。

转码过程中在另一个终端跑nvidia-smi -l 1观察，应该能看到 GPU-Util 明显上升、显存被占用、功耗上到 30W 以上。如果转码成功但nvidia-smi里一点动静都没有，说明 ffmpeg 其实在用 CPU 编码，硬件加速没真正生效，这时候要检查 ffmpeg 是不是在编译时启用了 nvenc 支持（老版本仓库包一般是带的，但某些自定义编译的不带）。

5. 踩坑实录与故障速查

这一节是我花时间最多的地方，也是这篇文章里最有价值的部分。下面这些故障现象，几乎每一个我都在真实机器上遇到过，而且不止一次。我把它们按报错信息归类，并把排查思路拆成可以照着走的步骤。

5.1 nvidia-smi has failed 这类报错的完整排查树

完整的报错通常是这样的：NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.这句话本身没有信息量，得靠下面的排查来确定病因。

第一步，确认模块到底加载了没有：

lsmod | grep -i nvidia

如果没有输出，说明模块根本没加载。转到第二步。如果有输出但仍然报错，说明模块加载了但设备节点有问题，跳到第四步。

第二步，尝试手动加载并看报错：

sudo modprobe nvidia

这里的报错信息通常很关键。如果提示Module not found，说明模块文件不存在，多半是驱动没装成功或者 DKMS 编译失败；如果提示签名相关的错误，说明 Secure Boot 拦住了，回到 2.2 节处理。

第三步，检查 DKMS 状态：

dkms status

正常应该显示nvidia, 470.xx.xx, 5.4.0-xx-generic, x86_64: installed。如果显示build failed或者列表里压根没有 nvidia，说明编译这一步就没过。常见原因是内核头文件缺失，重新走一遍 2.3 节的准备工作，然后sudo dkms autoinstall重试。

第四步，看内核日志里驱动说了什么：

sudo dmesg | grep -i -E 'nvidia|nouveau' | tail -30

这里面能找到最直接的原因。如果看到nouveau相关的初始化信息，说明拉黑没生效，回到 2.1 节。如果看到显存分配失败、通信超时之类的信息，可能是硬件层面的问题，比如卡没插好、供电不足、或者插槽是 PCIe 转接的兼容性有问题，这种情况换一个插槽或者换一台机器交叉验证一下。

第五步，检查是不是装了两个驱动版本打架：

dpkg -l | grep -i nvidia

如果看到两个不同版本系列的nvidia-driver-xxx同时存在，先把它们全卸干净再重装一个，混装是很多诡异问题的根源。

5.2 循环登录、黑屏与分辨率错乱

循环登录的表现是：开机进登录界面，输密码之后一闪又回到登录界面，无限重复。这个问题的根源通常在图形会话层面，不在驱动模块本身，因为驱动能加载起来（否则你连登录界面都看不到）。

最可能的原因是显示会话走了 Wayland，而 NVIDIA 驱动在这套系统上对 Wayland 的支持很不完整。处理方式就是在 GDM3 的配置里关掉 Wayland：

sudo sed -i 's/^#WaylandEnable=false/WaylandEnable=false/' /etc/gdm3/custom.conf sudo systemctl restart gdm3

如果这个没解决，就检查 Xorg 的日志：

cat ~/.local/share/xorg/Xorg.0.log | grep -i -E '\(EE\)|\(WW\)' | head -30

两个大写的 EE 表示错误，WW 表示警告。最常见的错误是 GLX 模块加载失败，也就是下一小节要讲的glxserver_nvidia。还有一种情况是.Xauthority权限不对，表现为 Xorg 日志里提示无法打开权限文件，处理方式是把用户主目录下的.Xauthority删掉让它重新生成，同时确认/tmp目录权限正常。

黑屏和分辨率错乱则通常是 EDID 识别或者显示模式配置的问题。如果接的是老显示器或者通过转接头连接，驱动可能读不到正确的 EDID 信息，只能给出一个很低的分辨率。这种情况下可以通过xrandr手动指定模式，或者在 Xorg 配置里手动写一段 ModeLine。这个属于显示配置的范畴，跟驱动安装本身关系不大，但很容易被误判成驱动故障，所以我一般会先确认nvidia-smi是正常的，再去处理分辨率问题。

5.3 glxserver_nvidia 加载失败与 OpenGL 库被覆盖

这个报错的完整形式是Failed to load module "glxserver_nvidia" (module does not exist, 0)，通常出现在用.run安装包的场景里。原因就是我们前面提到的：你在安装时加了--no-opengl-files，安装程序跳过了 GLX 相关文件的安装，但 Xorg 的配置里依然期望加载 NVIDIA 的 GLX 模块，于是启动时找不到就报错，图形界面要么起不来，要么掉到软件渲染。

处理方式有两条。如果你需要图形界面，重新跑一遍.run安装程序，不加--no-opengl-files，让它把 GLX 文件装上。如果你不需要图形界面，那就让 Xorg 别去加载这个模块，在/etc/X11/xorg.conf里把相关段落注释掉，或者干脆不生成这个配置文件。我个人的建议是，只要这台机器要接显示器，就别省这一步；只有纯计算节点才考虑用--no-opengl-files。

还有一个相关问题是 OpenGL 库被覆盖后，系统里其他依赖 Mesa 的程序跑不起来了。这是因为 NVIDIA 的安装程序会把libGL.so之类的软链接指向自己的实现，而有些程序（尤其是通过 Snap 或者 Flatpak 装的）期望的是系统 Mesa 版本。这种情况可以通过update-alternatives来管理多个 OpenGL 实现，或者用--no-opengl-files安装驱动后，另外用libglvnd那套机制来做运行时分发。这套东西稍微绕，我的做法是尽量统一：桌面机器就用仓库方式装驱动，不碰.run，从源头上避免覆盖问题。

5.4 常用命令与故障对照表

为了排查方便，我把上面提到的命令和对应的故障现象整理成一张表，你可以直接当速查手册用。

6. 后期维护与场景延伸

驱动装完只是开始，真正让人头疼的是后面几个月的稳定运行。Ubuntu 18.04 的自动更新机制可能在某个夜里把内核升级到新版本，然后第二天早上你开机就是黑屏；某个依赖包可能因为仓库归档导致apt upgrade卡住；跑标定工具的时候可能发现驱动版本和工具要求的 CUDA 版本对不上。这一节讲的就是这些“装完之后”的事。

6.1 锁住内核和驱动版本，别让自动更新毁掉环境

对于这类需要长期稳定运行的机器，我的标准做法是锁定内核版本，只做安全更新。具体操作是先把linux-image、linux-headers、linux-generic这几个包标记为保持：

sudo apt-mark hold linux-image-generic linux-headers-generic linux-generic

apt-mark hold之后，这些包就不会再被apt upgrade升级。要看当前锁了哪些包，用apt-mark showhold。这个操作能避免绝大多数“开机黑屏”的意外，代价是你得手动关注内核安全更新，每隔一段时间主动评估一次是否要升级。对我自己的机器来说，这个取舍是值得的，因为重装驱动的成本远高于晚几天打补丁的风险。

驱动包本身也建议锁住。如果你装的是 470 系列，就把nvidia-driver-470、nvidia-dkms-470这些一起 hold 住，避免某次更新把驱动升到一个和当前内核不匹配的版本。同时记得把nvidia-dkms保留在自动重编译的状态，这样即使内核被动升级了，模块也能跟着重建。

还有一点容易被忽略：PPA 的优先级问题。如果同时存在官方仓库和 PPA 两个来源的同名包，apt会选择版本号更高的那个，也就是 PPA 里的。这本来没问题，但如果某天 PPA 下线了，你的apt update会疯狂报错，进而阻塞整个更新流程。所以长期运行的机器上，我会定期清理不再使用的 PPA，用sudo add-apt-repository --remove ppa:xxx移除，或者直接在/etc/apt/sources.list.d/里把对应的文件重命名让它失效。

6.2 相机雷达联合标定这类工具链对驱动的额外要求

最后聊聊场景。如果你的 T1000 是用在自动驾驶或者机器人方向的相机雷达联合标定这类工具上，驱动装好只是第一步，后面还有几层依赖需要对齐。这类工具链一般会依赖 CUDA、OpenCV 的 CUDA 模块、PCL 点云库，以及某些特定版本的 Eigen 或者 Ceres，任何一层的版本错位都会导致编译失败或者运行时报错。

从驱动角度看，重点有两件事。第一是 CUDA 版本和驱动版本必须匹配。驱动有一个“最高支持的 CUDA 版本”，你装的 CUDA 运行时只要不超过这个上限就可以正常工作，超过了就会报运行时版本不匹配。所以选驱动的时候，先把工具链文档里要求的 CUDA 版本翻出来，再倒推需要的最低驱动版本，而不是反过来。第二是 OpenCV 编译时的 CUDA 架构参数。T1000 的计算能力是 7.5，编译 OpenCV 的时候CUDA_ARCH_BIN要包含 7.5，否则编译出来的库在你的卡上跑不了 CUDA 加速，只会静默地回退到 CPU 实现。这个错误很隐蔽，因为程序能跑，只是速度慢，你可能会以为是显卡性能不行。

至于点云可视化和多传感器数据同步显示，T1000 的 4GB 显存是需要留心的。一个高线数激光雷达的点云加上几路相机图像，很容易把显存吃到 80% 以上，如果再开个 RViz 之类的可视化工具，可能就会掉帧甚至崩溃。我的做法是把可视化的帧率降下来，比如从 30Hz 降到 10Hz，同时关掉不必要的显示层，把显存留给真正的算法处理。这类经验没什么技术含量，但在实际项目里能让机器稳定不少。

提示：如果工具链文档里写的驱动版本和你机器上能拿到的版本不一致，优先考虑用官方.run包精确安装文档要求的版本，而不是用更新的版本“试试看”。在这种多组件耦合的场景里，版本的可预测性比版本的新旧重要得多。

装过这么多次之后，我最大的体会是：这类老系统加老硬件的组合，最大的敌人不是技术难度，而是信息污染。网上流传的教程里，有相当一部分是复制粘贴的，作者自己都没在 18.04 加 T1000 这个组合上跑过；还有一些是几年前写的，当时能用的仓库和 PPA 现在早就变了。所以我每次动手之前都会先花十几分钟把当前系统的真实状态、可用仓库的真实内容、以及工具链的真实版本要求全都对一遍，这个过程看起来慢，但比起装到一半发现问题再回头排查，反而省时间。另外就是一定要留退路，备份、快照、以及一条能回到字符终端的路（Ctrl+Alt+F3），这三样东西能让你在任何一次翻车里全身而退。