AC启动，概率出现组件启动异常，有日志提示StartupCheck failed，影响PCIe卡加载

ubmc_assistant · 2026 年2 月 9 日 14:01

答案内容由AI生成，仅供参考：

总结

项目	内容
问题类型	概率性启动失败
根本原因	D-Bus服务未注册、组件未配置为高可用、启动时序竞争
关键日志	`org.freedesktop.DBus.Error.ServiceUnknown: The name bmc.kepler.* was not provided by any .service files`
影响	PCIe设备加载失败、丝印缺失、BIOS通信异常
修复建议	1. 确认服务文件存在 2. 配置高可用启动项 3. 添加启动依赖 4. 增加重试机制

建议立即行动：将 pcie_device、bios、compute 等关键组件加入 launch_control.json 的高可用列表，并验证其.service文件是否随镜像正确部署。

点击此处查看详细分析解答

AC启动时组件启动异常问题分析与定位

问题概述

在执行AC启动时，概率性出现多个关键组件启动异常，日志中频繁出现 StartupCheck failed 错误，导致 PCIe卡加载失败、丝印信息未生成、BIOS上报信息丢失等问题。该问题在329次AC测试中复现5次，属概率性故障，严重影响系统稳定性和设备识别。

问题现象

组件启动失败：
- 日志显示 StartupCheck failed，错误为 org.freedesktop.DBus.Error.ServiceUnknown。
- 涉及组件包括：
  - compute（服务名：bmc.kepler.compute）
  - bios（服务名：bmc.kepler.bios）
  - pcie_device（服务名：bmc.kepler.pcie_device）
  - certificate（状态为 Starting，初始化未完成）
功能影响：
- PCIe设备无法正常加载（因pcie_device组件未就绪）。
- 丝印信息未生成（可能因组件未及时启动，错过初始化流程）。
- BIOS上报信息失败（bios组件异常导致错过通信时机）。
- 系统健康检查异常，影响后续管理功能。

日志特征：

[maca ERROR] init.lua(186): [pcie_device]StartupCheck failed, error: org.freedesktop.DBus.Error.ServiceUnknown: The name bmc.kepler.pcie_device was not provided by any .service files

表明 D-Bus服务未注册，系统在启动检查时无法找到对应的服务文件。

根本原因分析

1. D-Bus服务未注册或加载失败

根据知识库中DBUS Error ServiceUnknown的定义：

“DBUS Error ServiceUnknown is a runtime error indicating that a requested D-Bus service is not available in the system. It occurs when a requested D-Bus service name is not registered or available.”

该错误表明，指定的D-Bus服务（如bmc.kepler.pcie_device）虽应在系统中存在，但在启动时未能成功注册或其.service文件缺失或未被加载。

结合文档【MACA】问题定位方法&FAQ中对平滑重启的描述：

“平滑重启先通知组件重启准备，如果有组件重启准备失败，则通知组件取消重启并返回失败”

可推断：组件自身加载逻辑或依赖服务未能及时响应，导致D-Bus服务未注册成功。

2. 组件启动时序竞争或资源竞争

错误集中在AC启动阶段，为概率性问题，说明存在时序或资源竞争。
pcie_device 和 bios 组件对PCIe拓扑和BIOS通信高度依赖。
若bios组件未就绪，pcie_device可能无法获取必要的BDF信息（如知识库中PcieAddrInfo需BIOS分配的BDF），从而无法完成初始化。
hwdiscovery日志中出现shm reply failed, message_queue push back: data size too large，表明共享内存消息队列溢出，进一步说明系统在启动初期存在高负载或消息拥塞。

3. 组件未正确配置为高可用或关键启动项

根据知识库文档：

“可以检查一下manifest/build/product/BMC/openUBMC/rootfs/opt/bmc/apps/hica/subsys/里面有没有配置高可用组件”

以及：

“在launch_control.json中已经增加了必要启动的高可用组件，服务报错没了”

说明：若关键组件未在launch_control.json中正确声明为必须启动项或高可用组件，可能在资源紧张时被延迟或跳过启动，导致StartupCheck失败。

影响的组件及其作用

组件名	D-Bus服务	功能描述	失败影响
pcie_device	`bmc.kepler.pcie_device`	管理PCIe设备拓扑、BDF计算、设备注册	PCIe卡无法识别、带外管理失败、拓扑信息缺失
bios	`bmc.kepler.bios`	与BIOS通信，获取启动信息、配置参数	BIOS信息上报失败、丝印信息生成失败
compute	`bmc.kepler.compute`	资源管理与计算节点控制	计算资源不可用、系统资源视图不完整
certificate	`bmc.kepler.certificate`	安全证书管理	安全功能不可用，可能影响安全启动或认证

定位与修复建议

1. 确认服务文件是否存在并正确注册

检查以下路径是否存在对应.service文件：

/usr/lib/systemd/system/bmc.kepler.pcie_device.service
/usr/lib/systemd/system/bmc.kepler.bios.service
/usr/lib/systemd/system/bmc.kepler.compute.service

若文件缺失，需确认该组件是否被正确打包进BMC镜像。
若存在，检查是否通过systemctl list-units --type=service | grep bmc.kepler确认其被systemd识别。

2. 检查组件是否配置为“高可用”或“关键启动项”

检查 launch_control.json 是否包含以下组件：

{
  "components": [
    "pcie_device",
    "bios",
    "compute",
    "certificate"
  ],
  "high_availability": true
}

若未配置，需将其添加为高优先级启动组件，确保在系统启动早期被加载。

3. 优化启动时序与依赖关系

在pcie_device中明确声明对bios的依赖：

# bmc.kepler.pcie_device.service
[Unit]
Requires=bmc.kepler.bios.service
After=bmc.kepler.bios.service

避免因bios服务未就绪导致pcie_device启动失败。

4. 增加启动重试与超时容忍机制

修改StartupCheck逻辑，对ServiceUnknown错误增加指数退避重试。
增加最大检查次数（如从8次增至15次），特别是在AC启动等慢速场景下。

5. 排查共享内存（SHM）与消息队列瓶颈

hwdiscovery出现message_queue push back: data size too large，建议：
- 增大消息队列缓存。
- 异步处理设备发现结果，避免阻塞主线程。

6. 日志与诊断增强

在组件main.lua中增加pcall包装，捕获启动异常并输出详细堆栈。
使用journalctl -u bmc.kepler.pcie_device -f监控服务启动过程。

参考解决方案（来自知识库）

来自文档#3与#9：

“在launch_control.json中已经增加了必要启动的高可用组件，服务报错没了”

结论：将pcie_device、bios等组件配置为高可用，可有效避免此类问题。
来自文档#4：

“新增IPMI命令后未注册，导致pcie_device启动异常”

说明：任何新功能或命令引入后，必须确保服务注册完整，否则会破坏启动流程。

总结

项目	内容
问题类型	概率性启动失败
根本原因	D-Bus服务未注册、组件未配置为高可用、启动时序竞争
关键日志	`org.freedesktop.DBus.Error.ServiceUnknown: The name bmc.kepler.* was not provided by any .service files`
影响	PCIe设备加载失败、丝印缺失、BIOS通信异常
修复建议	1. 确认服务文件存在 2. 配置高可用启动项 3. 添加启动依赖 4. 增加重试机制