UEFI裸机硬件自检工具：21项测试设计与实践解析-育师

干过机房运维的朋友应该都懂这个场景：新到一批裸金属服务器，得上架、加电、装系统，但最怕的不是装机慢，而是装到一半发现硬件有问题。内存报错、硬盘掉盘、网卡不识别，这种问题在系统层面排查特别恶心，日志看不出来，厂商诊断工具又要单独跑一遍，耗时又费劲。我自己也是被坑了好几次之后，干脆写了一个运行在 UEFI 环境下的整机自检工具，把 CPU、内存、存储、网络、外设全部过一遍，一共 21 项测试，全程图形化界面，跑完一键导出报告。这篇文章就把这个工具的思路、设计、实现细节和踩坑经历完整分享一下，给同样被裸金属硬件排障折磨的朋友一个参考。

这个工具目前是完全免费的，我平时自己机房排查、新机器验收都在用，也会给朋友拷一份应急。它的定位很简单：不需要装系统、不需要进 Linux，只要主板支持 UEFI，插上启动 U 盘就能跑。对运维、服务器管理员、DIY 装机玩家来说，等于随身带了一个硬件体检仪。

1. 为什么需要一个“裸机自检”工具

1.1 裸金属排障的真实场景

先说一个我自己的真实经历。有次机房进了一批二手的 1U 服务器，供应商说全部测过没问题。结果上架之后，连续三台机器装 CentOS 装到一半直接 crash，一开始怀疑是系统镜像坏了，换了镜像还是一样。后来用厂商自带的诊断工具逐台跑，折腾了整整一天，最后发现是三台机器的内存插槽有问题，其中一根内存没被正确识别。

这个事让我印象特别深。因为内存问题在 Linux 下不是不能查，memtest86+也能跑，但问题是这批服务器没有 IPMI 远程控制台，我只能一台台接显示器、插键盘，在 BIOS 界面和命令行工具之间反复切换。而且 memtest86+ 跑完一轮要几个小时，根本没那个时间逐台等。如果当时有一个 UEFI 下的一体化自检工具，20 分钟跑完 21 项测试，直接定位到内存插槽，后面的事就简单多了。

1.2 现成工具为什么不够用

市面上其实不是没有硬件检测工具，但真正用下来，总有几个绕不开的痛点。

第一类是厂商绑定的诊断工具，比如 Dell 的 ePSA、Lenovo 的 Diag 工具。这些工具确实做得好，但它绑定自家硬件，只在自己品牌的机器上能用。机房里的服务器品牌五花八门，今天戴尔明天超微后天浪潮，不可能每家的工具都准备一个 U 盘。

第二类是通用型的内存测试工具，比如 MemTest86、memtest86+。这一类只测内存，测不了硬盘、网卡、USB 接口，功能比较单一。如果要全面排查，得准备多个工具、多次启动，效率很低。

第三类是系统层面的检测工具，比如 Linux 下的smartctl、ethtool、lspci。这些工具必须等系统装好之后才能用，而硬件故障往往发生在这个阶段之前。更尴尬的是，如果系统根本装不上，你连诊断手段都没有，陷入死循环。

这些工具各有各的价值，但始终缺一个“开机就能用、什么机器都能跑、测完直接给结论”的解决方案。我当时找了一圈，免费开源的项目里没有一个满足全部需求，所以干脆自己动手写了一个。

2. 整体设计：UEFI 方案的选择与架构

2.1 为什么选 UEFI 而不是 Linux 引导

决定自己写之后，第一个要考虑的问题就是：这个工具运行在什么环境下。

方案一：做一个小型 Linux 发行版，开机引导进内存系统，然后在里面跑检测脚本。这个方案的优点是开发门槛低，Python、Shell 脚本都能写，生态丰富。但缺点也很明显：启动慢、体积大、驱动兼容性参差不齐，而且一旦内核不认某些新硬件，整个系统直接起不来。用这个方案等于用一套 Linux 的兼容性去赌所有服务器的硬件兼容性，风险太大。

