一次机械臂 Linux 工控机黑屏故障的排查与恢复

问题背景

在实验室调试过程中，这个机械臂的 Linux 工控机突然出现了显示器已经通电、但系统无法正常点亮屏幕的情况。由于这台工控机承担着机械臂后续开发工作，问题并不只是“能否重新进入桌面”这么简单：如果直接重装系统，原有的开发环境、内核配置和本地数据都可能受到影响。

因此，这次处理的重点有两个：一是判断故障究竟来自硬件、内核还是显卡驱动；二是在确实需要重装之前，尽可能保护已有数据和开发环境。

第一反应：不要急着覆盖硬盘

最初从厂家技术支持处得到的建议包括检查显示器、先进行放电，以及在仍然无法恢复时考虑重新安装 Linux 系统。现场也尝试更换了一台显示器，但黑屏问题并没有因此解决。随后完成放电操作，显示问题仍然存在，重装系统似乎成为一个可行选项。

但对于用于机器人和工控开发的设备来说，直接覆盖硬盘通常应该是最后的方案。

当前工程代码已经通过 Git 在云端保存了一部分备份，因此代码本身并不是唯一需要保护的内容。更容易在重装过程中丢失的，往往是以下这些本地环境：

• ROS 开发环境及其依赖；
• 系统和用户级配置；
• 自行编译或编写的内核；
• 内核模块、驱动和相关编译环境；
• 尚未提交到远端的实验数据与临时文件。

如果确实需要重装，比较稳妥的顺序应当是先抢救数据，再考虑系统重建。这台工控机使用的是 M.2 硬盘，可以准备一个对应规格的 M.2 硬盘盒，将硬盘中的重要数据复制出来，或者先制作完整备份。这样即使后续必须覆盖系统，也能把开发进度和环境恢复工作控制在可接受范围内。

从启动过程判断故障范围

进一步查看开机过程中的启动信息后，可以看到 GRUB 菜单能够正常显示，并且能够进入内核启动过程。启动画面中可以看到内核和初始内存盘（initial ramdisk）正在加载，但随后显示器仍然无法正常进入系统界面。结合此前的经验，曾经考虑过一种可能：自行编写的实时内核存在问题，导致系统无法正常初始化显卡。

这台设备中存在两个可供启动的内核：

• 默认内核 7.0.0-34-generic；
• 自行编写的实时内核 6.8.1-1015-realtime。

通过 GRUB 选择不同内核进行启动后，两个内核都出现了类似的显示问题。这个结果降低了“单个实时内核损坏”这一假设的可信度，也说明问题未必只发生在实时内核本身。

当不同内核表现出相同故障时，排查范围应当继续向共同依赖的部分收缩。此时，显卡硬件、显卡驱动以及图形启动配置就成为更值得关注的方向。

排查结论：显卡驱动相关问题

综合启动现象和不同内核下的结果，最终基本确定故障大概率与显卡驱动有关，而不是某一个内核单独导致的问题，也没有足够证据表明硬盘或其他核心硬件已经损坏。

这一步判断很重要：如果在没有完成故障定位的情况下直接重装系统，虽然可能暂时恢复设备，但也可能掩盖真正原因，并带来重新配置整个开发环境的额外成本。

解决过程

随后在 GRUB 中对启动项进行临时编辑。具体来说，选中 Ubuntu, with Linux 7.0.0-34-generic 启动项，按下 e 进入编辑界面，在以 linux 开头的启动行中删除末尾的 quiet splash，并追加参数：

nomodeset

例如，原本以 ro 等参数结尾的启动行，可以在末尾增加一个空格后写入 nomodeset。完成编辑后，使用 Ctrl + X 或 F10 启动本次修改后的配置。这种方式只影响当前这一次启动，不会直接修改系统中的永久配置。

nomodeset 会暂时禁止显卡驱动进行内核模式设置，改用最基础的显示路径启动系统。它适合用于判断黑屏是否与显卡驱动初始化有关，但不应被视为长期的显卡驱动解决方案。

调整后，系统能够正常进入，显示器也重新点亮。由此可以确认，问题与显卡驱动初始化或图形模式设置存在直接关系，系统本身并不需要立即通过重装来恢复。

在系统恢复后，再对相关驱动进行进一步排查，比在无法进入系统的状态下直接重装更加稳妥，也能尽量保留原有开发环境。

这次故障带来的经验

1. 重装系统不应当是默认的第一步

重装系统可以解决一部分系统级问题，但它同时会改变大量环境状态。对于已经投入使用的开发设备，应该先判断问题范围，并优先尝试可逆的修复方式。

2. 代码备份不等于环境备份

Git 只能覆盖已经提交和推送的代码。ROS 工作空间、系统依赖、内核、驱动、配置文件以及实验数据，同样需要纳入备份和恢复计划。

3. 不同内核下的相同现象具有排除价值

通过 GRUB 选择多个内核进行对照启动，可以帮助判断问题是否只存在于某一个内核。如果多个内核都出现同样的显示故障，就应当进一步检查它们共同依赖的显卡驱动和图形启动配置。

4. 先恢复可用状态，再做深入分析

用基础启动模式让系统重新进入，是一次有效的故障隔离。恢复可用状态后，再借助 Agent 或其他工具排查驱动问题，通常比在完全无法进入系统的状态下反复尝试更高效。

小结

这次机械臂 Linux 工控机黑屏问题，表面上看像是系统无法启动，最初也曾考虑过显示器、实时内核或其他硬件故障。更换显示器没有解决问题后，再通过数据保护、不同内核对照启动和基础模式验证，最终将范围收缩到了显卡驱动相关配置，并在不重装系统的情况下恢复了显示。

对于承担机械臂开发任务的工控机，遇到类似问题时，可以按照下面的顺序处理：

1. 先保护数据和本地开发环境；
2. 区分显示器、显卡驱动、内核和其他硬件问题；
3. 使用 GRUB 对不同内核进行对照；
4. 临时编辑启动行，使用 nomodeset 等可逆方式验证图形驱动假设；
5. 最后再评估是否需要重装系统。

这次故障也提醒我们，开发设备的可恢复性和环境备份，与代码本身的版本管理同样重要。