R730xd 升 Linux 7.0 两次重置：一次 HWE 启动故障排查
2026-11-09 凌晨，我给一台 Dell PowerEdge R730xd 安装了 Ubuntu 24.04 的官方 HWE 内核。安装和 initramfs 检查都通过了，重启后机器却没回来：SSH 连不上，Kubernetes 节点也成了 NotReady。打开 iDRAC 虚拟控制台，看到的是 Dell 的 UEFI0078，还没到能从 Linux 查日志的阶段。
原配置下试了两次，两次都要从 GRUB 退回 6.8。后来在 BIOS 里同时启用 X2APIC、I/OAT DMA Engine 和 SR-IOV Global Enable，同一个 7.0.0-42-generic 才成功启动。两口 Intel I350 仍用 igb，没有换驱动。
这篇记录的是一次可复核的绕过，以及它的边界。故障节点记作 node-a，时间均为北京时间，省略内网地址、服务标签和账号信息。环境为 R730xd、BIOS 2.19.0、iDRAC8 2.86.86.86、Ubuntu 24.04 LTS，这台机器同时跑 Kubernetes 控制面和两个 Ceph OSD。
先把回退留在 GRUB 里
要升级的是内核，发行版继续用 Ubuntu 24.04。用官方 linux-generic-hwe-24.04 元包，现场从 6.8.0-94-generic 试到 7.0.0-42-generic。这两个编号是当时的实际版本，其他机器应以自己的包源为准。 Ubuntu HWE 生命周期
安装后核对了新内核的启动镜像和 PERC 所需的 megaraid_sas，把原 6.8 的内核、模块和额外模块保留下来。GRUB 开启菜单，saved default 指向已验证的 6.8，只用 grub-reboot 选择一次 7.0。这样即使 Linux 没起来，仍能从带外控制台显式选回旧内核。
集群侧先让业务 VIP 转到另一台节点，并从客户端验证状态页。确认 etcd 和 Ceph 有仲裁、两块本地 OSD 可以同时停机之后才排空。Rook 的 PDB 一开始挡住第二块 OSD 的驱逐，等它识别到单节点维护后自然放行。两块 OSD 离线时有数百个 PG 副本不足；PG 仍 active、状态页仍能访问，只能说明当时服务仍可用，不能把这个状态当作存储健康。
CPU 报错，不等于 CPU 损坏
第一次启动失败后，回退路径是通过控制台继续启动，再从 Advanced options for Ubuntu 选择 6.8.0-94-generic。Linux 回来后，ACPI BERT 带回一条上一轮的 fatal 记录，包含缓存和微架构错误，但失败启动没有留下可用的 7.0 journal。回到能登录的系统后，可以分开查实际内核、启动历史和 BMC 日志：
uname -rjournalctl --list-bootsjournalctl -k -b --no-pagersudo ipmitool -I open sel elist第二次在同样的配置下重试，故障再次出现。对照 iDRAC Lifecycle Log 和本机 SEL，可以把几条证据分开看：
| 来源 | 实际看到的内容 | 能确定什么 |
|---|---|---|
| Lifecycle Log | PWR2262、CPU0000、复位、UEFI0078，随后有 CPU0704 和 OEM 诊断记录 | Intel Management Engine 报过内部错误，固件也记录了上一次启动的 Machine Check；事件没有点名故障设备 |
| SEL | 04:18:16–17，CPU 1 和 CPU 2 都报告了不可恢复的 Machine Check | 两个插槽都有报告，不能仅凭其中一条 CPU0704 换 CPU |
| 回退后的 Linux | 6.8 能恢复 SSH、kubelet 和 Cilium，短时观察没有新同类错误 | 旧内核仍可作为回退；短时无复发不足以排除间歇性硬件问题 |
Dell 也把 CPU0704 定义为处理器检测到 Machine Check，实际错误可以来自处理器之外。现场还遇到一个时间坑：本机 IPMI 工具的显示和 Lifecycle 页面差了八小时，所以本文按带 +0800 的 Lifecycle 和解码后的 SEL 对齐，不用显示时间差推导故障顺序。 Dell Machine Check 说明
为什么试这三个 BIOS 开关
排查时找到一个很接近的 XC730xd 现场报告：同样是 BIOS 2.19.0、Intel I350（8086:1521），I350 同样挂在 00:1c.4 → 06:00.0/1。报告者在旧内核上正常，在较新的 PVE 内核加载 igb 时能复现重置；屏蔽驱动能启动，手动加载又能触发。同一讨论里，另一台 R730 启用 X2APIC 和 I/OAT 后仍失败，加上 SR-IOV 后才通过一次启动。 原始复现和 R730 对照
这条线索比直接换 CPU 更值得先验证。两台机器的内核构建和网卡固件并不相同，本站这台的 Lifecycle 也没有报出指向 I350 或上游端口的 PCIe 地址。两口管理网都在 igb 的 bond 上，在线屏蔽驱动会先断自己的管理链路，所以没有照搬屏蔽驱动的实验。
实际通过 iDRAC RACADM 查到三项原来都为 Disabled，Above 4G MMIO 原来已开启。第三次只改了下表三项：
| 开关 | 管什么 | 启动后看到什么 |
|---|---|---|
| X2APIC Mode | 扩展 APIC 的中断寻址和路由 | Linux 明确记录 BIOS 已启用 x2APIC，并切换到对应路由 |
| I/OAT DMA Engine | 暴露硬件数据搬运引擎，供支持的软件卸载部分内存复制 | 枚举到了 Intel DMA 通道 |
| SR-IOV Global Enable | 允许支持的 PCIe 设备提供可分配的虚拟功能（VF） | BIOS 作业完成；测试没有创建 VF，两口 I350 仍用 igb |
这些是平台配置，不是 Linux 7.0 的通用前置条件。 Dell 处理器设置 · Dell 集成设备设置 · Linux SR-IOV 说明
实际操作是在目标服务器的 iDRAC SSH 会话中先确认没有其他待应用的 BIOS 变更，再将三项排成同一个作业：
racadm set BIOS.ProcSettings.ProcX2Apic Enabledracadm set BIOS.IntegratedDevices.IoatEngine Enabledracadm set BIOS.IntegratedDevices.SriovGlobalEnable Enabledracadm jobqueue create BIOS.Setup.1-1创建作业时不加 -r，让宿主机在排空并复核仲裁后发起受控重启，GRUB 仍只试一次 7.0。中途 SSH 和 kubelet 都不可达，作业一度仍是 Scheduled；等到 Lifecycle 出现 PR6、作业完成、系统重新上线，才确认 BIOS 配置已经应用。这里不能把重启中的 SSH 超时直接当成又一次失败。 Dell RACADM 作业说明
验收：网络要走通，卷要重新挂载
第三次成功启动后，uname -r 确认为 7.0.0-42-generic。I350 重新枚举到了 07:00.0/1，仍由 igb 驱动，原 bond 正常。地址改变说明这次枚举结果不同，不能倒推出原来就是 PCIe 地址分配错了。
- 控制面和网络：etcd 三成员健康；Cilium 四节点的主机与端点探测通过。再在
node-a上用临时 Pod 验证 DNS、跨节点 Pod、ClusterIP 和业务 VIP。 - 存储：RBD 和 CephFS 分别写入 64 KiB 数据。删除测试 Pod，核对旧挂载消失，再在同节点重建 Pod，两个卷重新挂载后的 SHA-256 均一致。测试资源随即清理。
- 集群状态：两块 OSD 恢复后，Ceph 回到 8/8 OSD up/in，513 个 PG 全部
active+clean，只剩原有的 CephX 告警。其他节点没有改动，业务 VIP 继续留在原先接手的节点。 - 硬件与回退：再次核对 SEL 和内核日志，没有新 Machine Check、致命 PCIe AER 或 I/O 错误。短时验收通过后才把这一版 7.0 设为 GRUB 默认项，仍保留 6.8 菜单和模块；改默认项时没有再重启。
这次能确定的是：原配置失败两次，三项 BIOS 开关一起启用后，同一个 7.0 内核成功启动一次，并通过了网络和存储检查。 没有逐项关回去做对照，没有抓到失败时的指令，也没有做长期运行或再次冷启动。它是一条在这台机器上验证过的恢复路径，不是所有 R730xd 的修复结论。另一个容易漏掉的边界是：从 GRUB 回到 6.8 只回退内核，不会撤销已经应用的 BIOS 配置。