方案二：做成一个 UEFI Application，直接跑在固件层。这个方案的好处是启动速度极快，按了电源键到出界面只需要几秒钟；不依赖操作系统驱动，而是直接通过 UEFI 协议访问硬件，兼容性取决于主板固件本身，而支持 UEFI 的主板一般都实现了完整的协议栈。缺点是需要用 C 语言和 EDK2/GNU-EFI 框架开发，工作量更大，调试也更麻烦，但这些问题都可以克服。

权衡之后我选了方案二，也就是 UEFI Application。核心原因就一句话：它离硬件最近，运行环境最干净，也最稳定。

2.2 可视化界面与一键报告的实现思路

确定了 UEFI 方案，接下来的问题是：怎么实现图形界面？怎么生成报告？

UEFI 规范里有一个 Graphics Output Protocol，简称 GOP，负责提供显示输出的抽象接口。通过 GOP 可以拿到 framebuffer 的地址、分辨率、像素格式，然后直接往显存里写数据就能画图。这个协议在 2010 年之后的几乎所有主板上都有实现，兼容性不用太担心。

界面部分我没有用现成的 UI 库，而是自己写了一套非常轻量的图形渲染引擎，支持画矩形、填充颜色、绘制中英文字符、显示进度条和按钮。字体点阵是自己预生成的，不依赖文件系统里的字体文件，这样整个工具就是一个独立的 EFI 可执行文件，放在 FAT32 格式的 U 盘里就能跑。

报告生成方面，UEFI 环境下的一个天然难点是没有文件系统驱动。虽然我们可以用 UEFI 自带的 Simple File System Protocol 来读写 FAT 分区，但如果你想直接把报告写到 NTFS 或 ext4 分区，就得自己实现文件系统驱动，工程量太大。所以我的方案是默认把报告写到 FAT32 格式的 U 盘或内置启动分区里，同时在内存里保留完整报告数据，如果检测到网络可用，还能通过 UEFI 的 HTTP Boot 协议把报告推送到指定的服务器上。

3. 21 项测试到底测什么

3.1 CPU 与内存类测试

CPU 和内存是整个系统里最容易出故障、也最容易引起莫名崩溃的部件，所以我把测试重点放在这两块。

CPU 部分有四项测试：

第一项是通过 CPUID 指令读取 CPU 的厂商、型号、步进、核心数和线程数，和 SMBIOS 里的记录做交叉比对。
第二项是 ACPI 表解析测试，重点看 MADT 表里的 Local APIC 信息是否完整，有多少个核心被正确映射。
第三项是缓存测试，读取 CPUID 里 L1/L2/L3 缓存的大小和关联度，确认缓存信息没有异常。
第四项是简单的 FPU 运算测试，执行一组浮点运算并对比预期结果，用来快速暴露 CPU 计算单元的问题。

这四项里头，最容易出问题的是 ACPI 表解析。我在调试阶段遇到过一个很诡异的情况：一台机器在 Windows 下完全正常，但只要跑 Linux，系统就随机死机。后来用自检工具一跑，发现 MADT 表里只列了一半的核心，导致操作系统只用了半个 CPU 的资源，非常隐蔽。这个测试基本上能把这个坑提前挖出来。

内存部分有六项测试：

内存容量识别：读取 SMBIOS Type 17 记录，列出所有内存条的信息，包括容量、速度、厂商、序列号。
内存插槽占位检测：对比主板内存插槽总数和实际占用数，帮你在测试早期就发现“少了一根内存”的问题。
内存读写测试：这是整个工具里最核心的稳定性测试，在 64 位模式下对全部可寻址内存做多次写入、读取、校验，通过不同的地址模式（全 0、全 1、倒置、走迷宫）暴露电气连接问题。
缓存一致性测试：专门检查 CPU 缓存和内存之间的数据一致性，这个测试对多路服务器特别重要。
ECC 功能检测：从 SMBIOS 里读取内存是否支持 ECC、当前是否启用 ECC，以及是否报告过可纠正错误。
内存延迟简易测试：通过多次随机访问测量内存延迟是否在合理范围内，数值异常往往预示着内存颗粒老化。

