服务器BIOS固件升级实战：UEFI Shell、BMC带外刷写与配置基线恢复

简介：面向华为 RH1288V2 服务器运维人员、售后工程师及企业 IT 管理者的 BIOS 更新资料包，适合用于固件维护、版本核对、兼容性排查和日常巡检等场景。压缩包共 4 个文件，约 26.37MB，包含 2 个 hpm 固件包、1 个 doc 说明文档和 1 个 xml 版本信息文件，分别对应升级文件、配套说明与版本标识，包体精简，便于快速定位所需内容。已有 1572 人学习下载，具备一定参考热度。资料围绕该机型 BIOS 维护需求整理，能够帮助读者确认固件版本、了解升级包组成，并为处理升级前准备、版本匹配及常见固件兼容问题提供依据；doc 文档可用于查阅注意事项，xml 文件便于核对版本信息，适合作为 RH1288V2 服务器维护过程中的备查资料。

1. 一颗 SPI Flash 里的固件，值不值得为一次偶发宕机去动它

一台跑了两年多的 2U 双路机架服务器，某次重启后卡在内存初始化， BMC 日志里只有一行内存训练失败。多数人第一反应是拔内存条换插槽，但更该先确认的是服务器 BIOS 固件版本——内存训练参数表、PCIe 链路均衡、处理器微码、UEFI 启动兼容性，全都压在主板上那颗 SPI Flash 里。手上这份 RH1288v2 BIOS.zip 就是那颗 Flash 的完整升级包，解决的是“硬件没坏、固件不对”这一类问题：换了批次不同的内存条点不亮、加装的阵列卡识别不到、跑虚拟化时直通设备偶发掉线。它适合手里有同型号机器、并且已经被某个固件 bug 折腾过一次的运维和售后工程师；机器跑得好好的、没有明确变更需求，就不必升级。

2. 解包与介质准备：从 zip 到一张能启动的 U 盘

拿到压缩包先别急着往服务器上插。这一步做扎实，后面能省掉大半返工。我一般按“看清单 → 校验 → 做盘 → 存证”四步走，顺序不能乱，尤其是存证，很多人跳过这步，出问题就没有可回退的基线。

2.1 先列清单：包里哪些文件必须进 U 盘

不同批次的固件包结构会有出入，但核心就那几类。解开后先扫一眼目录，对照下表确认东西齐不齐：

发布说明里有两句话必须找出来：一句是“从哪个版本起才能直接升到本版本”，另一句是“升级后是否需要 AC 断电”。前者决定你会不会刷到一半被工具拒绝，后者决定你刷完是重启还是必须拔电源。

2.2 校验与解压：残缺镜像刷进去就是变砖

下载中断、解压工具不兼容、U 盘拷贝掉字节，这三种情况都会让镜像损坏，而刷写工具不一定能在写 Flash 之前发现它。校验这一步别省：

# 1) 先校验压缩包本身，和发布页给出的摘要比对 sha256sum "RH1288v2 BIOS.zip" # 2) 解压到独立目录，避免和旧版本混在一起 mkdir -p ~/fw/rv2_bios && cd ~/fw/rv2_bios unzip -o ~/Downloads/"RH1288v2 BIOS.zip" -d . # 3) 再看一遍解出来的文件，逐个核对大小与摘要 ls -lh sha256sum -c ./*.sha256 2>/dev/null || echo "包内无校验文件，按发布说明手工比对"

第一段命令算的是压缩包摘要，用来确认下载完整；第二段解开到独立目录，是为了避免新旧两个版本的flash.efi混用——刷写工具和镜像是配套的，拿旧工具刷新镜像，最轻的结果是报错退出，最重的结果是写了一半。第三段优先用包内自带的校验文件；包里没有校验文件的，就得按发布说明里给出的摘要手工比对，别嫌麻烦。

2.3 做一张 UEFI Shell 启动盘

服务器固件包里的刷写器基本都是 UEFI 应用，所以要的是 FAT32 分区 + UEFI Shell，不是 DOS 启动盘。常见做法是拿一个 8GB 以内的 U 盘，整盘做一个 FAT32 分区，把 Shell 和固件目录拷进去：

