先放结论市面上能免费、可靠、批量做裸金属硬件健康检查的工具确实不多。你要么买商用服务器的带外管理套件要么靠人肉开机看自检灯再要么装完系统跑一轮压力测试。我因为经常要给一批裸金属服务器做交付前的硬件体检实在受不了这种效率索性自己写了一个跑在 UEFI 环境下的整机自检工具21 项测试全程图形界面显示进度和结果测完一键把报告写到 U 盘拿回电脑上打开就是一份简单明了的体检单。这篇文章就把这个工具的设计思路、实现细节和踩坑记录完整拆开讲手把手教你也能做出一套类似的自检方案。1. 为什么裸金属排查这么麻烦以及我为什么写这个工具先说我最直接的痛点。裸金属服务器和虚拟机完全是两码事虚拟机硬件层是被 Hypervisor 抽象过的出问题多半在宿主或虚拟化层裸金属交付的是整台物理机CPU、内存、硬盘、网卡、 RAID 卡、电源、风扇哪一个环节存在隐患后面跑业务迟早会爆雷。而且更麻烦的是很多机器到货时根本没装操作系统你没法上去跑 memtest、跑 badblocks、跑 ethtool 诊断只能靠服务器自带的 POST 自检或者带外管理口慢慢看。有人可能会说“服务器不是有 IPMI/BMC 吗看传感器不就完了。”这话对一半。BMC 能看电源、风扇、温度这些基础监控但内存 bit 翻转、PCIe 链路异常、网卡物理层通断、硬盘介质坏道这些光靠 BMC 是看不全面的。而且你有一批机器要批量验收的时候一台一台进 Web 界面点开传感器再对照日志手动记录效率低到让人怀疑人生。1.1 市面上免费工具的真实现状先别急着写代码我也研究过现成方案。在 UEFI Shell 下确实有一些可用的开源工具比如 EDK2 自带的 Shell 命令、memtest86 的 UEFI 版本、部分主板厂商的诊断工具。但实际用下来各有各的局限memtest86 对内存测试很专业但它只管内存网络、存储、传感器都不管UEFI Shell 下的pci、devices、drives命令可以看设备列表但结果是一堆原始文本没有统一判定也没法生成报告主板厂商自己的诊断工具通常要配合特定机型换一批服务器就没法用真正商业化的裸金属体检工具基本都按节点数收费几十台机器一年下来费用不低。免费、开源、可定制、能批量交付、还能出统一格式报告这几个条件放在一起现成轮子基本没有。所以我决定自己写一个 UEFI 引导阶段就能跑的自检工具代码自己控制想测什么测什么判定逻辑完全可见。1.2 UEFI 自检的核心价值在无 OS 环境下做体检为什么选择把工具做成 UEFI 应用而不是装个精简 Linux 系统来跑诊断原因有几个。第一机器没装系统时也能用。不管是新到货验收、返修后验证还是机房库存盘点只要机器能点亮进 UEFI插上启动 U 盘就能跑不需要预先装任何操作系统。第二UEFI 环境比 OS 环境更“干净”。没有 OS 的驱动栈、后台任务、日志服务干扰你访问的是固件层暴露出来的设备更能反映硬件本身的状态。这一点在做网卡物理层检测、内存原始读写测试时尤其重要。第三速度比装系统快得多。装一个最小 Linux 折腾装机流程至少十几分钟而 UEFI 工具从插上 U 盘到跑完 21 项测试正常机器三到五分钟就出结果。批量处理的时候这个时间差就是效率。第四UEFI 应用可以直接操作固件协议比如 GOP 图形输出、SNP 网络协议、Simple File System 文件读写、SMBIOS 表查询这些接口既标准又稳定。只要主板 UEFI 固件实现符合规范同一份 .efi 文件在不同品牌服务器上都能跑不需要每台机器单独适配。2. 工具整体设计21 项测试怎么拆为什么是这 21 项这一个章节是全文的核心我把测试项设计的思路和具体实现细节完整讲一遍。2.1 测试项选型的逻辑做硬件自检最怕两件事一是漏测关键部件二是测了一堆无关痛痒的项目浪费时间。我在选测试项时按这个逻辑筛选服务器交付后最容易出问题、且故障率最高的硬件单元优先测同时保证每个主要组件至少覆盖“识别 功能 压力”三个维度中的一个。举个例子内存如果只读容量那只能证明“BIOS 认得这根内存条”并不能证明内存颗粒能稳定存取数据。所以我给内存设计了容量识别、SPD 信息读取、数据线/地址线测试、多模式读写压力测试四层。CPU 也一样光读型号没有意义还要验证核心/线程数、频率、缓存参数是否能被正确枚举。网卡不仅要有 MAC还要能读到物理链路状态插没插网线一眼就知道。2.2 21 项测试总表整个工具最终收敛成 21 项测试分成 7 大类。下面这张表是工具的完整测试清单实际界面和报告里也是按这个顺序输出。分类编号测试项验证目标CPU01CPUID 基本信息CPU 厂商、型号、步进是否可读CPU02核心与线程数核数是否与官方规格一致CPU03频率校准TSC/APIC 频率是否正常CPU04缓存参数L2/L3 容量、关联度是否匹配内存05总容量汇总SMBIOS Type 17 累计容量内存06SPD 信息每根内存条容量、频率、厂商内存07地址线测试高位地址线有无短路、浮空内存08数据线测试数据总线是否粘连、丢失内存09多模式压力测试数据保持与读写一致性存储10磁盘控制器枚举AHCI/NVMe 控制器识别存储11NVMe 设备信息型号、容量、固件版本存储12SATA 设备信息硬盘型号、容量、固件存储13Identify 命令验证设备响应是否正常网络14网卡 MAC 读取SNP 协议能否枚举网卡网络15物理链路检测Link 状态是否正常USB16USB 控制器枚举XHCI/EHCI 控制器识别USB17USB 存储识别是否可枚举到 U 盘串口18串口回环测试板载串口收发是否正常RTC19CMOS 读写测试RTC 寄存器读写稳定RTC20实时钟走时时间递增是否正常平台21固件与传感器信息BIOS 版本、温度、风扇转速你没看错这 21 项里有不少是“识别类”测试看起来简单但恰恰是交付验收最常翻车的点。比如说 CPU 核心数和官方规格对不上多半是 ES 版 CPU 或者 UEFI 微码有问题SATA 设备型号读不出来可能盘已经掉线或者背板线缆松动。这类问题在批量验收时特别常见靠人工很难一眼发现差异脚本判定的价值就在这里。2.3 关键测试的原理细节简单识别类测试我不过多赘述重点讲三个判定逻辑最复杂、也最容易写错的测试。内存地址线测试地址线问题的本质是 CPU 访问某个物理地址时高位地址线因为虚焊、短路或者主板布线故障导致访问落到了错误的地址上。我用的方法是回绕测试法选取 0x80000000、0x40000000、0x20000000 这样的 2 的幂次地址向目标地址写入一个标记值然后去读它对应的“影子地址”看是否一致。如果地址线 A31 短路到地往 0x80000000 写的数据可能会出现在 0x00000000测试立刻就能发现。实际操作中要注意避免覆盖已使用的内存区域。我的做法是在 UEFI 分配内存时先用AllocatePages申请一块固定大小的测试缓冲区在缓冲区内部做地址位测试。这样既不会踩到固件自己的数据又能保证地址连续可控。内存多模式压力测试压力测试不能只写一种 0x55/0xAA 交替模式因为那只能覆盖数据线上的固定粘连故障。我用了四轮模式全 0、全 1、0xAA55 交替、伪随机数。每轮先写入再读出校验做一遍正向写入、反向写入从高地址往低地址写以覆盖行缓冲和 DRAM 刷新逻辑的边界情况。伪随机数我用 LFSR线性反馈移位寄存器生成避免引用标准库增加体积。校验时逐字节比较一旦发现不一致立即记录错误地址和期望值/实际值测试项标记 FAIL但不会立刻中断整机测试而是记录完继续跑完其他内存区域这样报告里能给出具体的故障密度方便判断是单颗粒故障还是整根内存条故障。网卡物理链路检测UEFI 下的 SNP 协议Simple Network Protocol既能拿到 MAC 地址也能查询媒体状态。我调GetStatus接口读取 Tx 和 Rx 状态再结合GetModeData返回的MediaPresent字段判断网线是否物理连接。当年我第一次写这个功能时踩了个坑有些主板网卡在 UEFI 阶段默认没有初始化 PHYMediaPresent永远是 FALSE但这不代表网卡是坏的。后来我在测试前先主动调用Initialize和Start再发一个空包触发 PHY 协商等几百毫秒重新读状态结果才准确。3. 全程可视化的实现UEFI 下画界面并没有想象中难很多人一听“UEFI 程序画界面”第一反应是复杂。实际 UEFI 规范里有一个 GOPGraphics Output Protocol协议它给应用程序提供了访问显示帧缓冲的标准接口。拿到 GOP 之后画界面本质上就是往内存里写像素。3.1 GOP 图形输出基础获取 GOP 的代码非常直接EFI_GRAPHICS_OUTPUT_PROTOCOL *Gop; EFI_STATUS Status; Status gBS-LocateProtocol( gEfiGraphicsOutputProtocolGuid, NULL, (VOID **)Gop ); if (EFI_ERROR(Status)) { // GOP 不可用进入文本模式回退逻辑 }拿到协议后Gop-Mode-Info里有屏幕分辨率和像素格式Gop-Mode-FrameBufferBase是帧缓冲首地址。我封装了一个最简 UI 库只实现四种基础能力填充矩形、输出字符串、绘制进度条、绘制状态色块。不需要窗口系统不需要事件驱动框架整个界面就是一个自绘的仪表盘。界面布局我做成上下结构顶部是机器信息和 BIOS 版本中间左侧是 21 项测试的状态列表右侧是当前测试项的日志输出底部是一条总进度条和当前测试项名称。每完成一项左侧对应条目从黄色“RUNNING”变成绿色“PASS”或红色“FAIL”右侧实时刷新该测试项的检测结果。3.2 布局、进度条与事件循环一个典型的进度条绘制逻辑长这样// 在坐标 (X, Y) 绘制宽度为 W 的进度条Value 范围 0~100 VOID DrawProgressBar(UINTN X, UINTN Y, UINTN W, UINTN Value) { UINTN i; // 先画外框和背景 DrawRect(X, Y, W, 20, BACKGROUND_COLOR); DrawRect(X, Y, W, 20, FRAME_COLOR); // 画边框 // 前景填充 for (i 0; i (W * Value / 100); i) { DrawRect(X i, Y, 1, 20, PROGRESS_COLOR); } }关键点在于要循环刷新而不是一次性画完。我在主测试循环里每完成一个测试子步骤就调用一次gBS-Stall短暂延时同时刷新进度条和右侧日志人眼看起来就是“实时滚动”的效果。Stall的单位是微秒我一般用 50ms 的粒度刷新既能保证界面流畅又不会拖慢测试本身。3.3 文本模式回退与兼容性处理写的时候要时刻记住不是所有服务器的 GOP 都靠谱。我在部分老款主板上遇到过LocateProtocol能拿到 GOP但QueryMode返回的分辨率列表全是空的或者SetMode设置分辨率后屏幕花屏的情况。所以程序在 GOP 获取失败时会自动回退到 UEFI 文本模式用gST-ConOut输出字符界面。文本模式也算一个可用界面只是显示效果朴素一些核心测试和报告生成逻辑完全复用不会因为显示模式不同而中断。另外推荐一个调试阶段的技巧在 QEMU/OVMF 虚拟机里做基本功能验证时界面像素格式可能和真实服务器不同我在DrawPixel底层做了像素格式判断BGR 还是 RGB这个小小的兼容处理帮我省掉了大量真机适配时间。4. 一键出报告HTML/TXT 双格式落盘工具跑完测试不出报告等于白测。我在设计报告模块时定了几个目标格式统一、任何人都能看懂、便于机器解析、能长期归档。4.1 UEFI 下写文件的三板斧UEFI 应用写文件绕不开 Simple File System Protocol。首先定位到 U 盘的文件系统根目录EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *Sfsp; EFI_FILE_PROTOCOL *Root, *File; gBS-LocateProtocol(gEfiSimpleFileSystemProtocolGuid, NULL, (VOID **)Sfsp); Sfsp-OpenVolume(Sfsp, Root);然后创建文件并用Write写入内容EFI_STATUS Status; UINTN Size; CHAR16 FileName[] Lreport.html; CHAR8 *Content htmlbody...; // 这里放生成好的 HTML Status Root-Open(Root, File, FileName, EFI_FILE_MODE_CREATE | EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE, 0); if (!EFI_ERROR(Status)) { Size AsciiStrLen(Content); File-Write(File, Size, Content); File-Close(File); }有个细节值得注意我故意把文件名处理成report_YYYYMMDD_HHMMSS.html这种带时间戳的格式避免同一台机器多次测试时覆盖旧报告。时间可以直接从 RTC 读取格式化成字符串后拼接进文件名。文件系统识别方面程序会遍历所有 Block IO 设备找 FAT 分区且卷标符合约定比如HWDIAG的那个卷。这样做的好处是现场操作时不用管 U 盘在机器里被识别成哪个设备号插对了盘就一定写到正确的位置哪怕机器里还有其他启动设备也不会搞混。4.2 报告格式设计报告我生成两份一份 HTML一份纯文本。HTML 给现场工程师用浏览器打开直接看结果纯文本给脚本和自动化流程用方便grep关键字做后续处理。HTML 报告的核心结构是一个大表格每一行对应一项测试包含测试编号、名称、结果状态、耗时、关键返回值。结果状态用颜色区分PASS 是绿底FAIL 是红底SKIP 是灰底。表格上方是服务器摘要CPU 型号、内存总容量、BIOS 版本、测试时间、总判定结果。报告内嵌简单的 CSS不需要联网加载任何外部资源离线打开也完整。报告下方的判定规则也写得很清楚。总判定规则是21 项测试全部 PASS 则总结果 PASS任一 FAIL 则总结果 FAIL如果某项因为硬件不支持导致无法测试标记为 SKIP不影响总结果但会在报告里显著标注“未覆盖项”。这样做是为了避免因为串口回环没接自环头就把整台机器判定为故障但也不能让 SKIP 项悄无声息地藏过去。4.3 无人值守与结果判定逻辑做批量验收时我不可能每台机器都盯着屏幕看。所以在工具里做了一个自动模式如果需要无人值守程序检测到 U 盘上有autotest.cfg配置文件就跑完全部测试后自动写报告、自动关机或重启。判定逻辑完全在代码里闭环不依赖人工观察。配置文件里还能指定重复跑几轮压力测试比如LOOP3就把内存压力测试连续跑三遍提高捕获取证时偶发错误的概率。个人经验是验收场景下内存压力测试最好设置至少两轮因为很多坏内存条并不是第一轮就稳定报错的而是温度升高后才开始出现 bit 翻转。LOOP 参数从 1 调到 3单台机器测试时间增加大约四分钟但漏测率明显下降性价比非常高。5. 完整实操从编译到真机运行这一章节是给想复现这个工具的人写的完整操作流程从源码编译到 U 盘启动全链路都过一遍。5.1 编译环境搭建与代码骨架编译环境我推荐用 EDK2正式稳定资料也多。以 Linux 环境为例git clone https://github.com/tianocore/edk2.git cd edk2 git checkout edk2-stable202405 git submodule update --init make -C BaseTools source edksetup.sh然后在 EDK2 的OvmfPkg或者自建一个 Package 里添加你的驱动模块写一个.inf文件描述模块信息写一个.dsc文件编译整个包。编译命令大致长这样build -p MyDiagPkg/MyDiagPkg.dsc -m MyDiagPkg/DiagApp.inf -b RELEASE -t GCC5编译产物是一个.efi文件。我在代码里用了一些 EDK2 提供的标准库头文件包括Uefi.h、Protocol/GraphicsOutput.h、Protocol/SimpleFileSystem.h、Library/UefiLib.h等基本上写 UEFI 应用需要的东西都能覆盖。代码骨架的核心是一个主循环按照前面说的 21 项顺序逐项执行。每一项我封装成一个函数返回一个结构体包含测试结果和详细日志。主循环只负责收集结果、刷新界面、最后调报告生成模块。这样设计的好处是后续加测试项非常方便只要新写一个函数往测试列表里填一行记录即可。5.2 制作启动 U 盘U 盘制作有几个需要注意的地方分区表用 GPT文件系统用 FAT32这是 UEFI 启动最稳的组合把编译好的 .efi 文件改名为BOOTX64.EFI放到EFI/BOOT/目录下U 盘插入机器后可以直接被识别为启动设备U 盘卷标建议设置成HWDIAG和工具内约定的卷标一致保证报告写入时能找到正确位置不要用各种一键装机工具往 U 盘里写私有引导结构很多服务器主板对非标准启动盘兼容性极差识别不了。我习惯在同一张 U 盘里再放一份readme.txt写着工具用途、操作步骤和报告文件名规则。现场工程师拿到 U 盘不至于一头雾水。5.3 真机运行步骤与结果判读真机运行的流程并不复杂开机按对应按键进入主板启动菜单调整启动模式为 UEFI关闭 Secure Boot自签名或未签名工具会被拦截选择 U 盘启动工具自动加载并进入图形界面测试自动开始左侧列表逐项点亮右侧滚动输出日志全部测完后屏幕显示总判定结果报告自动写入 U 盘把 U 盘插回笔记本电脑打开生成的 HTML 文件查看报告。判读报告时重点关注三块总判定结果是不是 PASS有没有 SKIP 项有的话要弄清楚为什么跳过是硬件不支持还是测试环境不满足FAIL 项的详细信息里面的寄存器值、地址信息、错误模式对返修非常有用。6. 常见问题与排查心得工具写了快半年真机验证跑了上百台服务器踩坑记录攒了不少。挑几个最有代表性的整理成速查表方便你遇到问题直接查。6.1 问题速查表现象可能原因解决思路U 盘无法启动Secure Boot 拦截未签名程序进入 BIOS 关闭 Secure Boot或用 EDK2 标准签名机制签名界面花屏或分辨率异常GOP 显示模式不兼容增加文本模式回退或强制设置 1024x768 标准模式网卡 MediaPresent 恒为 FALSEPHY 尚未初始化测试前主动调用 SNP Initialize/Start延时后等链路协商内存压力测试跑太久测试模式过多、容量太大增加抽样测试选项或按内存容量动态调整模式轮数报告没有写入 U 盘卷标不匹配或分区格式不对确认 U 盘是 FAT32、卷标为 HWDIAG且未挂载其他文件系统NVMe 设备识别不全平台不支持 NVMe 命名空间枚举降级为 PCI 配置空间读取设备信息6.2 在 Supermicro 等服务器主板上踩过的坑服务器主板和消费级主板在 UEFI 实现上的差异非常大这条经验值得记住不能因为程序在 QEMU 里跑得通就直接上服务器真实硬件永远有你想不到的兼容性问题。拿我之前大量接触的 Supermicro 主板举例它有几种情况特别考验工具一是默认启动模式可能是 Legacy/CSM 而不是纯 UEFIU 盘要选择 UEFI 启动入口二是部分型号对 U 盘的文件系统格式非常挑剔FAT32 单分区没问题但如果有多个分区或者用了 exFAT开机菜单可能直接不显示这个 U 盘三是它的 GOP 驱动在部分型号上分辨率支持不全强行设置高分分辨率会花屏安全做法是优先尝试 1024x768再按需往高适配。这些坑都有一个共同特征大多数不是工具逻辑写错了而是 UEFI 固件对标准的实现各有各的“私货”。所以工具的兼容层一定要写得宽容能降级就降级能回退就回退不要死磕某一个协议调用必须成功。6.3 与批量装机流程的衔接思路最后补充一个和裸金属服务器批量安装操作系统流程衔接的实践。工具跑出来的报告文件名里带机器序列号和时间戳这个序列号我在程序里通过 SMBIOS 系统信息直接读取不需要人工录入。后续接自动化流程的话巡检脚本扫描报告目录按序列号归档状态为 FAIL 的机器自动进入维修工单状态为 ALL_PASS 的机器才允许加入装机队列。这样做还有一层额外收益因为自检发生在 UEFI 阶段所有日志可以完整保留到磁盘后续机器在 OS 里运行出了问题返回来翻硬件体检报告能快速判断是硬件本身的问题还是上层软件的问题省掉很多重复排查的时间。个人实际感受是这个“先体检、再装机”的顺序一旦建立起来第一批交付验收的效率提升非常明显至少省了一半以上的来回沟通成本。如果你也想做一个类似的自检工具我的建议是不要一开始就追求功能齐全先跑通最小闭环3 到 5 项关键测试能出报告能启动能判 PASS/FAIL。真机验证没问题后再一项一项往里加每加一项都在目标硬件上测一轮。这样既不会一上来就被复杂度劝退也能确保每一轮迭代都建立在可验证的基础上。这个思路看起来慢实际上是最快走通全流程的方式。