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 -5Ubuntu 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 modeset0 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 之后如果直接重启并且驱动还没装图形界面可能会掉到低分辨率模式。这是正常现象不是故障装完闭源驱动就恢复了。如果这时候你发现连图形界面都进不去可以先切到字符终端CtrlAltF3继续操作。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/grub3. 三条路线的完整实操准备工作做完就可以正式装了。这一节我把三条路线各自的完整流程、参数含义、以及每一步为什么要这么做都写清楚。你可以只挑你要走的那一条看但我建议至少把仓库方式那一节读完因为它是后面两条路线的参照基准出问题时的对比分析都要靠它。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输出为空或者候选版本明显偏老、不满足你的需求就需要加 PPAsudo 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 -Vnvcc -V能输出版本号说明工具链可用。再跑nvidia-smi如果右上角显示的 CUDA Version 与你装的一致或更高说明驱动部分也没问题。这条路要注意两个细节。一是 CUDA 自带的驱动版本通常比对应的独立驱动版本要旧一些如果你对桌面显示或者视频编码有要求可能得在装完 CUDA 之后再用仓库方式把驱动升到较新的版本这时候要保证 CUDA 版本不会因为驱动升级而失效——一般来说大版本向前兼容但跨太多代就有风险建议升级后重新跑一遍 CUDA 的示例程序验证。二是 Ubuntu 18.04 上的 CUDA 支持到 11.x 系列就停了更新的版本官方已经不再为这个系统提供安装包所以不要盲目去找最新的安装包找不到对应系统版本的文件。3.4 驱动版本怎么挑一张对照表说清楚版本选择是这件事里最让人犹豫的部分。选太老缺功能选太新兼容性差。结合我在 18.04 上的实际经验把常见的几个版本系列整理成下面这张表供你参考。版本系列适用场景优点风险点390 系列老平台、只求能用稳定性验证充分兼容老内核对新一点的框架和库支持不够440 / 450 系列通用办公、CAD、图形加速与 18.04 契合度高Xorg 表现稳部分新版转码功能缺失460 / 470 系列视频转码、需要较新 CUDA 的场景功能完整支持较新 CUDA 版本PPA 可能已停止构建需确认候选包CUDA 自带驱动纯计算节点、容器宿主版本配对绝对可靠桌面显示和转码能力偏保守更高版本一般不建议在 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 还是 Waylandecho $XDG_SESSION_TYPE在 Ubuntu 18.04 上装了 NVIDIA 闭源驱动之后这里应该是x11。如果是wayland那么基于 Wayland 的会话很可能会回退到软件渲染或者干脆出现登录循环。解决方式是在/etc/gdm3/custom.conf里把WaylandEnablefalse的注释去掉然后重启显示管理器。这个文件在 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 couldnt 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 的配置里关掉 Waylandsudo sed -i s/^#WaylandEnablefalse/WaylandEnablefalse/ /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 常用命令与故障对照表为了排查方便我把上面提到的命令和对应的故障现象整理成一张表你可以直接当速查手册用。命令观察重点对应问题lspci -nn | grep -i nvidia是否能看到设备看不到说明硬件或 BIOS 层面有问题lspci -k | grep -A3 nvidiaKernel driver in use显示 nouveau 说明拉黑未生效lsmod | grep nvidia模块是否加载无输出说明模块没加载dkms status编译是否成功build failed 说明头文件缺失或编译出错modprobe nvidia加载时的具体报错签名失败、模块不存在等都能看出来dmesg | grep -i nvidia内核层的初始化信息硬件通信失败、显存分配失败nvidia-smi驱动版本、显存、功耗版本不对说明装了两个驱动glxinfo -BOpenGL renderer显示 llvmpipe 说明在软件渲染echo $XDG_SESSION_TYPE会话类型显示 wayland 说明要关掉 Waylandffmpeg -hwaccels硬件加速列表没有 cuda 说明编码链没通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-genericapt-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 现在早就变了。所以我每次动手之前都会先花十几分钟把当前系统的真实状态、可用仓库的真实内容、以及工具链的真实版本要求全都对一遍这个过程看起来慢但比起装到一半发现问题再回头排查反而省时间。另外就是一定要留退路备份、快照、以及一条能回到字符终端的路CtrlAltF3这三样东西能让你在任何一次翻车里全身而退。