# 假设 U 盘是 /dev/sdb，操作前务必用 lsblk 确认，别写错盘 lsblk -o NAME,SIZE,MODEL # 整盘重建分区表并格式化为 FAT32（会清空 U 盘数据） sudo parted -s /dev/sdb mklabel msdos sudo parted -s /dev/sdb mkpart primary fat32 1MiB 100% sudo mkfs.vfat -F 32 -n BIOSFW /dev/sdb1 # 挂载后按目录结构拷贝：根目录放 Shell.efi，固件放 /bios 子目录 sudo mkdir -p /mnt/usb && sudo mount /dev/sdb1 /mnt/usb sudo mkdir -p /mnt/usb/bios sudo cp Shell.efi /mnt/usb/ sudo cp ~/fw/rv2_bios/*.bin ~/fw/rv2_bios/*.efi ~/fw/rv2_bios/*.nsh /mnt/usb/bios/ sync && sudo umount /mnt/usb

parted那两行是把整盘重做成单分区，起点给到 1MiB 是为了对齐；mkfs.vfat -F 32的卷标建议起个短名字，UEFI Shell 里盘符就是fs0、fs1这种，卷标能帮你快速认出来。目录结构上，Shell 放根目录、固件单独放一个子目录，是因为有些刷写脚本会按相对路径找镜像，混在根目录容易和 Shell 自己的文件撞名。

提示：U 盘容量别贪大，部分老版本固件的 UEFI Shell 对大容量 U 盘的识别不稳定，8GB 以内最省事。

2.4 刷之前先存证：把当前基线抓下来

这一步是后悔药。刷之前把当前 BIOS 版本、启动模式、关键开关、BMC 版本全部记录下来，刷完才有对照：

# 通过 BMC 抓硬件与固件信息，不需要进系统 export IPMI_PASS=~/.ipmi_pass # 口令文件，权限设成 600 ipmitool -I lanplus -H 10.0.0.11 -U admin -f "$IPMI_PASS" mc info ipmitool -I lanplus -H 10.0.0.11 -U admin -f "$IPMI_PASS" fru print # 已经装好系统的机器，顺手把系统侧看到的版本也存一份 dmidecode -t bios > ~/fw/before_bios.txt dmidecode -t system >> ~/fw/before_bios.txt lscpu > ~/fw/before_cpu.txt

mc info给的是 BMC 自身固件版本，fru print会打出主板、机箱的厂商和序列号信息，这两份输出是判断“到底哪一层固件变了”的依据。系统侧的dmidecode -t bios能看到 BIOS 版本号和发布日期，lscpu能留下 NUMA 节点数和逻辑核数——升级后配置被重置，这两项是最容易对不上的。把这个before_*.txt存到本地而不是服务器上，因为升级过程会多次重启，服务器上的临时文件不保险。

3. 三条升级路径：带内 Shell、带外 BMC、离线批处理

同一个包，落地方式有三种，差别不在技术难度，而在“人到不到现场”。选错路径的代价不是刷失败，是刷到一半没法收场。

3.1 选路径：三种方式的适用边界

判断标准很简单：机器在本地、只有一两台，走带内；机器在异地机房或者托管，走带外；同型号超过五台，先做一台验证，剩下的再考虑批处理。反过来做——先批量后验证——是我见过最容易把事情搞大的顺序。

3.2 UEFI Shell 带内刷写：命令行参数逐条对

插上 U 盘，开机按提示进 Boot Manager，选 U 盘里的 UEFI Shell。进去之后先确认盘符，再执行刷写脚本：

# 进入 UEFI Shell 后，重新扫描设备并列出盘符 map -r # 一般 U 盘是 fs0，用 ls 确认里面能看到 bios 目录 fs0: ls cd \bios # 执行厂商脚本；不同包的脚本名不同，先用 type 看一眼内容 type flash.nsh # 典型执行方式：指定镜像、全区域刷写、刷完自动重启 flash.nsh -f rv2_bios_2.68.bin -all -reboot

参数逐个说清楚：-f后面跟镜像文件名，必须是当前目录下的实际名字，写错会立刻报错退出，这一步反而是安全的；-all表示刷写整个固件区域，包含主 BIOS 和管理引擎区段，只在发布说明明确要求时才用，跨大版本升级通常需要，小版本修补一般只刷主区；-reboot是刷完自动重启，如果这台机器还要接着做别的操作，把它去掉，手动 AC 断电更稳妥。有些工具提供-preserve之类的参数用来保留 NVRAM 里的设置，跨版本升级时不要用，旧版本的结构在新固件里可能对不上，保留下来反而是隐患。

刷写过程会显示进度百分比，中途不要按键、不要拔 U 盘。进度到 100% 之后工具会提示成功，但这不代表结束，后面还有一次完整的 POST 要走。

3.3 BMC 带外刷写：不进机房也能刷

BMC 一般提供两种方式：Web 界面上传镜像，或者走 Redfish 接口。Web 界面适合一次性操作，接口适合脚本化。这里给命令行方式，因为它的过程可记录、可复现：

