拉最新的manifest库编译出版本之后，升级bmc包之后再次升级bmc包就出错

交流互助区
1

// 此模板仅供参考，如果不适用可以修改

问题描述

[在这里详细描述您遇到的问题]

环境信息

  • 操作系统：[如 Ubuntu 24.04]

  • 软件版本：[如 OpenUBMC2609]

image
image2471×911 186 KB

  • 硬件配置：[如 CPU、内存等]

重现步骤

  1. [第一步]

  2. [第二步]

  3. [第三步]

期望结果

可以正常升级bmc的固件

[您希望实现什么]

实际结果

2026-07-14 02:27:23.727814 firmware_mgmt ERROR: validate_sign.lua(368): FirmwareUpgradeError: An error occurred during the firmware upgrade process. Details: add crl file is error, file is: /dev/shm/upgrade/1518612179/cms.crl, code 88200102
2026-07-14 02:27:23.728784 firmware_mgmt ERROR: task_instance.lua(253): parse package(rootfs_openUBMC.hpm) failed, ret:InvalidFirmwarePackage.
2026-07-14 02:27:23.733225 firmware_mgmt WARNING: harbor_client.lua(386): Receiver Skynet message queue scheduling delay is 639 ms (threshold: 500 ms), service_name=bmc.kepler.firmware_mgmt, path=/bmc/kepler/UpdateService, interface=bmc.kepler.UpdateService, method_name=GetUpdateProgress
2026-07-14 02:27:23.833332 firmware_mgmt NOTICE: task_mgmt.lua(174): task[Id: 1518612179, StartTime: 2026-07-14T02:27:19+00:00, Progress: 0, State: Exception] will be destroyed after 10 minutes
2026-07-14 02:27:23.834041 firmware_mgmt NOTICE: task_mgmt.lua(445): Update task[Id: 1518612179, StartTime: 2026-07-14T02:27:19+00:00, Progress: 0, State: Exception] successfully
2026-07-14 02:27:23.836264 firmware_mgmt ERROR: state_handle.lua(155): not find state obj
2026-07-14 02:27:24.907322 firmware_mgmt NOTICE: tasks_scheduling.lua(170): upgrade queue is empty, exit the tasks processor
2026-07-14 02:27:24.907718 firmware_mgmt NOTICE: tasks_scheduling.lua(202): stop tasks processor
2026-07-14 02:27:24.909138 firmware_mgmt NOTICE: active_fructl.lua(96): get host type is Singlehost

[实际发生了什么，包含错误信息]

image
image2555×820 286 KB

image
image1340×815 37.6 KB

尝试过的解决方案

[列出您已经尝试过的解决方案及结果]

分析结论

[详细总结您对此问题的分析结论]

2

答案内容由AI生成，仅供参考：
根据您的要求，原样提取内容如下：

分析结论

您遇到的问题与 HPM 包的签名验证环节直接相关，具体是 CRL 文件添加失败引起 InvalidFirmwarePackage 错误。社区已有多个类似案例（Chunk 6、Chunk 8），均出现在先升级过渡包再升级自签名包的过程中。

核心建议（基于上下文信息）：

  • 参考 Document Chunk 5 中描述的签名包结构，检查第二次编译产生的 HPM 包是否完整包含了 CRL 吊销列表。
  • 确认签名工具链是否一致，若使用 bmcgo 签名，需确保已按照对应文档正确放置根证书、签发证书和 CRL 文件（如 ca/rootca.crl）。
  • 参考 Chunk 6 中关于伙伴签名的讨论，可能需要调整 manifest.yml 中 board_name 或开启 manufacture 模式以避免签名冲突。

如果问题持续，建议在社区论坛（如 discuss.openubmc.cn）提供完整的升级包构建日志和 manifest.yml 配置，以便进一步诊断签名流程中的具体断点。

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

问题分析

根据您提供的错误日志，核心问题出现在第二次升级时 firmware_mgmt 模块的签名验证环节：

firmware_mgmt ERROR: validate_sign.lua(368): FirmwareUpgradeError: Details: add crl file is error, file is: /dev/shm/upgrade/1518612179/cms.crl, code 88200102

随后提示 parse package(rootfs_openUBMC.hpm) failed, ret:InvalidFirmwarePackage，表明升级包因无法正确添加 CRL（证书吊销列表）文件而被判定为无效固件包。