内存测试的算法细节我多说一句。很多人写内存测试就是for (i = 0; i < size; i++) mem[i] = pattern;，这种写法在操作系统层面跑没问题，但在 UEFI 裸机环境下有一个坑：CPU 的 cache 可能把数据留在缓存里，你写进去又读出来，读的全是缓存里的内容，根本没真正打到内存条上。所以每一轮读写之后必须执行wbinvd指令把缓存刷回内存，或者读的时候用 non-temporal 指令绕过缓存，否则测试结果没有意义。

3.2 存储与接口类测试

存储设备是另一个故障高发区，尤其机房里的机器，硬盘整天在高温高负载下运转，坏盘是家常便饭。这项测试覆盖了常见存储接口。

SATA 接口测试通过 ATA Pass-Through 协议发命令给硬盘，主要做三件事：枚举 SATA 设备列表、读取 SMART 健康信息（通电时间、重映射扇区数、CRC 错误计数等）、做一个小范围的读写测试。

NVMe 接口测试走的是 NVMe Admin Command 和 IO Command，先通过 Identify Controller 拿到硬盘的容量、固件版本、序列号，再用 Get Log Page 读取 SMART/Health Information，最后做一次小块随机读验证。

软件层面的 SMART 解析这块有不少细节。SATA 硬盘的 SMART 数据有 256 字节，每个厂商对 vendor specific 字段的定义都有区别，但有几个关键字段全行业通用：Reallocated Sector Count（重映射扇区）、Current Pending Sector（待定映射扇区）、Uncorrectable Sector Count（不可纠正扇区）。这三项只要有一个不为零，基本可以判断硬盘已经处于亚健康状态，建议直接换盘。NVMe 的 SMART 信息更标准化，重点看 Percentage Used、Available Spare、Media Errors 这三个字段。

UEFI 环境下的读写测试我做了安全限制：只允许对设备前 1MB 区域做非破坏性读写，也就是先读取原始内容、写测试数据、校验、再把原数据写回去。这样做能确认设备基本可读写，又不会动到已有分区结构。

3.3 网络与外设类测试

网络和外设的问题通常不致命，但一旦出问题也很心烦。

网卡测试通过读取 PCIe 配置空间枚举所有网络控制器，读取 Vendor ID、Device ID、Subsystem ID、MAC 地址，然后通过 UEFI 的 SNP（Simple Network Protocol）接口尝试初始化设备并检测链路线缆是否连接。这里有一个细节：很多服务器的网卡在 UEFI 阶段只有第一个端口被初始化，后面的端口要等操作系统驱动加载后才可用，所以这一项测试会明确标注“这是固件环境的识别结果，不完全代表操作系统下的状态”。

USB 设备测试包括枚举所有 USB 控制器和已连接的设备，尝试读取设备描述符，验证设备能否被正确识别。键盘和鼠标的测试则是真正地等待用户操作，界面上会显示“请按任意键，请移动鼠标”，实际操作时顺手就能完成。

显示输出测试会检测当前 GOP 模式支持的最大分辨率和当前分辨率，然后画一组标准色块和闪烁图案，由人眼确认是否有花屏、偏色、亮暗不均。音频不做测试，因为服务器环境里很少用到。

这组测试不太可能发现所有问题，但它能把明显故障暴露在装机之前。

4. 实操演示：从制作启动盘到输出报告

4.1 工具准备与 U 盘启动盘制作

使用这个工具的门槛很低，准备步骤很简单。

第一步，找一支 U 盘，容量 1GB 以上就行。数据提前备份好，制作过程中 U 盘会被格式化。

第二步，把 U 盘格式化或者分区为 FAT32。这一步必须手动确认，因为 UEFI 固件只认 FAT 文件系统。有些主板支持 NTFS 启动，但不建议依赖这种能力。分区完成后，创建一个目录结构：根目录放EFI/BOOT/BOOTX64.EFI，这个文件就是自检工具的主程序。