export IPMI_PASS=~/.ipmi_pass HOST=10.0.0.11 # 1) 先确认 BMC 自身版本，太老的 BMC 可能不支持在线刷 BIOS ipmitool -I lanplus -H $HOST -U admin -f "$IPMI_PASS" mc info | head -20 # 2) 通过 Redfish 的固件更新服务上传镜像（镜像先放到内网 HTTP 上更快） curl -k -u admin:"$(cat $IPMI_PASS)" \ -X POST "https://$HOST/redfish/v1/UpdateService/update-multipart" \ -F 'UpdateParameters={"Targets":["/redfish/v1/Systems/1/Bios"],"@Redfish.OperationApplyTime":"Immediate"};type=application/json' \ -F "UpdateFile=@./rv2_bios_2.68.bin" # 3) 盯着任务状态，别只看 HTTP 200 curl -k -u admin:"$(cat $IPMI_PASS)" "https://$HOST/redfish/v1/TaskService/Tasks" | head -40

第二段用 multipart 上传，Targets指定刷哪一块固件——同一台机器上 BIOS、BMC、网卡各是一个 target，指定错了会刷错地方；OperationApplyTime设成Immediate表示立即执行，如果这台机器还在承载业务，改成OnReset，让固件在下次重启时生效。第三段是关键：上传接口返回 200 只代表文件收下了，真正的刷写是异步任务，要轮询任务状态确认走到完成。中途用 SOL 挂上串口控制台看 POST 输出，比盯着进度条有用：

# 挂载串口重定向，看 POST 过程和内存训练日志 ipmitool -I lanplus -H $HOST -U admin -f "$IPMI_PASS" sol activate # 退出用 ~. （波浪号加点）

3.4 刷写窗口里的电源与超时边界

固件刷写本质上是在改写 Flash 的若干区块，这期间掉电，轻则固件区损坏需要走恢复模式，重则整板返修。几个边界要卡死：刷写开始前确认机房供电没有计划性切换；刷写过程中不要执行任何chassis power类命令；刷完之后的第一次 POST 会比平时慢很多，因为内存要重新训练，双路大内存配置跑 5～10 分钟很正常，这段时间千万别以为死机了去强制重启。等 POST 完整走完、进到 Setup 或者系统，才算这一台刷完。

4. 刷完不是收工：把 BIOS 配置基线重新落回去

固件升级最常见的后遗症不是刷坏，是“刷完机器能开机，但性能不对了”。原因是升级过程会重置 NVRAM 里的设置项，包括那些你当初调了半天才定下来的开关。

4.1 为什么固件升级一定会动到你的参数

新固件的设置项结构跟你原来的不一样：有的选项改名了，有的默认值改了，有的拆成了两个新选项。升级工具为了保证兼容性，通常会在检测到结构不匹配时直接加载出厂默认值。出厂默认值面向的是“能开机”，不是“跑得快”——NUMA 默认关、内存交织默认 Auto、SR-IOV 默认关，这些都是常见情况。于是机器是好的，虚拟机上直通设备没了，数据库的跨节点访问延迟上去了。

4.2 六个必须逐项确认的参数

启动模式放第一位，因为它一错机器就起不来，其他参数再对也没意义。NUMA 和内存交织要一起看：开了 NUMA 又开交织，效果会互相抵消，具体取哪个看业务——延迟敏感的走 NUMA 感知，带宽密集的走交织。VT-d 这一项经常被忽略，因为它在 BIOS 里名字各不相同，有的叫 VT-d，有的叫 IOMMU，有的藏在“高级 → PCIe 配置”下面。

4.3 用命令验证版本、微码与拓扑

刷完重启进系统，别急着交差，跑一遍下面这组命令，把结果和 2.4 存的基线对一遍：

# BIOS 版本与发布日期，和预期版本比对 dmidecode -t bios | grep -E "Version|Release Date" # 处理器微码版本，跨版本升级时这个值应该变了 grep -m1 -i microcode /proc/cpuinfo # NUMA 拓扑：节点数、每个节点的 CPU 与内存 numactl -H lscpu | grep -E "^NUMA|^Socket|^Core|^Thread" # PCIe 侧的 SR-IOV 能力是否还在 lspci -vv 2>/dev/null | grep -ci "Single Root I/O Virtualization"

