2512签名包启动过程中服务启动失败

CICD SIG
2

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

25.12签名包启动过程中服务启动失败问题分析

根据您提供的framework.log日志内容，并结合相关技术文档与知识库信息，现对25.12版本签名包升级后服务无法正常启动的问题进行全面分析和定位。

:magnifying_glass_tilted_left: 一、核心问题定位

您的系统在成功升级签名包后无法正常启动，主要问题集中在framework.log中大量报错，其根本原因可归纳为两类：

  1. DBus服务无法注册或未提供（DBUS Error: ServiceUnknown）
  2. 关键对象路径缺失（UnknownObject）与资源配置错误

这些错误导致MACA（Main Control and Agent）框架的启动检查失败，进而引发多服务无法正常启动，最终系统处于异常状态。

:firecracker: 二、关键错误类型与日志分析

1. DBUS Error: Service Unknown — 服务未注册

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

:white_check_mark: 含义：

  • 表示系统试图访问一个名为 bmc.kepler.ai_engine 的 D-Bus 服务，但该服务未在系统中注册。
  • init.lua 是系统初始化脚本，其中的 StartupCheck 模块会检查各个服务是否已成功注册到 D-Bus。
  • 此类错误反复出现在多个组件（如 cooling, dcmid, license, metric_analyzer, trust, redisfit 等）。

:puzzle_piece: 关联实体：

  • Dbus Error Service Unknown（知识图中实体）
  • StartupCheck Failed：因依赖的 D-Bus 服务缺失导致
  • IBMC Framework: 日志由该系统框架记录
  • init.lua: 启动检查逻辑执行入口

:pushpin: 常见原因：

  • 对应组件的 .service 文件未正确生成或部署
  • 组件未被编译进最终固件包
  • Conan包依赖缺失或版本不匹配
  • 签名过程中某些组件被遗漏或替换失败

:warning: 注意：多个模块同时出现此类错误，表明这是全局性构建/打包问题，而非单一服务故障。

2. Unknown Object Path — 对象路径不存在

maca ERROR: init.lua(184): [ddns]StartupCheck failed, error: org.freedesktop.DBus.Error.UnknownObject: Unknown object path /bmc/kepler/ddns/MicroComponent

:white_check_mark: 含义：

  • 表示服务已启动，但其预期的 D-Bus 对象路径 /bmc/kepler/ddns/MicroComponent 未成功注册。
  • 通常由服务内部初始化逻辑错误引起，例如未正确实例化 MicroComponent。

:puzzle_piece: 关联实体：

  • MicroComponent：作为 D-Bus 对象路径的一部分，存在于多个子系统中
  • Unknow Object Path：知识图中明确标识此为一种错误类型
  • product_mgmt 和 General Hardware 模块也曾因类似问题启动失败（参考上下文）

:pushpin: 可能原因：

  • 服务代码中未调用 dbus_export 或 add_object 注册该路径
  • MicroComponent 初始化脚本缺失或路径配置错误
  • 服务加载了错误版本的库文件

3. 配置文件缺失 — launch_control_00_ff.json does not exist

unknown_service ERROR: init.lua(56): launch_control_00_ff.json does not exist.

:white_check_mark: 含义：

  • 初始化过程中需要读取 launch_control_00_ff.json 文件，但文件不存在。
  • 该文件可能是用于定义某些低级硬件控制策略或电源管理配置。

:puzzle_piece: 关联实体：

  • Initialization Error：由缺失必要 JSON 配置文件引发
  • Framework Launch：此错误发生在框架启动阶段

:pushpin: 常见原因：

  • 构建过程中该配置文件未包含在包中
  • 文件路径硬编码错误或未适配目标平台
  • 自定义 manifest.yml 配置遗漏了必要的资源配置项

4. devmon 服务缺失导致依赖服务初始化失败

fetch devmon objects failed, err=org.freedesktop.DBus.Error.ServiceUnknown: The name bmc.kepler.devmon was not provided by any .service files

出现在 hwpromx, soctrl, mcgpd, chassis, network_adapter 等模块中。

:pushpin: 潜在影响：

  • devmon（Device Monitor）是硬件发现与监控的核心服务。
  • 多个硬件模块（如网络适配器、存储、FPGA）依赖 devmon 提供设备信息。
  • 其缺失将导致整个系统的硬件抽象层瘫痪。

5. 其他辅助性错误

日志片段 分析
nosi cmd ctrl select package failed NCSI（网络控制接口）命令执行失败，可能因底层驱动未加载或 MAC 地址配置问题
set fpga initial mux failed FPGA 初始多路复用设置失败，可能与固件初始化顺序或 VRD/MCU 通信异常有关
open /data/var/log/vrd/MCU_CLI_010103 failed MCU 日志文件打开失败，提示 VRD 服务或硬件代理未准备就绪

