ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

Ubuntu 18.04 安装 Quadro T1000 驱动与 CUDA 环境

Ubuntu 18.04 安装 Quadro T1000 驱动与 CUDA 环境 手上这台装着 Quadro T1000 的机器是三年前配来做视觉算法开发的系统一直压在 Ubuntu 18.04 LTS 上没动过。原因很简单整个工具链、第三方库、编译脚本全是按这个版本的 GCC 和 OpenCV 调通的换系统意味着重新踩一遍依赖地狱。但 Ubuntu 18.04 加 NVIDIA 显卡驱动安装这件事本身就是个老生常谈却又每次都能让人掉头发的活儿——尤其是 Quadro 这种专业卡它的装法和普通 GeForce 有不少细节差异。这篇东西就是把这台机器上反复装、反复坏、反复修的经验完整记下来从版本选型、nouveau 屏蔽、apt 与 runfile 两条路线一直到装完之后 CUDA、ffmpeg 硬编解码、多屏输出的配套配置以及那些让人血压升高的报错到底该怎么查。如果你手上也有一台跑着 Ubuntu 的老工作站或者正在给入门级专业卡搭深度学习、视频处理环境这篇应该能帮你省下几个晚上。1. 先把机器的底细摸清楚再决定驱动怎么装1.1 Quadro T1000 的定位决定了驱动版本的下限Quadro T1000 用的是 TU117 核心图灵架构里最小的一颗896 个 CUDA 核心、4GB 显存、128 位位宽整卡功耗四十多瓦走的是不需要外接供电的那条路线。它没有 RT Core也没有 Tensor Core所以指望它跑光追或者大规模混合精度训练是不现实的但做常规的推理、图像处理、多路视频解码、CUDA 加速计算完全够用而且功耗低、发热小塞在小机箱里跑 7x24 也不吵。关键点在于它的计算能力等级是 7.5这个数字直接决定了两件事。第一驱动版本不能太老。图灵卡需要 410 系以上的驱动才能被正确识别你如果手贱装了个 390 的驱动装完大概率是黑屏或者进系统之后nvidia-smi报一句经典的 “NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver”然后你会以为是驱动没装好其实是因为驱动压根不支持这颗核心。第二CUDA 工具链的选择也被这个等级约束住了。7.5 的卡配 CUDA 9.0 是能跑的但现在的框架基本都要求 CUDA 11 以上所以驱动版本还得往上抬一般建议落在 450 到 535 这个区间。我个人的经验是在 Ubuntu 18.04 这种老系统上做长期稳定的开发机驱动版本不要盲目追新。新版驱动确实对 Vulkan、视频编解码有改进但 Ubuntu 18.04 的内核版本相对老用户态库也老新驱动经常会在 Xorg 初始化阶段出状况。稳妥的做法是挑一个经过长期验证的 LTS 分支470 和 535 都是图灵卡能用的、支持周期足够长的版本我最后落在 470 上跑了两年多没出过幺蛾子。提示判断一颗 NVIDIA 卡“最低需要哪个驱动版本”最快的办法是去查官方驱动的支持列表里面有一张架构与驱动分支的对应表。别靠猜猜错的代价是一次黑屏加半天的恢复。1.2 三种装法的对比与选择逻辑在 Ubuntu 18.04 上装 NVIDIA 驱动实际上只有三条正经路子每条路背后对应的是不同的心智模型和维护成本选错了不是装不上而是后面每次内核升级都要重新遭一遍罪。装法核心命令/来源优点缺点适合谁系统附加驱动ubuntu-drivers/ 软件与更新里的附加驱动面板图形化一条命令搞定自动处理 DKMS版本可选范围窄有时推荐的版本并非最优只想尽快点亮屏幕的人apt 仓库PPAapt install nvidia-driver-470版本切换干净卸载彻底内核升级自动重建模块需要联网加 PPA老系统上 PPA 版本有限长期维护的开发机绝大多数场景官方 runfile官网下载.run文件版本最全能精确控制装哪些组件与 apt 冲突内核升级后需要重装卸载容易留残留需要特定版本或 apt 装不上的场景这张表里的选择逻辑其实很简单只要 apt 能装、版本满足需求就不要碰 runfile。原因不在于 runfile 不好而在于 Ubuntu 的包管理系统和 runfile 是两套互不认识的体系一旦你在一个已经用 apt 装过驱动的系统上直接跑 runfile两边的库文件会打架最典型的症状就是 Xorg 日志里冒出failed to load module glxserver_nvidia然后整个图形界面起不来。反过来说什么时候必须用 runfile两种情况。一是 apt 仓库里能拿到的最高版本仍然低于你的需求比如你需要 550 以上的驱动去支持更新的计算特性而 PPA 在老系统上已经停止更新二是你需要一个非常特定的版本号比如复现某篇论文的实验环境或者某个商业软件的认证驱动列表里只有那一个版本。这两种情况我都遇到过所以后面 runfile 那一节会写得很细。还有第三种情况值得单独提一句如果你确实是新手只是想把这台机器从“分辨率 800x600 的糊屏”状态救回来那就用“软件与更新 - 附加驱动”这个图形面板它本质上是 apt 的封装帮你自动挑一个合适的版本并装好 DKMS出问题的概率最低。2. 动手前的准备工作少走弯路的三个前置动作2.1 确认显卡型号、VBIOS 与当前驱动状态不管走哪条路第一步永远是确认硬件身份而不是直接开装。我见过不少人因为把笔记本的双显卡环境当台式机处理装完之后独显没起来还把集显搞挂了的案例。# 看显卡是否被 PCI 总线正确识别 lspci | grep -i vga lspci | grep -i nvidia # 看更详细的信息包括驱动正在使用哪个内核模块 lspci -k -s $(lspci | grep -i nvidia | head -n1 | cut -d -f1) # 看卡的身份信息需要驱动已装好 nvidia-smi -q | head -n 30 # 看 VBIOS 版本排查“卡是矿卡/改卡”的经典手段 nvidia-smi -q | grep -i vbioslspci -k这一条特别值得看它会告诉你 “Kernel driver in use” 是谁。如果是nouveau说明当前跑的是开源驱动如果是nvidia说明商业驱动已经在工作如果这一项是空的说明两个都没挂上卡处于“裸奔”状态。这三种状态对应的处理方式完全不同第一种要屏蔽 nouveau 后装驱动第二种基本不用动第三种要先查是不是被 BIOS 或 Secure Boot 拦住了。另外lspci输出的那一行里方括号里的设备 ID 也能帮你确认身份。Quadro T1000 的设备 ID 一般是10de:1fbb这个系列如果你看到的 ID 和官方对不上那就要小心是不是遇到了工程样品或者改过 BIOS 的卡这种卡在 Linux 下的驱动行为是不确定的装驱动前最好先在别的系统上验证一遍。注意虚拟机和云主机里lspci看到的 NVIDIA 设备通常是直通或者 vGPU装驱动的逻辑和物理机完全不同不要照搬本文流程否则容易把虚拟机的显示搞崩。2.2 屏蔽 nouveau 与处理 Secure Boot 的真实原因nouveau 是内核自带的 NVIDIA 开源驱动它的存在意义是“让显卡在没有商业驱动时也能显示画面”。问题在于它和商业驱动会争抢同一块硬件而且 nouveau 通常先加载。你在加载了 nouveau 的情况下装 nvidia 模块结果是两个模块抢资源轻则驱动装不上重则开机黑屏。所以要屏蔽它方法是写一个 modprobe 配置文件把这个模块拉进黑名单并且关掉它的 modeset 参数sudo tee /etc/modprobe.d/blacklist-nouveau.conf EOF blacklist nouveau options nouveau modeset0 EOF # 让配置进入 initramfs否则开机早期 nouveau 还是会被拉起来 sudo update-initramfs -u这里有个细节很多人只写blacklist nouveau忘了options nouveau modeset0然后重启之后发现lsmod | grep nouveau还是有输出就以为是屏蔽失败了。其实blacklist只是阻止它被自动加载如果某个依赖链明确要求加载它还是会被拉起来加上modeset0能让它在被加载的情况下也不接管显示等于上了双保险。执行完这两个命令后sudo reboot重启然后再执行lsmod | grep nouveau理想情况是没有任何输出lsmod | grep nvidia同样应该是空的因为还没装驱动。如果 nouveau 还在检查一下是不是有别的配置文件在作祟比如某些主板厂商的定制包会往/etc/modprobe.d/里塞东西。至于 Secure Boot这是另一个经常被忽略的坑。开启 Secure Boot 时内核只加载有签名的内核模块而 NVIDIA 的商业驱动模块默认是没有签名的。DKMS 在安装过程中会尝试用一个本机的 MOK 密钥给模块签名但这个过程在 Ubuntu 18.04 上经常需要你手动在重启时进 MOK 管理界面确认很多人直接跳过了结果就是模块编译成功了但加载失败。# 查看 Secure Boot 状态 mokutil --sb-state如果输出是SecureBoot enabled你有两个选择一是进 BIOS 把它关掉这是最简单也最推荐的做法尤其是开发机反正也不装第三方操作系统二是老老实实走 MOK 注册流程用sudo mokutil --import /var/lib/shim-signed/mok/MOK.der导入密钥重启时在蓝底界面里选 Enroll MOK输入你设的密码。我自己在这台机器上直接关了 Secure Boot省事而且后续 runfile 安装也不会被签名问题卡住。2.3 编译依赖与系统快照Ubuntu 18.04 的 apt 装驱动会走 DKMS 编译内核模块所以必须先确保编译环境和当前内核的头文件都在位否则会出现“驱动包装完了但模块没编译出来”的情况表现就是nvidia-smi报通讯失败。sudo apt update sudo apt install -y build-essential gcc make dkms \ linux-headers-$(uname -r) \ pkg-config libglvnd-dev # 确认当前内核版本后面排错要用 uname -rlinux-headers-$(uname -r)这条是关键。如果你用的是 HWE 内核18.04.5 之后默认可能是 5.4那么uname -r会返回类似5.4.0-xx-generic这样的字符串apt 会自动装对应版本的头文件。但如果你只装了linux-headers-generic这个元包它拉下来的可能是另一个版本的头文件和正在跑的内核对不上DKMS 就会编译失败。所以这里用$(uname -r)精确锁定。在做任何驱动层面的改动之前我强烈建议做一次系统快照或者至少一份关键配置备份。原因很现实驱动装崩之后最常见的状态是进不了图形界面这时候你会需要在恢复模式或者 tty 里操作如果之前没有备份你连/etc/X11/xorg.conf是不是被动过都不确定。# 备份 Xorg 配置如果存在 sudo cp -a /etc/X11/xorg.conf /etc/X11/xorg.conf.bak 2/dev/null # 备份当前已加载模块列表方便对比 lsmod ~/lsmod-before.txt # 记录当前内核与驱动包状态 dpkg -l | grep -i nvidia ~/nvidia-pkgs-before.txt uname -a ~/kernel-before.txt这几个文件看着不起眼但真出问题的时候diff一下就知道驱动到底改了哪些东西。如果系统里有重要的数据做一份完整备份再动手这一点上多花十分钟永远不亏。3. apt 仓库方式Ubuntu 18.04 上最省心的安装路径3.1 挂载 PPA 并锁定驱动版本Ubuntu 18.04 官方仓库里的 NVIDIA 驱动版本更新很慢而且不一定包含你需要的版本所以通常要加上 graphics-drivers 这个 PPA。这个 PPA 是社区维护的里面几乎涵盖了所有官方发布的 Linux 驱动分支。sudo apt install -y software-properties-common sudo add-apt-repository ppa:graphics-drivers/ppa -y sudo apt update加完之后先用ubuntu-drivers devices看看系统自己推荐哪个版本ubuntu-drivers devices输出里会列出所有兼容你显卡的驱动包其中带recommended标记的就是系统认为最合适的。但要注意推荐版本是系统根据“发行版 内核 显卡”三者算出来的不一定是最优解。比如在我这台机器上它推荐的是 470这个和我的判断一致但在某些内核较新的机器上它可能会推荐一个偏新的版本而你如果只是想要稳定选一个已验证的 LTS 分支更好。关于版本号有几个容易混淆的地方值得说清楚。nvidia-driver-470这个包名里的 470 是驱动的主分支号实际安装后nvidia-smi显示的是完整的版本号比如470.239.06后面的部分是补丁版本。同一个主分支下的补丁版本可以互相升级apt upgrade的时候会自动处理不会破坏已编译的模块跨主分支升级则是一次真正的重装需要重新编译模块也更容易出问题。所以锁定主分支很重要。驱动分支支持架构在 Ubuntu 18.04 上的表现建议390Kepler 到 Pascal太老不认识图灵核心不要用450Turing 到 Ampere 早期可用但版本偏旧只在特定依赖需要时用470Kepler 到 Ampere长期分支稳定T1000 完美支持推荐535Maxwell 到 Hopper支持较新特性可用注意老内核兼容选定之后如果系统里已经装过别的版本先清理干净再装别让两个版本的库混在一起# 查看已装的 nvidia 相关包 dpkg -l | grep -i nvidia # 彻底清理旧驱动如果有 sudo apt purge -y ^nvidia-.* ^libnvidia-.* sudo apt autoremove -yapt purge和apt remove的区别在于前者会删掉配置文件这在驱动这种“配置文件残留会引发玄学问题”的场景下非常必要。清理完先别急着重启直接接着装新驱动。3.2 执行的完整命令序列与每一步在做什么下面是这台机器上实际跑通的完整序列我按顺序解释每一步的意图。# 1. 确保依赖完整头文件与当前内核匹配 sudo apt install -y build-essential dkms linux-headers-$(uname -r) # 2. 拉取最新的包索引 sudo apt update # 3. 安装驱动主包顺便把 nvidia-settings、nvidia-utils 一起带上 sudo apt install -y nvidia-driver-470 nvidia-settings nvidia-utils-470第 3 步里nvidia-driver-470是元包它会依赖一系列具体组件内核模块走 DKMS 编译、用户态库libnvidia-gl、libnvidia-compute 等、nvidia-smi工具、以及 Xorg 的驱动模块。nvidia-settings是那个图形化的控制面板用来配多屏和性能模式nvidia-utils-470则提供了nvidia-smi等命令行工具。这三个一起装后面用起来方便。安装过程中你会看到 DKMS 在编译内核模块这一步的日志很关键。如果编译失败apt 会报错常见的失败原因是头文件版本不匹配或者 GCC 版本冲突。Ubuntu 18.04 默认的 GCC 是 7一般没问题如果你手动升级过 GCC 到 9 或更高可能会出现内核模块编译时的警告或错误这时候可以在 DKMS 配置里指定编译器路径或者干脆用回系统默认的 GCC。# 编译完成后检查 DKMS 状态 dkms status # 期望输出类似 # nvidia, 470.239.06, 4.15.0-213-generic, x86_64: installed这里的installed是关键词。如果显示built但没有installed说明模块编译出来了但没被正确安装到/lib/modules/$(uname -r)/updates/dkms/这一步会在下次内核更新时出问题。出现这种情况可以试试sudo dkms install nvidia/470.239.06 -k $(uname -r)手动装一次。装完之后需要重启。这不是建议是必须的。因为 nouveau 已经在开机时加载过新的 nvidia 模块要在下次启动、nouveau 被黑名单拦住之后才能接管硬件。重启前可以先确认一下 blacklist 文件确实存在免得白重启一次。3.3 重启后的验证与 nvidia-smi 输出解读重启之后先别急着开图形界面按 CtrlAltF3或者 F4切到 tty登录后跑几条命令验证# 1. 确认 nvidia 模块已经加载 lsmod | grep nvidia # 2. 确认 nouveau 已经被屏蔽 lsmod | grep nouveau # 应该无输出 # 3. 核心验证命令 nvidia-sminvidia-smi的输出信息量很大值得逐块解读----------------------------------------------------------------------------- | NVIDIA-SMI 470.239.06 Driver Version: 470.239.06 CUDA Version: 11.4 | |--------------------------------------------------------------------------- | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | || | 0 Quadro T1000 Off | 00000000:01:00.0 Off | N/A | | 34% 38C P8 N/A / N/A | 12MiB / 4096MiB | 0% Default | ---------------------------------------------------------------------------第一行的Driver Version是实际安装的驱动版本和你装的包主分支对得上就没问题。CUDA Version: 11.4这一行最容易引起误解——它不是说你的系统已经装了 CUDA 11.4而是说这个驱动最高支持 CUDA 11.4 的运行库。这个数字是驱动能力的上限装不装工具链是另一回事后面的章节会专门说清楚。中间那块是卡的实时状态。Temp是核心温度T1000 这种低功耗卡待机 38 到 45 度是正常的满载一般也就 70 度上下如果你看到待机就上 70那多半是风扇曲线有问题或者机箱风道太差。Perf是性能状态P8 是最低功耗档跑计算任务时会自动跳到 P0不用手动干预。Pwr:Usage/Cap这一栏在 T1000 上经常显示N/A因为这张卡没有功耗传感器上报看到 N/A 不用慌不代表驱动坏了。底下那一块是显存占用和利用率。如果这里显示No running processes found但你怀疑有进程占着显存可以用sudo fuser -v /dev/nvidia*查一下是谁在占这个命令在排查“显存被僵尸进程占住”的问题时非常有用。验证完如果还有图形界面方面的需求再跑glxinfo | grep -i OpenGL renderer正常应该输出类似Quadro T1000/PCIe/SSE2的字符串说明 OpenGL 渲染确实走的是 NVIDIA 卡而不是 CPU 软渲染。glxinfo需要先装mesa-utilssudo apt install -y mesa-utils4. runfile 方式什么时候必须用它怎么装怎么卸4.1 runfile 的适用场景与下载、校验前面说过runfile 是备选方案但有些场景它确实是唯一选择比如你需要一个 apt 仓库里没有的特定版本或者 PPA 在你的系统上因为依赖冲突装不进去。这种情况下官方.run文件就是最后的退路。下载的时候有个细节要注意官网的下载页面会根据你在页面上选的显卡型号和系统版本过滤文件但这些过滤规则有时候会漏掉老系统。文件名的格式是NVIDIA-Linux-x86_64-版本号.run比如NVIDIA-Linux-x86_64-470.239.06.run。下载完之后一定要校验这是防止文件损坏或者被中间环节篡改的必要步骤# 下载官方提供的校验和文件 wget 驱动包对应目录/NVIDIA-Linux-x86_64-470.239.06.run.sha256sum # 校验 sha256sum -c NVIDIA-Linux-x86_64-470.239.06.run.sha256sum # 赋予执行权限 chmod x NVIDIA-Linux-x86_64-470.239.06.run校验这一步我从来不会跳过。曾经有一次下载过程中断文件大小看起来正常但解压到一半报错排查了半天才发现是包本身不完整。花十几秒做校验比事后排错划算得多。注意如果你之前用 apt 装过驱动跑 runfile 之前必须先彻底清理否则两边的东西会打架。清理命令是sudo apt purge -y ^nvidia-.* ^libnvidia-.*然后sudo apt autoremove清理完重启一次再进文本模式。4.2 文本模式下安装的完整流程与选项含义runfile 安装必须在没有图形界面运行的情况下进行因为它要替换正在被 Xorg 使用的内核模块。所以流程是先切到文本模式再执行安装。# 1. 停止显示管理器切成多用户文本模式 sudo systemctl isolate multi-user.target # 2. 确认 Xorg 已经不在了 pgrep -l Xorg # 应该无输出 # 3. 运行安装程序 sudo ./NVIDIA-Linux-x86_64-470.239.06.run安装程序会问你几个问题每个问题都值得仔细回答第一个是“是否注册内核模块到 DKMS”。这里选是。选了之后DKMS 会接管模块的编译和内核升级后的重建能省掉很多麻烦。如果你不选每次内核更新之后你都要手动重跑一遍安装程序。第二个是“是否安装 32 位兼容库”。如果你的系统需要跑 32 位程序比如某些老旧的 OpenGL 应用、某些游戏选是纯粹做计算和视频处理可以不装。我一般选是因为 32 位库占不了多少空间但少装之后遇到需要的场景会很尴尬。第三个是“是否运行 nvidia-xconfig 自动生成 Xorg 配置”。如果是台式机单卡接显示器可以选是如果是笔记本双显卡或者你已经有手工维护的 xorg.conf选否让系统自己走自动配置。这一点在笔记本上尤其重要自动生成的 xorg.conf 经常会把集显也一起关掉导致进不了桌面。第四个是“是否安装 OpenGL 库覆盖 mesa 的库”。这一步在双显卡笔记本上有坑如果选是可能会把集显的 OpenGL 渲染覆盖掉导致桌面环境异常。稳妥做法是加--no-opengl-files参数跳过这一步sudo ./NVIDIA-Linux-x86_64-470.239.06.run --no-opengl-files --dkms装完之后重启然后同样跑nvidia-smi验证。如果驱动版本、温度、显存这些信息都能正常显示就说明装好了。4.3 卸载与版本切换的正确姿势runfile 最让人头疼的就是卸载不干净。很多人直接用apt purge去删结果发现删不掉因为 runfile 装的东西根本不归 apt 管。正确的卸载方式是调用安装文件自带的卸载参数# 先切到文本模式 sudo systemctl isolate multi-user.target # 用同一个版本的安装文件卸载 sudo ./NVIDIA-Linux-x86_64-470.239.06.run --uninstall注意这里必须用当初安装时用的那个文件不能随便拿另一个版本的文件来卸载否则卸载逻辑会找不到对应的文件清单删不干净。如果安装文件已经删了可以从官网重新下载同版本的文件这个问题上不要偷懒。卸载完之后还有几个残留位置需要检查# 检查残留的库文件 ls -la /usr/lib/x86_64-linux-gnu/ | grep -i nvidia ls -la /usr/lib/x86_64-linux-gnu/nvidia/ # 检查残留的 Xorg 配置 ls -la /etc/X11/xorg.conf* ls -la /etc/X11/xorg.conf.d/ # 检查残留的内核模块 ls -la /lib/modules/$(uname -r)/kernel/drivers/video/nvidia*如果发现残留手动删掉。特别是/etc/X11/xorg.conf这个文件如果它引用了已经不存在的驱动模块下次开机 Xorg 会直接启动失败表现就是黑屏加光标闪烁。删掉它之后Ubuntu 会回退到自动检测模式一般就能恢复了。从 runfile 切回 apt 驱动的路径是先--uninstall卸载重启进系统可能会用回 nouveau分辨率会变得很奇怪忍一下然后按第 3 节的流程用 apt 装。反过来从 apt 切到 runfile也要先apt purge清理再跑 runfile。两套体系之间的切换一定要走完整的清理流程不要图省事直接叠加。5. 驱动跑起来之后CUDA、ffmpeg 硬编解码与多屏输出5.1 nvidia-smi、CUDA 版本号与 toolkit 的关系别急着装全套驱动装好之后下一个绕不过去的概念就是 CUDA。这里有个特别常见的误解我必须先掰扯清楚nvidia-smi右上角显示的 “CUDA Version” 是驱动支持的最高 CUDA 运行库版本不是你已经装了 CUDA。很多人看到这个数字就以为自己有 CUDA 环境了然后去跑带 CUDA 的代码报一串libcudart.so not found白折腾半天。要真正拥有 CUDA 开发环境你需要单独安装 CUDA Toolkit它包含编译器nvcc、运行库、头文件、以及一堆样例程序。验证方式很简单# 这条命令查的是驱动能力上限 nvidia-smi | grep CUDA Version # 这条命令查的是实际安装的 toolkit 版本 nvcc --version # 或者查运行库 ls /usr/local/ | grep cuda驱动和 toolkit 的关系是向下兼容一个支持 CUDA 11.4 的驱动可以跑 11.0、11.2、11.4 的 toolkit但跑不了 11.6 的。反过来说如果你现在用 11.4 的驱动将来想升级到 CUDA 12光装新的 toolkit 是不够的必须先把驱动升上去。所以驱动版本其实决定了你这台机器的 CUDA 上限装驱动的时候应该把这个因素一起考虑进去。那么要不要装 CUDA Toolkit取决于你要干什么。如果只是跑 Python 的深度学习框架比如 PyTorch现在的主流做法是pip install的时候装带 CUDA 运行库的 wheel 包框架自带运行库不依赖系统级 toolkit你只需要一个够新的驱动就行。但如果你想自己编译 CUDA 代码、或者用到 TensorRT、cuDNN 这类需要链接的库那就必须装 toolkit。装 toolkit 的时候官方安装程序会问你要不要顺便装驱动这里一定要选否。因为你已经通过 apt 或 runfile 装好了驱动让 toolkit 再装一遍会把驱动覆盖掉而且 toolkit 自带的驱动版本可能比你装的老覆盖完就等着出问题吧。# 安装 toolkit 时只装 toolkit 本身不装驱动 sudo sh cuda_11.4.0_470.42.01_linux.run --silent --toolkit装完记得配环境变量写进~/.bashrcexport PATH/usr/local/cuda-11.4/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda-11.4/lib64:$LD_LIBRARY_PATH这里用完整版本号路径而不是/usr/local/cuda软链接是个值得养成的好习惯。因为很多机器上会同时装多个版本的 toolkit软链接指向哪个版本取决于最后一次安装用完整路径能避免“跑着跑着 toolkit 版本变了”这种诡异问题。5.2 让 ffmpeg 吃上 NVENC版本选择与验证方法T1000 虽然算力不高但它的视频编解码单元是真的实用。做视频处理的人都知道用 CPU 软编码 1080p 视频速度大概在 1x 到 3x 实时之间而用 NVENC 硬编码同样的素材能跑到 10x 以上而且 CPU 占用几乎为零。对于需要批量转码的场景这是数量级的差距。但 Ubuntu 18.04 有个坑系统仓库自带的 ffmpeg 是 3.4 版本这个版本的 Debian/Ubuntu 打包编译时没有开启 NVENC 支持。所以你把驱动装好了ffmpeg也装了跑起来还是只能软编。# 检查当前 ffmpeg 支持哪些硬件加速方式 ffmpeg -hide_banner -hwaccels # 检查编码器列表里有没有 nvenc ffmpeg -hide_banner -encoders | grep -i nvenc # 检查解码器 ffmpeg -hide_banner -decoders | grep -i nvdec如果第一条命令输出里没有cuda第二条没有任何输出说明你手上的 ffmpeg 不支持。解决办法有两个一是找一个编译时开启了 NVENC 的第三方构建二是自己编译。考虑到 Ubuntu 18.04 上编译 ffmpeg 4.x 需要一堆依赖我建议直接换一个带 NVENC 支持的构建版本。# 用支持硬件加速的构建替换系统 ffmpeg # 装好之后重新验证 ffmpeg -hide_banner -encoders | grep nvenc # 期望看到类似输出 # V..... h264_nvenc NVIDIA NVENC H.264 encoder # V..... hevc_nvenc NVIDIA NVENC hevc encoder验证通过之后实测一下转码效果ffmpeg -hide_banner -hwaccel cuda -i input.mp4 \ -c:v h264_nvenc -preset p4 -cq 23 -b:v 0 \ -c:a copy output.mp4这条命令里几个参数值得解释。-hwaccel cuda让解码也走 GPU减少 CPU 占用-preset p4是较新的 NVENC 预设命名p1 最快 p7 最慢质量最好老版本驱动可能只认slow/medium/fast这种命名报错的话换成旧命名即可-cq 23是恒定质量模式数值越小质量越高23 是个常用的平衡点-b:v 0配合 cq 使用表示不设码率上限。这套参数我在批量处理素材时用了很久速度和质量的平衡比较让人满意。提示NVENC 在并发数上有限制。消费级卡同时支持两到三路编码会话Quadro 卡的会话数限制更宽松这也是专业卡的一个隐性价值。如果你要同时跑多路转码用nvidia-smi观察一下编码器占用率别把会话占满导致新任务失败。5.3 多显示器、分辨率与 DP 链路的几个坑T1000 一般有四个 Mini-DisplayPort 或者 DP 输出接多屏是它的强项。Ubuntu 18.04 下配多屏最省事的方式是用图形化的nvidia-settingssudo nvidia-settings进去之后在 “X Server Display Configuration” 里拖拽排列屏幕位置设置分辨率和刷新率满意之后点 “Save to X Configuration File”把配置保存到/etc/X11/xorg.conf。保存这一步很关键因为不保存的话重启之后布局又回到默认的镜像模式。保存之后如果 Xorg 启动异常把那个文件删掉就能恢复这也是为什么前面强调要备份这个文件。关于分辨率有个老生常谈的问题刚装完驱动、还没配置的时候分辨率可能只有 1024x768甚至更低。这不是驱动没装好而是 Xorg 还没读到显示器的 EDID 信息。用xrandr看一下xrandr --query如果显示器的支持模式列表是空的或者只有几个低分辨率可以试试sudo nvidia-xconfig生成一个基础配置或者手动把显示器的 EDID 信息通过xrandr --newmode添加进去。不过大多数情况下只要显示器连接正常、线材没问题重启一次之后系统就能读到正确的分辨率。DP 链路这块有个特殊历史问题值得一提。早期的 DP 1.3/1.4 显示器在某些显卡上首次启动时会黑屏原因是固件版本不匹配。NVIDIA 官方为此发布过一个 DisplayPort 固件更新工具主要针对 Maxwell 和 Pascal 架构的卡。T1000 是图灵架构一般不受这个问题影响但如果你接的是一台比较新的高刷新率显示器出现“开机黑屏、插拔线材后正常”这种现象可以查一下是不是链路训练的问题试试换一根质量更好的 DP 线或者把显示器的 DP 版本手动降到 1.2。另外nvidia-settings里有个 “Force Full Composition Pipeline” 选项开启之后能显著减少画面撕裂和某些窗口管理器的闪烁问题。这个选项在专业卡上效果很明显代价是占用一点显存带宽对 T1000 这种 4GB 显存的卡来说完全无所谓建议开上。6. 故障排查速查从报错信息直接定位病因6.1 nvidia-smi 通讯失败的六种成因与对应处置NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver这句报错大概是被搜索最多的一条。它是一句笼统的失败信息背后至少对应六种完全不同的原因处理方式也不一样。可能原因判别方法处置方式驱动根本没装dpkg -l | grep nvidia无输出按第 3 节安装驱动装了但模块没加载lsmod | grep nvidia无输出检查 blacklist、Secure Boot、DKMS 状态DKMS 模块未随内核重建dkms status显示 built 而非 installed重新dkms install补装头文件nouveau 仍在占用设备lsmod | grep nouveau有输出重做 blacklist 并update-initramfs -u装了两个版本的驱动冲突dpkg -l | grep nvidia出现两个主分支全部 purge 后重装单一版本卡被其他驱动或驱动绑定错误lspci -k中 Kernel driver 为空检查 BIOS 中独显是否被禁用排查顺序上我建议从下往上查先看硬件有没有被正确识别再看模块有没有加载最后看软件包层面有没有冲突。这样能避免在一堆软件配置里绕圈子结果发现是 BIOS 里把独显关了——这种情况在品牌工作站上并不少见尤其是那些默认用集显输出的机型。还有一个容易被忽略的场景如果你是通过 SSH 远程连到这台机器上执行nvidia-smi而本机的 Xorg 正在用这张卡一般不会有问题但如果卡被某个图形会话独占偶尔会出现权限相关的报错。这时候加sudo试试能跑通就说明是权限问题需要把用户加到video组里sudo usermod -aG video $USER6.2 黑屏、循环登录与 GLX 模块加载失败装驱动之后进不了桌面是另一类高频问题症状通常有三种全黑只有光标、卡在登录界面输入密码后又弹回来、以及能进桌面但没有窗口管理器。这三种的成因和处置方式不太一样。全黑的情况第一件事是切 tty 看看系统是否还活着。按 CtrlAltF3如果能出现登录提示说明系统没死只是图形界面起不来。这时候看 Xorg 日志# 查看最近的 Xorg 日志 tail -n 100 /var/log/Xorg.0.log # 或者用 grep 过滤错误 grep -i (EE) /var/log/Xorg.0.log日志里出现failed to load module glxserver_nvidia是最典型的症状说明 Xorg 找到了 NVIDIA 的驱动模块但加载失败了。原因通常是 libglx 和驱动模块版本不匹配最常见于 runfile 和 apt 混装的场景。处置办法是彻底清理后重装单一体系的驱动# 切到文本模式 sudo systemctl isolate multi-user.target # 清理 sudo apt purge -y ^nvidia-.* ^libnvidia-.* sudo apt autoremove -y # 删掉可能残留的手工安装文件 sudo rm -f /usr/lib/x86_64-linux-gnu/libGLX_nvidia* sudo rm -f /usr/lib/x86_64-linux-gnu/nvidia/glxserver_nvidia* # 删掉 xorg.conf让 Xorg 回到自动探测 sudo rm -f /etc/X11/xorg.conf sudo reboot循环登录的情况除了驱动本身的问题还有一个常见诱因是~/.Xauthority文件权限不对或者磁盘满了导致会话无法写入。检查一下ls -la ~/.Xauthority df -h /.Xauthority的属主应该是当前用户权限 600。如果属主是 root比如之前用过sudo startx改回来就行。磁盘满了的情况在老开发机上很常见尤其是/var/log和/tmp塞满了东西du -sh /var/log/* | sort -h看一下就知道。还有一种情况是能进桌面但特别卡glxinfo显示渲染器是llvmpipe说明 OpenGL 回退到 CPU 软渲染了NVIDIA 的 GLX 库没生效。这通常发生在笔记本双显卡场景检查/etc/X11/xorg.conf里是不是把 NVIDIA 设备写死了或者用prime-select切换一下# 查看当前使用的显卡 prime-select query # 切换到独显 sudo prime-select nvidia # 切换后需要重启 sudo reboot6.3 内核升级导致驱动失效的根治方案这台机器上最让人恼火的一类故障是昨天还好好的今天开机nvidia-smi就报通讯失败什么都没改就是系统自动升级了内核。原因很简单Ubuntu 每次内核升级/lib/modules/新内核版本/目录是全新的之前为旧内核编译的 NVIDIA 模块不在里面。DKMS 会在内核升级时自动触发重建但这个自动触发有几个前提条件缺一个就会失败。第一DKMS 服务本身要正常。检查systemctl status dkms如果有异常先修。第二新内核对应的头文件包要已经装好。如果你平时用apt upgrade但没装linux-headers-generic这个元包升级内核时头文件不会跟着装DKMS 就拿不到头文件编译必然失败。第三DKMS 的构建日志里没有报错。根治的办法是确保三件事# 1. 装好头文件的元包跟着内核一起升级 sudo apt install -y linux-headers-generic # 2. 如果是 HWE 内核装对应的元包 sudo apt install -y linux-headers-generic-hwe-18.04 # 3. 装完驱动后确认 DKMS 状态 dkms status如果你已经处于内核升级后驱动挂掉的状态最快的恢复方式是在 GRUB 里选旧内核启动开机时按住 Shift 或者反复按 Esc 调出菜单选 “Advanced options”然后选一个旧的内核版本进系统后重新装一遍驱动或者手动 DKMS 重建# 查看有哪些内核 dpkg -l | grep linux-image # 为当前内核重建模块 sudo dkms install nvidia/470.239.06 -k $(uname -r) # 如果还是不行删掉重新构建 sudo dkms remove nvidia/470.239.06 --all sudo dkms install nvidia/470.239.06 -k $(uname -r)长期跑的开发机我建议直接禁用自动内核升级把升级节奏控制在自己手里。方法是编辑/etc/apt/apt.conf.d/20auto-upgrades把Unattended-Upgrade关掉或者用apt-mark hold把内核包锁住# 查看当前内核包 dpkg -l | grep linux-image # 锁定内核版本不随升级变动 sudo apt-mark hold linux-image-generic linux-headers-generic锁内核是个双刃剑好处是稳定坏处是安全更新也一起停了。我的做法是锁定主版本但每个月手动安排一次升级窗口升级前先确认 DKMS 能正常重建在测试环境验证一遍再上生产机。7. 一些个人经验和收尾建议7.1 版本配对与备份习惯这几年前前后后装过十几台带 NVIDIA 卡的 Ubuntu 机器最深的体会是驱动、内核、CUDA 三者的版本配对比任何一个单独组件的版本都重要。一次典型的翻车场景是这样的你为了跑一个新模型把 CUDA 升到了 12结果发现驱动版本不够于是升驱动升完驱动发现新的驱动和当前内核的 DKMS 不兼容编译失败为了解决编译失败你把内核也升了然后发现新内核和你的无线网卡驱动不兼容连不上网了。整个链条上每一步都是合理的但组合起来就是把机器搞死。所以我的建议是先把当前所有关键版本号记录下来形成一张“版本矩阵”每次只改一个变量改完验证通过再动下一个。这张矩阵大概长这样Ubuntu 18.04.6 LTS 内核 4.15.0-213-generic 驱动 470.239.06 CUDA 11.4 cuDNN 8.2.4 ffmpeg 4.4 (nvenc enabled)这张表可以写在便利贴上贴机箱侧面也可以存成文件。它的价值在半年后就会体现出来那时候你已经忘了当初装的是哪个版本而某天系统出问题时这张表就是唯一的参照物。备份方面除了系统级备份我更推荐把“恢复所需的最小信息”单独存一份。实际上大部分驱动故障的恢复只需要知道正确版本号、能进 tty、有一份清理和重装命令的清单。我会把这些命令写成一个 shell 脚本放在/opt/下面出问题的时候直接跑省得在手机上手忙脚乱地查。7.2 长期维护的几点提醒最后说几点这台机器跑了这么久之后总结出来的日常维护心得都是些小事但能省不少麻烦。一是定期看一眼nvidia-smi的温度和dmesg里的 Xid 报错。Xid 错误是 NVIDIA 驱动上报的硬件或驱动异常码比如 Xid 79 表示 GPU 掉线Xid 13 表示图形引擎异常。平时没事的时候扫一眼dmesg | grep -i xid没有输出是最好的有输出就去查对应的错误码含义。提前发现能避免某天突然整机不显示。二是显存占用要留意。4GB 显存对现在的模型来说确实不宽裕跑多进程任务时很容易被某个僵尸进程占住不放。养成习惯用fuser -v /dev/nvidia*检查发现占了就清理掉别等到新任务分配显存失败才想起来。三是别轻易动 Xorg 配置。这台机器稳定运行的这两年我唯一做的配置改动就是通过nvidia-settings保存了一次多屏布局其他时间xorg.conf都没有动过。很多人喜欢手动改这个文件去优化渲染结果是引入了各种玄学问题。能用自动检测解决的就别手工介入。四是如果要长期跑 7x24 任务用nvidia-smi -pm 1开启持久化模式。默认情况下GPU 在没有任务时会卸载驱动状态下次调用需要重新初始化多卡环境下这个开销明显。开启持久化模式后驱动一直保持加载状态调用延迟会降低。这个设置在重启后会失效要写进开机脚本。五是老系统上的浏览器和 Electron 类应用如果开启硬件加速后频繁闪崩可以试着在启动参数里加上--disable-gpu-sandbox或者干脆关掉硬件加速。这类问题和 NVIDIA 驱动的 GPU 沙箱实现有关在 470 分支上偶有出现不算严重但确实影响使用体验。这台机器到现在还在跑驱动一直停在 470中间换过一次硬盘顺手做了次完整重装其余时间没有出过需要重装驱动的故障。一套稳定的环境价值不在于它有多新而在于它不给你添麻烦。把版本钉死、把备份做好、把排查命令存起来剩下的时间就可以安心写代码了。
返回列表