dmidecode -t bios的版本号是最直接的验收点，版本没变说明镜像根本没写进去，多半是刷错了 target 或者刷的是备份镜像。grep microcode这一项容易被跳过，但如果发布说明里提到“包含处理器微码更新”，这个值不变就说明-all没生效。numactl -H打出的是系统视角的拓扑，节点数为 1 就说明 NUMA 在 BIOS 里还是关的——这一条比看 BIOS 界面快得多，批量验证时尤其好用。

4.4 配置模板化：一次调好，后面照抄

单台机器手工点一遍没问题，同型号十几台就这么点，迟早点错。做法是把调好的配置导出成模板，后面直接导入。BMC 一般提供 BIOS 配置的导出导入，导出的是一个配置项键值对文件；接口侧则走 Redfish 的属性写入：

# 把模板里的关键项写回去（属性名各厂商不同，先 GET 一次拿到完整列表） curl -k -u admin:"$(cat $IPMI_PASS)" \ -X PATCH "https://10.0.0.11/redfish/v1/Systems/1/Bios/Settings" \ -H "Content-Type: application/json" \ -d '{"Attributes":{"BootMode":"Uefi","NumaEnable":"Enabled","SriovEnable":"Enabled"}}' # 写完之后重启生效，再读一次确认落盘 curl -k -u admin:"$(cat $IPMI_PASS)" \ "https://10.0.0.11/redfish/v1/Systems/1/Bios" | grep -E "Numa|Sriov|BootMode"

属性名是最坑的地方：NumaEnable、Numa、NumaSupport在不同固件版本里都可能出现，所以先GET /redfish/v1/Systems/1/Bios拿到这台机器支持的完整属性列表，再照着写。PATCH 写进去的是 Settings 资源，要等一次重启才会合并到生效配置，写完立刻读主资源是看不到变化的。

5. 避坑与排查：五条踩过的记录

下面这五条都是真实踩过的，每一条都按“现象 → 原因 → 解决”记，遇到同类问题可以直接对号。

5.1 刷写工具报“镜像校验失败”，但摘要明明对得上

现象：U 盘里的镜像用sha256sum算出来和发布说明一致，进 UEFI Shell 执行刷写脚本却提示镜像无效。

原因：刷写工具校验的不是文件摘要，是镜像内部的头部签名和版本段，而这两段在解压过程中被改过——最常见的是用某些解压工具处理时改了文件大小写或截断了尾部填充字节。

解决：换一个解压工具重新解一遍，解开后对比文件字节数而不是只看ls -lh的向上取整值，用stat -c %s看精确字节数。另外确认 U 盘是 FAT32 而不是 exFAT，个别 Shell 版本读 exFAT 会读出不完整内容。

5.2 升级后机器起不来，卡在“no boot device”

现象：固件升级成功、POST 通过，但系统找不到启动项，提示无启动设备。

原因：启动模式从 UEFI 被重置成了 Legacy，或者 UEFI 启动项列表被清空。前者是默认值变化，后者是 NVRAM 区域被重写。

解决：进 Setup 把启动模式改回 UEFI，然后检查启动项顺序。如果启动项列表是空的，用 UEFI Shell 手工加一条：进fs0:找到系统的EFI/BOOT/BOOTX64.EFI，用bcfg boot add 0 fs0:\EFI\BOOT\BOOTX64.EFI "Linux"加回去。这条命令我建议提前抄在笔记本上，因为出问题的时候机器是起不来的，查不了。

5.3 带外刷写卡在 30% 不动，任务一直 running

现象：通过 BMC 上传镜像后，任务进度停在某个百分比超过二十分钟，既不报错也不完成。

原因：BMC 到 Flash 的写入通道被占用，常见触发是刷写期间有人通过 SOL 或 Web 控制台做了电源操作，也可能是镜像放在一个带宽很差的链路上、传输层反复重传。

解决：先等，别急着断电，很多情况下它会在超时后自己回滚并报错。真要中断，只能 AC 断电，然后重新上电，固件一般会走一次恢复流程。预防上，镜像提前放到和 BMC 同网段的 HTTP 服务上，让 BMC 自己拉，而不是从本地通过浏览器上传。

5.4 升级后性能掉了两成，硬件看起来都正常

现象：跑分和业务延迟都变差，CPU 核数、内存容量、网卡速率全部正常。

原因：NUMA 被重置为关闭，内存全部挂在一个节点上，跨 socket 访存变成常态；或者内存交织的开关状态和原来相反。

解决：numactl -H看节点数，只有 1 就回 BIOS 打开 NUMA；再看交织设置是否符合业务预期。这一条之所以排进前五，是因为它不会报错，只会慢慢变慢，靠监控很难第一时间定位到固件。