第三步，如果是 UEFI Shell 环境，也可以直接把 EFI 文件放到 FAT 分区的任意目录，进 Shell 手动执行。为了省事，我一般直接把文件放到默认启动路径，开机直接加载。

第四步，重启机器，进 BIOS 设置，把启动模式设成 UEFI，关闭 Secure Boot，设置从 U 盘启动。这一步在不同主板上菜单名称不太一样，有的是 “CSM” 相关设置，有的是 “Secure Boot” 子菜单，需要稍微找一下。

实际操作中有一个很重要的习惯：在准备带进机房的 U 盘之前，先在台式机上完整跑一遍自检，确认工具能在 UEFI 环境下正常启动，避免到了现场发现 U 盘没做好浪费一整个下午。

4.2 完整测试流程跑一遍

启动工具的流程大概是这样的：

开机后几秒钟进入自检工具的主界面，顶部显示机器型号和 BIOS 版本，中间是 21 项测试的图标矩阵，底部有三个按钮：开始测试、单测选项、退出。

按下“开始测试”之后，界面左上角会出现一个实时状态区，当前正在执行哪项测试会高亮显示，右侧的日志窗口会滚动输出测试细节。CPU 和内存这几项测试跑得很快，通常在十几秒内完成，存储测试要看硬盘数量和容量，一般每块盘需要 20 到 60 秒，网络和外设测试需要人工配合操作键盘鼠标，全部跑下来大约在 5 到 15 分钟之间。

每一项测试完成后，图标会变成绿色（通过）、红色（失败）或黄色（警告），测试日志里会记录具体的失败原因。全部测试结束后，界面中央会弹出一个汇总面板，列出通过、失败、警告的项数，以及每一项的耗时。这时候如果插着 FAT32 格式的 U 盘，点击“导出报告”，工具会在 U 盘里生成一个以时间戳命名的 HTML 文件，同时把原始日志打包成一个 TXT 文件。

HTML 报告的结构很适合给不懂技术的同事或客户看：最上面是整机摘要，包括制造商、产品型号、序列号、BIOS 版本；中间是测试结果总览，用颜色区分；下面按分类列出每一项测试的详细数据，比如内存条的容量、硬盘的 SMART 属性、网卡的 MAC 地址等，所有字段都有中文说明。

4.3 报告文件怎么读

报告拿到手之后，重点不是看“通过”和“失败”，而是看那些“黄色警告”和“测试参数异常”的项。举几个实际案例。

案例一：某台机器内存测试全部通过，但内存容量识别只认出了 32GB 中的 16GB，这是典型的单通道失效，也就是有一条内存插槽没工作，或者内存条有一面颗粒坏了。这种情况正常运行 Linux 可能也稳定，但性能会掉一半，如果机器对性能敏感，必须处理。

案例二：一块 NVMe 盘的 SMART 信息显示 “Available Spare” 只有 30%，虽然测试是通过的，但这是一块非常接近寿命尽头的盘，随时可能掉盘，应该趁还没出大问题赶紧换掉。

案例三：网卡 PHY 检测正常，但 UEFI 环境下只有第一端口有 link，其他端口都显示 down。这个并不是故障，而是固件只初始化了第一个端口。如果操作系统下所有口都能 up，那这个“红色失败”项是可以忽略的。所以我特意在报告里加了一个“固件环境说明”字段，提醒阅读者区分是环境限制还是真实故障。

5. 常见问题排查与避坑经验

5.1 与厂商固件冲突的处理

实际用下来，最常遇到的问题就是 Secure Boot。很多品牌机的 Secure Boot 是默认开启的，而这个自检工具是一个自定义编译的 UEFI Application，没有微软签名，直接启动会被拦下来，表现就是开机后直接黑屏，或者提示 “Security Violation”。

解决办法是在 BIOS 里临时关闭 Secure Boot，跑完测试再打开。这个操作不改变任何硬件数据，只影响启动流程，所以不用担心。

