Ubuntu 24.04 + RTX 5090:NVIDIA 595.71.05 被 unattended-upgrades 自动升级到 595.84,导致驱动版本漂移的排查与恢复
背景之前我已经遇到过一次 RTX 5090 在 Ubuntu 24.04 下的 NVIDIA 驱动稳定性问题。当时的结论是595.84-open下出现过 PCIe AER Fatal、Xid 79、GPU fallen off the bus回退到595.71.05-open后恢复稳定原计划对 NVIDIA 相关包执行apt-mark hold但后来发现当时实际上并没有真正执行 HOLD这次系统再次出现异常迹象后最终确认Ubuntu 的 unattended-upgrades 在后台把 NVIDIA 595.71.05 自动升级到了 595.84。更有意思的是由于机器一直没有重启因此出现了一个非常典型的状态RAM 中正在运行的 NVIDIA 驱动595.71.05 磁盘上下一次准备加载的驱动595.84这篇记录完整整理一下排查和恢复过程。一、发现 unattended-upgrades 自动升级了 NVIDIA 驱动首先检查/var/log/unattended-upgrades/unattended-upgrades.log发现 2026-08-12 的日志2026-08-12 06:15:34,945 INFO Starting unattended upgrades script 2026-08-12 06:15:34,960 INFO Allowed origins are: oUbuntu,anoble, oUbuntu,anoble-security, oUbuntuESMApps,anoble-apps-security, oUbuntuESM,anoble-infra-security 2026-08-12 06:15:40,568 INFO Packages that will be upgraded: libnss-systemd libnvidia-cfg1-595 libnvidia-common-595 libnvidia-compute-595 libnvidia-decode-595 libnvidia-encode-595 libnvidia-extra-595 libnvidia-fbc1-595 libnvidia-gl-595 libpam-systemd libsystemd-shared libsystemd0 libudev1 nvidia-compute-utils-595 nvidia-dkms-595-open nvidia-driver-595-open nvidia-kernel-common-595 nvidia-kernel-source-595-open nvidia-utils-595 systemd systemd-dev systemd-resolved systemd-sysv systemd-timesyncd udev xserver-xorg-video-nvidia-595 2026-08-12 06:18:21,652 INFO All upgrades installed这已经可以直接确认不是手工执行apt upgrade导致而是 unattended-upgrades 自动升级了整套 NVIDIA 595 驱动。其中最关键的包包括nvidia-driver-595-open nvidia-dkms-595-open nvidia-kernel-source-595-open nvidia-kernel-common-595 nvidia-utils-595 libnvidia-compute-595 libnvidia-gl-595二、最关键的现象RAM 是 595.71.05磁盘已经变成 595.84执行cat/proc/driver/nvidia/version modinfo-Fversion nvidia得到NVRM version: NVIDIA UNIX Open Kernel Module for x86_64 595.71.05 ... 595.84这两个结果看似矛盾其实非常关键。/proc/driver/nvidia/version表示当前已经加载进内核、正在运行的 NVIDIA 模块版本。当前结果595.71.05modinfo -F version nvidia表示磁盘上当前modinfo能找到的 NVIDIA 内核模块版本。当前结果595.84于是当时机器的真实状态其实是当前 RAM 595.71.05 磁盘 595.84原因很简单系统原本启动时加载的是 595.71.05unattended-upgrades 在机器运行期间升级了 NVIDIA 软件包磁盘文件已经被替换成 595.84但 Linux 不会自动把正在运行的内核模块替换掉所以 RAM 中仍然保留 595.71.05这个时候最重要的一件事情就是不要急着 reboot。如果直接重启当前 RAM 中最后还在工作的 595.71.05 会消失系统下一次就会加载磁盘上的 595.84。三、确认 Ubuntu 仓库已经只提供 595.84执行apt-cachemadison\nvidia-driver-595-open\nvidia-dkms-595-open\nvidia-kernel-source-595-open\nvidia-kernel-common-595\nvidia-compute-utils-595\nvidia-utils-595\libnvidia-compute-595\libnvidia-gl-595得到的版本全部已经是595.84-0ubuntu0.24.04.1来源包括noble-updates noble-security说明旧的595.71.05-0ubuntu0.24.04.1已经不能直接从当前 APT 仓库重新安装。四、幸运的是APT 缓存里还保留完整的 595.71.05执行find/var/cache/apt/archives-maxdepth1\-typef-name*595.71.05*.deb\-printf%f\n|sort发现旧版本.deb全部还在libnvidia-cfg1-595_595.71.05-0ubuntu0.24.04.1_amd64.deb libnvidia-common-595_595.71.05-0ubuntu0.24.04.1_amd64.deb libnvidia-compute-595_595.71.05-0ubuntu0.24.04.1_amd64.deb libnvidia-decode-595_595.71.05-0ubuntu0.24.04.1_amd64.deb libnvidia-encode-595_595.71.05-0ubuntu0.24.04.1_amd64.deb libnvidia-extra-595_595.71.05-0ubuntu0.24.04.1_amd64.deb libnvidia-fbc1-595_595.71.05-0ubuntu0.24.04.1_amd64.deb libnvidia-gl-595_595.71.05-0ubuntu0.24.04.1_amd64.deb nvidia-compute-utils-595_595.71.05-0ubuntu0.24.04.1_amd64.deb nvidia-dkms-595-open_595.71.05-0ubuntu0.24.04.1_amd64.deb nvidia-driver-595-open_595.71.05-0ubuntu0.24.04.1_amd64.deb nvidia-firmware-595-595.71.05_595.71.05-0ubuntu0.24.04.1_amd64.deb nvidia-kernel-common-595_595.71.05-0ubuntu0.24.04.1_amd64.deb nvidia-kernel-source-595-open_595.71.05-0ubuntu0.24.04.1_amd64.deb nvidia-utils-595_595.71.05-0ubuntu0.24.04.1_amd64.deb xserver-xorg-video-nvidia-595_595.71.05-0ubuntu0.24.04.1_amd64.deb一共 16 个。这就给了一个非常好的恢复窗口RAM 中还跑着稳定的 595.71.05同时本地缓存又完整保留了旧版本安装包。五、先把旧版驱动包单独备份为了避免以后执行aptclean导致这些旧包被删除先永久备份mkdir-p/root/nvidia-595.71.05-debscp-av/var/cache/apt/archives/*595.71.05*.deb\/root/nvidia-595.71.05-debs/确认find/root/nvidia-595.71.05-debs\-maxdepth1-name*.deb|wc-l结果16以后即使 Ubuntu 仓库完全不再提供 595.71.05也可以直接使用本地包恢复。六、先模拟降级不要直接安装先执行模拟apt-sinstall--allow-downgrades\/root/nvidia-595.71.05-debs/*.deb主要检查两件事1. NVIDIA 包是否全部从 595.84 降级到 595.71.05预期595.84-0ubuntu0.24.04.1 ↓ 595.71.05-0ubuntu0.24.04.12. 有没有误删除大量无关软件包如果只是 NVIDIA 595 软件栈的正常 downgrade就可以继续。七、真正执行 595.84 → 595.71.05 降级执行aptinstall--allow-downgrades\/root/nvidia-595.71.05-debs/*.deb这里使用 APT 安装本地.deb而不是简单执行dpkg-i*.deb主要是为了让 APT 正确处理各包之间的依赖关系。整个过程中不要 reboot 不要 rmmod nvidia 不要 modprobe nvidia 不要 apt upgrade 不要 apt full-upgrade因为当前内存里还运行着正常的 595.71.05没有必要主动破坏这个状态。八、降级后确认 RAM 和磁盘重新一致再次检查cat/proc/driver/nvidia/version modinfo-Fversion nvidia目标状态/proc/driver/nvidia/version 595.71.05 modinfo -F version nvidia 595.71.05也就是RAM 595.71.05 Disk 595.71.05再检查dkms status|grep-invidia以及dpkg-query-W-f${binary:Package}\t${Version}\n|grep-Envidia|libnvidia|grep595|sort主要驱动组件应该全部恢复到595.71.05-0ubuntu0.24.04.1九、这次一定执行 HOLD上一次最大的问题不是没有解决而是解决之后忘了锁版本。因此这次确认降级完成后立即执行apt-mark hold\nvidia-driver-595-open\nvidia-dkms-595-open\nvidia-kernel-source-595-open\nvidia-kernel-common-595\nvidia-compute-utils-595\nvidia-utils-595\libnvidia-cfg1-595\libnvidia-common-595\libnvidia-compute-595\libnvidia-decode-595\libnvidia-encode-595\libnvidia-extra-595\libnvidia-fbc1-595\libnvidia-gl-595\xserver-xorg-video-nvidia-595验证apt-mark showhold|grep595|sort这一步非常重要。因为 APT 现在仍然会认为Installed: 595.71.05 Candidate: 595.84但只要处于 HOLD 状态正常的 unattended-upgrades 就不会再把这些软件包自动更新回 595.84。十、最终重启验证所有检查完成后进行了正常 reboot。重启之后执行cat/proc/driver/nvidia/version modinfo-Fversion nvidia nvidia-smi dkms status|grep-invidia最终全部正常。也就是说系统已经真正完成595.84 落盘 ↓ 本地 .deb 降回 595.71.05 ↓ DKMS 恢复 595.71.05 ↓ HOLD NVIDIA 软件包 ↓ reboot ↓ 重新加载 595.71.05 ↓ GPU 正常至此恢复完成。十一、一个额外现象PCIe replay error 累计到 3009但模型仍稳定这两天运行大模型时还注意到一个现象# gpu rxpci txpci sbecc dbecc pci # Idx MB/s MB/s errs errs errs 0 0 2 - - 3009 0 0 0 - - 3009这里最后一列pci errs可以理解为 PCIe replay 相关的累计计数。比较重要的是3009 3009 3009数值虽然不为 0但已经不继续增长。这和之前的AER: Uncorrectable (Fatal) Xid 79 GPU has fallen off the bus不是同一个严重程度。PCIe 本身有链路层重传机制所以可能出现PCIe 传输出现错误 ↓ 链路自动 replay ↓ 重传成功 ↓ CUDA / 大模型任务继续正常因此单纯看到一个比较大的累计值并不等于当前仍然存在持续故障。相比绝对值我更关注的是这个值是否继续增长。例如3009 3009 3009 3009比3009 3200 3800 5000健康得多。后续可以持续观察nvidia-smi dmon-i0-set-d10-oT同时监控内核journalctl-k-f|grep--line-buffered-EiAER|NVRM|Xid|PCIe|fallen off目前实际情况是大模型持续稳定运行 PCIe replay 计数没有继续明显上涨 没有新的 Xid 79 没有 GPU fallen off bus所以目前继续使用 595.71.05。十二、这次问题的完整时间线整个过程可以总结为最初使用 595.84 ↓ PCIe AER Fatal / Xid 79 GPU fallen off the bus ↓ 回退 595.71.05 ↓ 系统恢复稳定 ↓ 当时忘记执行 apt-mark hold ↓ 2026-08-12 06:15 unattended-upgrades 自动启动 ↓ 整套 NVIDIA 595 被自动升级到 595.84 ↓ 由于机器没有重启 RAM 中仍然是 595.71.05 磁盘已经是 595.84 ↓ 发现 /proc 595.71.05 modinfo 595.84 ↓ 幸好 /var/cache/apt/archives 仍保留完整 595.71.05 deb ↓ 本地整套 downgrade ↓ RAM 595.71.05 Disk 595.71.05 ↓ apt-mark hold ↓ reboot ↓ 595.71.05 正常加载 ↓ 目前系统和大模型运行稳定十三、这次最大的经验1. 驱动回退成功后一定记得 HOLD解决问题不代表事情结束。如果仓库中的 Candidate 仍然是问题版本而 unattended-upgrades 又正常开启那么迟早可能再次自动升级。检查apt-mark showhold应该成为回退驱动之后的固定步骤。2./proc和modinfo同时检查非常有用只看nvidia-smi可能无法及时发现磁盘上的驱动已经被后台升级。以后遇到类似情况可以直接cat/proc/driver/nvidia/version modinfo-Fversion nvidia如果两个版本不同/proc old modinfo new基本就说明驱动软件包已经在运行期间发生变化但当前内核仍然加载旧模块。这个状态下尤其要慎重 reboot。3. 不要随便清理/var/cache/apt/archives这次能够快速恢复最大的幸运就是595.71.05 的全部 .deb 还在对于生产环境里已经验证稳定、但仓库可能随时淘汰的 NVIDIA 驱动版本建议直接另外存一份/root/nvidia-595.71.05-debs/以后恢复会简单很多。4. 不建议为了锁 NVIDIA 而关闭全部 unattended-upgradesunattended-upgrades本身仍然负责 Ubuntu 的很多正常安全更新。更合理的方式是系统安全更新继续 已知不稳定的 NVIDIA 驱动单独 HOLD而不是一刀切关闭全部自动安全更新。最终状态目前系统OS : Ubuntu 24.04 GPU : NVIDIA GeForce RTX 5090 Driver : 595.71.05 Open Kernel Module RAM : 595.71.05 Disk : 595.71.05 DKMS : 595.71.05 APT HOLD : 已配置 Reboot : 已完成 CUDA/LLM : 正常稳定运行这次问题最终不是一个新的 GPU 硬件故障而是之前修复之后漏掉了最后一个非常重要的步骤HOLD。导致 unattended-upgrades 在 2026-08-12 又把 595.84 自动装了回来。好在发现时机器还没有重启旧的 595.71.05 内核模块仍然存活在 RAM 中同时 APT cache 里也保留了完整旧包因此最终顺利恢复。

相关新闻

docker-android 重启后镜像起不来

docker-android 重启后镜像起不来

问题现象 使用 budtmo/docker-android:emulator_14.0 首次启动正常,但 docker restart 之后只有 VNC 背景,Android 系统不再启动。 相关 issue: https://github.com/budtmo/docker-android/issues/476 根因 cli/src/device/emulator.py 的 change_permis…

2026/10/6 15:10:04 阅读更多 →
澳大利亚NAATI翻译认证是什么?NAATI翻译认证渠道怎么选择?如何办理?

澳大利亚NAATI翻译认证是什么?NAATI翻译认证渠道怎么选择?如何办理?

【办理材料】准备需要翻译文件清晰照片或者扫描件,保证印章、编号完整无遮挡。【办理渠道】慧办好小程序、NAATI官网持证译员。【通用流程】选好正规办理渠道,提交电子版文件,确认翻译类型,完成付费对接,等待出件&…

2026/10/4 4:07:32 阅读更多 →
从IT运维角度聊聊东莞复印机租赁的选型问题

从IT运维角度聊聊东莞复印机租赁的选型问题

做企业IT运维的都知道,办公文印设备的选型是个容易被低估的坑。最近群里好几个同行在讨论一个话题:预算有限的情况下,东莞复印机租赁是不是只能选翻新机? 从技术角度说,这个结论完全不成立。 先看翻新机的本质&#xf…

2026/10/10 14:20:49 阅读更多 →

最新新闻

数据库实验报告书写作全攻略:环境配置、查询索引与事务验证

数据库实验报告书写作全攻略:环境配置、查询索引与事务验证

简介:《zzu数据库实验报告书》是一份面向计算机科学与技术、软件工程专业学生的数据库系统原理课程实验合集,围绕openGauss数据库环境,依次覆盖认识DBMS、创建数据库表与索引、交互式SQL语句、创建视图、完整性与安全性控制、事务与并发控制、…

2026/10/13 17:42:06 阅读更多 →
PaperSpine 逻辑转移审计(Logic Transfer Audit):验证论文改写是否真正改变了论证逻辑

PaperSpine 逻辑转移审计(Logic Transfer Audit):验证论文改写是否真正改变了论证逻辑

AI 技能AI 写作人工智能深度研究AI 应用 【免费下载链接】PaperSpine PaperSpine5 — local-first, evidence-bound paper research, writing, figures, review and delivery. Download: https://wubing2023.github.io/PaperSpine/v5/ 项目地址: https://gitcode.co…

2026/10/13 17:42:06 阅读更多 →
深搜剪枝实战:Addition Chains 加法链问题精讲

深搜剪枝实战:Addition Chains 加法链问题精讲

1. 从一道经典题看深搜剪枝的真正价值Addition Chains,中文常译为“加法链”,是一道在算法竞赛圈子里流传很久的搜索入门题。题目本身不复杂:给定一个整数 n,要求构造一个从 1 开始的序列,序列中每个数都等于前面某两个…

2026/10/13 17:42:06 阅读更多 →
移动端数据采集实战:Fiddler抓包与今日头条接口还原

移动端数据采集实战:Fiddler抓包与今日头条接口还原

1. 移动端数据采集的底层逻辑与方案选型1.1 为什么移动端采集比网页采集更棘手做过网页采集的人第一次转向移动端时,往往会有一个错觉:不就是换个请求地址吗?实际上,移动端的数据采集难度比网页端高出一个量级。网页端你打开开发者…

2026/10/13 17:42:06 阅读更多 →
DeepSeek 学习手册:用推理链与长上下文构建可控学习助手

DeepSeek 学习手册:用推理链与长上下文构建可控学习助手

简介:这份《DeepSeek中小学生使用手册》面向小学到高中的学生及家长,聚焦如何借助DeepSeek这一AI教育助手提升学习效率与成长质量。内容围绕四大板块展开:向DeepSeek提问的十大原则、阅读能力提升方法、英语与数学学科的具体应用,…

2026/10/13 17:42:06 阅读更多 →
ISaGRAF 3.4老牌IEC 61131-3开发环境安装编程与迁移全攻略

ISaGRAF 3.4老牌IEC 61131-3开发环境安装编程与迁移全攻略

简介:ISaGRAF 3.4编程软件压缩包,面向工业自动化控制系统的开发与调试工程师,尤其适合基于IEC 61131-3标准构建PLC、运动控制或过程控制项目的团队。软件支持IL、ST、FBD、LD、SFC五种标准编程语言,兼顾不同场景的编程习惯&#x…

2026/10/13 17:41:05 阅读更多 →

日新闻

物联网系统集成避坑指南:从选型到验收的关键要点

物联网系统集成避坑指南:从选型到验收的关键要点

做了这么多年物联网系统集成的项目,我最大的感受是,大部分坑不是出在技术前沿,而是出在一些看起来很平常的地方。设备选了便宜的、协议没问清楚、现场没摸透、验收标准写得含糊——这些细枝末节,最后都会变成延期、超支和扯皮的大…

2026/10/13 0:00:57 阅读更多 →
ESP32舵机控制全攻略:从PWM原理到高级玩法与常见故障排查

ESP32舵机控制全攻略:从PWM原理到高级玩法与常见故障排查

如果你玩ESP32有一阵子了,很难不碰到舵机控制这道坎。做智能小车要转方向,做机械臂要抬关节,做云台要偏航俯仰,背后都是同一个东西在干活:舵机。而我见过太多人卡在“代码能编译、舵机就是不听话”这个阶段&#xff0c…

2026/10/13 0:00:57 阅读更多 →
CAN总线原理与STM32实战:抗干扰、仲裁、错误处理全解析

CAN总线原理与STM32实战:抗干扰、仲裁、错误处理全解析

1. 为什么CAN总线至今仍是工业现场的“硬通货”?——从汽车底盘到智能温室的真实需求你有没有拆过一辆老款燃油车的中控台?或者调试过某高校实验室里那台跑着Modbus协议却频频丢帧的PLC控制柜?又或者,在某个农业物联网项目里&…

2026/10/13 0:00:57 阅读更多 →

周新闻

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

简介:基于 ARIMA、LSTM、Transformer 等模型的流感时间序列预测 Python 源码,面向计算机相关专业课程设计与期末大作业学生,以及项目实战学习者。内容覆盖预处理、平稳性检验、定阶、残差分析、多模型对比预测的完整时序建模流程,…

2026/10/13 2:54:56 阅读更多 →
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别 做影刀RPA自动化,十个新手有八个栽在"往输入框里填东西"这件事上:要么填不进去,要么填了一半,要么直接把原来内容追加在后面。这背后的根因&…

2026/10/13 16:22:04 阅读更多 →
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容 1. 认识影刀:什么场景该用RPA采小说数据 起点中文网的页面结构相对稳定——分类榜单、书籍详情、章节内容三块独立页面,跳转链路清晰。这种场景非常适合影刀自动化&#x…

2026/10/13 1:58:08 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/12 21:05:09 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/13 14:57:39 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/12 18:11:17 阅读更多 →