:hammer_and_wrench: 三、根因推断与排查建议

:magnifying_glass_tilted_right: 根本原因推测

结合日志中多组件集中性失败这一现象，判断最可能的原因是：

:white_check_mark: 签名包制作过程中，部分组件未被正确打包或签名失败导致文件损坏，造成多个服务的 .service 文件丢失或不可用。

这可能是由于以下原因之一引起的：

  • 使用了不兼容的 bmcgo 工具版本进行签名（应确保使用与 25.12 SDK 兼容的版本）
  • manifest.yml 中签名配置错误（如路径、文件名后缀 .der/.pem 不一致）
  • 白牌包或定制内容覆盖了关键系统组件
  • 构建环境 Conan 缓存损坏或依赖解析失败

:pushpin: 参考案例：文档 bingo build -b openUBMC -r openubmc_dev报错签名失败（ID:7）中提到，签名失败后若继续使用残缺包，会导致服务缺失。

:white_check_mark: 四、解决方案与操作建议

1. 验证签名工具和 SDK 版本兼容性

确保使用的是 BMC SDK Version 25.12 推荐的版本：

  • :white_check_mark: 下载地址：Index of /25.12/sdk/
  • :white_check_mark: 推荐使用 bmcgo 工具生成签名包
  • :cross_mark: 避免使用旧版 SDK 或 bingo 直接签名（bingo 不支持完整白牌包签名）
# 检查工具版本
bmcgo --version
# 输出应支持 25.12 流程

2. 检查并修正 manifest.yml 签名配置

确认 manifest.yml 中 signature 字段配置正确，尤其是证书路径与文件后缀：

signature:
  certificates:
    rootca_der: ${product}/ca/rootca.der
    signer_pem: ${product}/ca/signer.pem
    timestamp_signer_pem: ${product}/ca/ts_signer.pem
    timestamp_signer_cnf: ${product}/ca/tsa.cnf
    rootca_crl: ${product}/ca/rootca.crl

:warning: 若签名文件扩展名为 .pem.enc 而非 .pem，必须在配置中显式声明，否则签名失败。

3. 重新构建签名包并验证完整性

# 清理 Conan 缓存（必要时）
rm -rf ~/.conan/data   # Conan v1
rm -rf ~/.conan2/p     # Conan v2

# 重新执行 bingo build
bingo build -b openUBMC -r openubmc_dev

# 使用 bmcgo 重新签名 HPM 包
bmcgo sign --input rootfs_openUBMC.hpm --output signed.hpm --config sign_config.json

4. 升级前验证包结构完整性

解压 .hpm 包，检查是否包含以下关键文件：

  • /lib/systemd/system/*.service （如 ai_engine.service, cooling.service）
  • 所有组件的 main.lua 和 init.lua
  • launch_control_00_ff.json 是否存在

5. 日志进一步排查路径

日志文件 用途
/var/log/framework.log 查看服务注册与启动失败详情
/var/log/app.log 查看具体服务内部错误（如 Lua 脚本崩溃）
journalctl -u bmc_core 查看 systemd 管理的服务状态
busctl --system list-names 检查当前已注册的 D-Bus 服务

:toolbox: 五、预防建议

措施 说明
:white_check_mark: 严格遵循《组件集成出包指导-25.12版本-v1.0》流程 确保签名步骤、工具、配置一致
:white_check_mark: 构建前清理 Conan 缓存 防止旧依赖干扰
:white_check_mark: 升级前在仿真环境（QEMU）测试签名包 快速验证服务可启动性
:white_check_mark: 使用 bmcgo 替代 bingo 执行签名操作 支持更完整的签名流程
:white_check_mark: 保留过渡包用于降级恢复 避免系统变砖风险

:white_check_mark: 总结

问题类型 分析结论 建议措施
ServiceUnknown 多个服务 .service 文件未注册，极可能因签名包构建失败或组件缺失 重新使用正确版本 bmcgo 签名
UnknownObject MicroComponent 对象路径未注册，服务内部初始化失败 检查服务代码与 D-Bus 导出逻辑
launch_control_00_ff.json 不存在 构建时资源配置遗漏 确保 manifest.yml 包含必要资源文件
devmon 缺失 硬件监控服务未启动，引发连锁故障 验证 devmon 组件是否被打包

:light_bulb: 最终建议：重新按照官方25.12流程构建签名包，使用bmcgo工具签名，并先在QEMU中验证服务启动情况，再烧录到实际设备。

如有需要，可提供签名包的目录结构及 manifest.yml 内容以进一步协助诊断。

相关链接：

  1. 25.03版本第一次maca组件检测会出现53组件只有7个起来，maca重新拉起后所有组件才起来
  2. hpm签名包升级失败
  3. general_hardware 服务部署问题
  4. QEMU仿真问题
  5. 升级常见问题指南 | 文档中心 | openUBMC