另一个常见问题是某些服务器主板的 “Fast Boot” 或 “Ultra Fast Boot” 选项。开启后固件会跳过很多 UEFI 驱动，导致存储设备没被枚举、GOP 分辨率被锁定在 800x600，自检工具识别不到硬盘，或者界面显示模糊。遇到这种情况，需要进入 BIOS 把 Fast Boot 关掉，让 UEFI 完整初始化所有设备再跑测试。

5.2 硬件识别失败的常见原因

如果某项测试识别不到硬件，先不要判断硬件坏了，按这个顺序排查：

第一步，看 UEFI 固件里能不能看到这个设备。在 BIOS 里打开外接设备列表，确认硬盘、网卡被主板识别。如果 BIOS 里都看不到，那才可能是硬件问题。

第二步，确认是不是端口供电问题。比如 USB 设备插前面板不识别，插后面板就能识别，多半是前置面板到主板的线序或者供电有问题。这个在自检工具里也能复现，多插几个口对比一下。

第三步，看报告里的设备描述符是否正常。UEFI 环境下设备识别信息不完整很常见，比如某品牌的工业主板，USB 控制器的 Vendor ID 是空的，这个时候工具会打警告，但不一定代表故障。

第四步，换一个 U 盘或者换一个 USB 口再试。有些 U 盘在 UEFI 环境下兼容性很差，表现为启动过程中死机、黑屏、识别不到。我常备两个不同主控的 U 盘，一个装自检工具，一个装 memtest，免得现场出岔子。

5.3 报告丢失与日志收集技巧

有几次我在现场跑完测试，点导出报告，提示成功，但回到工位插上 U 盘发现文件是 0 字节。排查下来发现是 U 盘质量问题，扩容盘或者快报废的 U 盘在 UEFI 环境下写入会静默失败。

这里分享一个我踩过几次坑之后的习惯：U 盘准备之后，先做一次“写入校验”，就是在自检工具里导出一份测试报告到空目录，再在电脑上打开确认内容完整，而不是只看导出成功的提示。

如果工具在跑内存压力测试的时候死机，导不出报告，可以先把DEBUG级别的日志开启，日志会实时输出到串口。很多服务器后面板有串口，用一根 USB 转串口线连到笔记本，配合 PureUEFI 自带的串口日志抓取功能，就算机器死机了，日志也已经全部传到笔记本上，能省很多排查时间。

另外还有一个实用技巧：UEFI 引导日志里会记录所有驱动加载的过程，包括每个 PCIe 设备的 BAR 地址和 ROM 地址。如果某个设备无法初始化，但工具没有识别到具体原因，可以手动进入 UEFI Shell，执行drivers、devices、pci这几个命令查看固件视角的设备树，经常能找到比自检工具更底层的报错信息。

5.4 一个容易忽视的坑：内存测试的“假阳性”

最后讲一个非常关键的踩坑经验，关于内存测试的假阳性。

我最早验证工具的时候，在一台老旧的 Xeon E5 机器上连续跑了十几遍内存测试，偶尔会出现一两次随机地址的读写校验失败。当时很兴奋，以为抓到了不稳定内存的证据，但换掉内存条之后问题复现概率还是很高。仔细排查后发现，问题出在我的测试算法和 UEFI 环境的内存映射上。

UEFI 环境下有些内存区域是保留给固件用的，比如 ACPI 表、NVRAM 变量、图形 framebuffer，这些区域不能瞎写。我当时用GetMemoryMap拿到的内存映射表，有的保留区域没有正确过滤，测试写到这些地方就会和固件抢内存，导致数据错乱。后来改成了严格过滤非可用内存区域，并且对可用的 EfiConventionalMemory 做了双重校验，假阳性基本绝迹。

所以如果你也要写类似的工具，或者用别人的自检工具看到偶发的内存失败，先别急着换内存条，确认测试工具是否正确过滤了保留内存区域再下结论。这个细节一般不会写在工具的说明文档里，但恰恰是最容易出问题的地方。