相关上下文信息

来源 内容 关联性
Document Chunk 5（hpm 包格式说明） 签名 HPM 包由 包头、签名原文、CMS 签名、CRL 吊销列表、裸 HPM 包 五部分组成。CRL 是签名根证书的吊销列表。 直接说明 CRL 是签名验证的必要组成部分，“add crl file is error”意味着该部分缺失或无效。
Document Chunk 6（25.03 构建与伙伴签名问题） “使用社区的 dockerfile 创建镜像编译，刷完过渡包再升级之后升级失败，显示无效的升级包，查看日志显示签名校验不通过”。 描述了完全相同的场景：先升级过渡包（可能未签名或使用社区签名），再升级自签名包，结果因签名校验失败而报错。
Document Chunk 8（hpm 签名包升级失败） “开发板是先升级了前面那个过渡包（bingo生成的），升级成功并且开发板正常运行后再升级的签名包（bmcgo生成的），然后显示升级失败”。 再次印证该操作模式（过渡包 → 签名包）容易导致第二次升级失败。
KG Relationship：BMC Firmware Upgrade → Invalid Upgrade Package Error “BMC firmware upgrade fails when using a community发行版due to an invalid upgrade package error”。 概括了使用社区版本时升级包因签名问题被拒绝的典型错误。
KG Entity：Firmware File Mismatch “Firmware File Mismatch occurs during the upgrade of the BMC Firmware Package due to configuration mismatch.” 可能指向签名配置或证书不匹配导致的升级失败。

可能原因

  1. CRL 文件缺失或生成错误
    根据 Chunk 5，签名包必须包含 CRL。若第二次编译时未正确添加 CRL（例如证书路径配置不对、未使用 hpm_signer 工具重新生成完整的签名结构），升级时 validate_sign.lua 将无法成功添加 CRL 文件，从而报错。

  2. 签名证书链不一致
    第一次升级的过渡包可能只包含基础签名（如社区默认证书），而第二次升级的自签名包使用了不同的根证书和 CRL。BMC 在升级过程中会校验 CRL 的完整性和与证书的匹配关系，若不匹配则抛出错误。

  3. 升级后文件系统状态变化
    错误中 CRL 路径为 /dev/shm/upgrade/...，该临时目录可能在第一次升级后被清理或权限受限，导致第二次升级时 CRL 写入失败。

  4. 构建工具或配置差异
    如 Chunk 6 所提示，使用不同的构建工具（bingo vs. bmcgo）或未正确修改 manifest.yml 中的签名相关配置（如 ca 目录、签名策略）均可能导致包结构不正确。

分析结论

您遇到的问题与 HPM 包的签名验证环节直接相关，具体是 CRL 文件添加失败引起 InvalidFirmwarePackage 错误。社区已有多个类似案例（Chunk 6、Chunk 8），均出现在先升级过渡包再升级自签名包的过程中。

核心建议（基于上下文信息）：

  • 参考 Document Chunk 5 中描述的签名包结构，检查第二次编译产生的 HPM 包是否完整包含了 CRL 吊销列表。
  • 确认签名工具链是否一致，若使用 bmcgo 签名，需确保已按照对应文档正确放置根证书、签发证书和 CRL 文件（如 ca/rootca.crl）。
  • 参考 Chunk 6 中关于伙伴签名的讨论，可能需要调整 manifest.yml 中 board_name 或开启 manufacture 模式以避免签名冲突。

如果问题持续，建议在社区论坛（如 discuss.openubmc.cn）提供完整的升级包构建日志和 manifest.yml 配置，以便进一步诊断签名流程中的具体断点。

3

伙伴反馈：
操作1、使用tag： 26.06_2026.06.30的manifest升级BMC正常
操作2、使用主干最新manifest升级BMC后，就不能继续升级了

估计是最新manifest调整过相关校验机制，需要继续定位

4

开发者本地出包不能使用community_sign_webvnc_1711配置整包，只能使用community_unsign_webvnc_1711配置，否则将导致后续验签无法通过导致升级失败

5

我什么都没有改，直接在manifest库里 bingo build 出包，然后升级该包。升级之后再次升级这个包就报错。

6

什么都没有改才会有问题，当前社区manifest配置的是community_sign_webvnc_1711整包，使用这种包升级后就会打开升级验签功能，开发者本地出包需要改为community_unsign_webvnc_1711