5.5 同批机器刷完，有一台 BMC 失联

现象：批量升级完成后，大部分机器正常，个别机器 BMC 网络不通，但系统本身能跑。

原因：-all参数把管理引擎区段一起刷了，而这台的 BMC 固件版本比包里要求的基线还老，刷完不匹配，管理子系统起不来。

解决：到现场接显示器进系统，用系统内的带外管理工具重新刷一次 BMC 固件到匹配版本；如果系统也进不去，走主板的恢复跳线。预防的办法很直白：升级前先用mc info把所有机器的 BMC 版本扫一遍，低于发布说明要求基线的，先升 BMC 再升 BIOS。

6. 回滚与批量：把单机刷写变成可复用的流程

单台刷完不算有经验，能把这件事在二十台机器上不出岔子地做完，才算。回滚和批量这两件事要一起设计，因为批量的前提就是“每一台都能退回去”。

先说回滚的边界。固件回滚不是想退就退的：大部分厂商只保证相邻小版本之间可以回退，跨大版本回退会因为 NVRAM 结构不兼容直接拒绝，或者退回去之后配置全乱。所以升级前一定要确认三件事——旧版本镜像还留着、发布说明里明确写了“支持回退到 X 版本”、以及这台机器的业务允许再停机一次。三条有一条不满足，就别在业务机上试。

再说批量。我的做法是把流程拆成三段，每段都能单独停：先扫版本、再逐台刷、最后逐台验。

#!/usr/bin/env bash # 三段式批量升级骨架：扫描 -> 刷写 -> 验收，每段可单独执行 set -u HOSTS=$(cat hosts.txt) # 一行一个 BMC 地址 PASS=~/.ipmi_pass NEW_VER="2.68" echo "== 第一段：扫描当前版本，低版本的挑出来 ==" for h in $HOSTS; do cur=$(ipmitool -I lanplus -H "$h" -U admin -f "$PASS" fru print 2>/dev/null \ | grep -i "bios" | head -1) echo "$h -> $cur" done > scan_before.log echo "== 第二段：逐台刷写，一台失败就停，不往下滚 ==" for h in $HOSTS; do curl -k -s -u admin:"$(cat $PASS)" \ -X POST "https://$h/redfish/v1/UpdateService/update-multipart" \ -F 'UpdateParameters={"Targets":["/redfish/v1/Systems/1/Bios"],"@Redfish.OperationApplyTime":"OnReset"};type=application/json' \ -F "UpdateFile=@./rv2_bios_${NEW_VER}.bin" || { echo "$h 上传失败，中止"; exit 1; } echo "$h 已提交，等待下一次重启生效" sleep 30 done echo "== 第三段：重启后回读版本，逐台确认 ==" for h in $HOSTS; do ipmitool -I lanplus -H "$h" -U admin -f "$PASS" sol deactivate 2>/dev/null ipmitool -I lanplus -H "$h" -U admin -f "$PASS" chassis power cycle sleep 300 # 给内存训练留足时间，双路大内存别少于 5 分钟 ipmitool -I lanplus -H "$h" -U admin -f "$PASS" fru print | grep -i bios done > scan_after.log

第一段只读不写，输出一份升级前的版本清单，这份日志的价值在于事后追责——哪台机器本来就不该在名单里，一目了然。第二段用了OnReset而不是Immediate，镜像先落盘、等重启生效，好处是可以把所有机器一次性提交完，再统一安排停机窗口；|| exit 1是刻意加的，批量场景里最怕的就是脚本一路往下跑、把一台的错误复制到二十台。第三段的sleep 300是保守值，双路满配内存的机器第一次 POST 确实可能跑这么久，宁可多等也别在内存训练期间断电。

两个细节值得单独拎出来。一是hosts.txt和scan_*.log都放本地，不要放在任何一台被升级的机器上，因为那些机器会重启。二是每台刷完之后，把numactl -H和dmidecode -t bios的输出单独存一份到以 IP 命名的文件里，二十台的输出混在一个日志里，出问题的时候根本对不上是哪台。

有一个习惯是我从那以后一直保留的：不管多急，刷固件之前一定先把before_bios.txt、before_cpu.txt和一份 BIOS 配置导出的模板放进同一个以日期命名的目录，刷完再补一份after_*。这套东西平时没人看，真出事的时候它就是唯一能把“刷之前是什么样”还原出来的东西。固件这东西没有中间态，要么是好的，要么得靠现场那台机器慢慢救；多留一份记录，成本是五分钟，收益是少一次通宵。希望帮到你。

本文还有配套的精品资源，点击获取