2509 general_hardware组件构建报错

CICD SIG
1

如图，构建general_hardware组件时报错：

image
image1421×229 12.5 KB

但是出整包正常：

image
image1626×834 109 KB

报错的libmgmt_protocol/1.80.43@openubmc/stable来自于社区2509_sdk仓：
image

请问这个问题要如何解决？

2

答案内容由AI生成，仅供参考：
:white_check_mark: 总结

项目 内容
问题根源 libbmc_protocol 的 source() 方法中访问 'pwd' 键失败，因构建上下文缺失或缓存损坏
为何整包成功 整包使用现成二进制缓存，跳过了 source() 源码构建阶段
根本原因 本地环境不匹配（特别是 bmc_sdk 未使用官方配套版本）
推荐方案 重新使用官方 2509 初始 bmc_sdk 环境 + 清理缓存 + 执行 bingo build -t install_sdk

:white_check_mark: 最终建议操作顺序：

rm -rf ~/sdk ~/rtos_compiler ~/.conan2/p/
# 下载官方 2509 bmc_sdk.zip，解压并复制 sdk/ rtos_compiler/ 到 ~/
cd manifest
bingo build -t install_sdk
bingo build general_hardware

如仍失败，请提供：

  • conan remote list 输出
  • conan --version
  • bmc_sdk 和 manifest 的具体来源链接

我们将进一步排查。

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

问题分析与解决方案：general_hardware 组件构建报错 KeyError: 'pwd'

根据您提供的信息，general_hardware 组件在使用 conan create 构建时失败，错误信息为：

ERROR: KeyError: 'pwd'
ERROR: 执行命令 conan create --name general_hardware ...

尽管如此，整包构建却可以正常完成。下面将结合知识库中的上下文，对问题进行深入分析并提供解决方案。

:magnifying_glass_tilted_left: 问题定位

1. 错误本质：KeyError: 'pwd'

  • 这是一个典型的 Conan 运行时异常（ConanException），由 KeyError 触发。
  • 根据知识库，KeyError.Pwd 是指在执行 source() 方法时，无法在上下文中找到 'pwd' 键。
  • 错误发生位置：在 libbmc_protocol/1.80.43@openubmc/stable 的 source() 方法中调用时触发。
  • 技术路径：
    conan create ... → 下载/解压依赖 → libbmc_protocol → source() → 调用 'pwd' → KeyError

:white_check_mark: 关键点：该问题并非 general_hardware 本身代码导致，而是其依赖项 libbmc_protocol 在源码处理阶段因环境变量或配置缺失而崩溃。

2. 为何整包构建成功，但单独组件构建失败？

从您附带的日志可以看出：

  • 整包构建成功，且明确显示：
    libgmm_protocol/1.80.43@openumbc/stable: Already installed! (4 of 128)

    :warning: 注意：包名为 libgmm_protocol，而报错包是 libbmc_protocol —— 存在命名差异。

进一步分析：

场景 包管理行为
整包构建 直接安装已构建好的二进制缓存（Cache），跳过了 source() 阶段
单独构建 general_hardware 触发从源码构建依赖项（Build missing），导致进入 source() 流程

:backhand_index_pointing_right: 因此，根本原因在于：当 Conan 遇到未缓存或强制重建的依赖时，会尝试从源码构建，从而触发 source() 中对 'pwd' 的访问，但当前上下文未正确初始化，导致 KeyError。

3. 深层原因分析

可能原因 1：Conan 配置不完整或环境上下文缺失

  • source() 方法可能依赖一个名为 'pwd' 的键（代表当前工作目录路径），但在某些构建流程中未注入。
  • 例如：本地开发环境未完全同步社区 SDK 的配置文件或 profile。

可能原因 2：本地 Conan 缓存状态异常

  • 本地有部分包缓存损坏或版本不匹配，导致 Conan 误判需要从源码重建。
  • 文档中多次出现 WARN: Trying to remove corrupted source folder 提示，表明源码目录可能已损坏。

可能原因 3：bmc_sdk 与 manifest 版本不配套

  • 多个用户反映：使用了 2509 版本的配置，但实际 bmc_sdk 或 manifest 来源不一致。
  • 文档块 2 明确指出：

    “这种问题一般为开发者本地 bmc_sdk 和当前版本依赖不配套”

:white_check_mark: 解决方案

:white_check_mark: 方案一：确保使用匹配的 bmc_sdk 环境

这是最常见且有效的解决方式。

步骤如下：

  1. 确认当前构建版本为 2509

    # 检查 manifest 分支
git branch
git log -n1

  2. 清理旧环境

    rm -rf ~/sdk ~/rtos_compiler ~/.conan2/p/

  3. 下载官方配套的 2509 bmc_sdk 初始包

    • 从 openubmc.cn 官网 下载对应版本的 bmc_sdk.zip
    • 解压后复制 sdk 和 rtos_compiler 到 ~ 目录

  4. 重新执行依赖安装

    cd manifest
bingo build -t install_sdk

  5. 再尝试构建组件

    bingo build general_hardware

:pushpin: 注意：许多用户反馈即使版本看似一致，也因非官方渠道获取的 bmc_sdk 导致问题。务必使用官方发布的初始环境包。

:white_check_mark: 方案二：避免源码构建，优先使用二进制缓存

如果目标是快速构建组件，而非调试依赖项，应避免触发 source() 阶段。

操作建议：

  1. 显式指定使用远程二进制（不构建缺失项）：

    conan create . --build=never

  2. 或仅构建目标组件本身，其他依赖全部使用缓存：

    conan create . --build=general_hardware/*

:light_bulb: 原理：通过 --build=never 或 --build=<your_component> 防止 Conan 对 libbmc_protocol 等依赖执行 source()，从而绕过 KeyError。

:white_check_mark: 方案三：升级 Conan 并检查兼容性

  • 您使用的 Conan 版本可能为 2.x，而某些旧版组件（如 libbmc_protocol）的 conanfile.py 可能存在向后兼容问题。
  • 推荐使用社区推荐版本（目前多为 2.24.0）：
    conan --version
pip install conan==2.24.0

:white_check_mark: 方案四：手动修复缓存问题（可选）

如果确认包已损坏，执行：

# 清除特定包缓存
conan remove libbmc_protocol/1.80.43@openubmc/stable -f

# 或清除所有
conan remove "*" -f

然后重新运行构建，允许它从远程下载完整包。

:hammer_and_wrench: 预防措施

措施 说明
:white_check_mark: 使用官方初始环境包 确保 bmc_sdk、manifest、docker 镜像版本严格配套
:white_check_mark: 定期清理本地 Conan 缓存 防止旧/损坏缓存干扰新构建
:white_check_mark: 使用 bingo build -t install_sdk 确保依赖项正确安装
:white_check_mark: 构建前执行 conan remote list 验证远程仓库配置无误

:puzzle_piece: 补充说明：关于 pwd 的用途

虽然具体实现未披露，但从逻辑推断：

  • 在 conanfile.py 的 source() 方法中，可能存在如下代码：
    def source(self):
    self.run(f"tar -xzf {self.conan_data['sources'][self.version]['url']} -C {self.conf.get('user.pwd')}")
  • 若 self.conf.get('user.pwd') 未设置，则触发 KeyError: 'pwd'。

该问题反映了一个配置缺陷：不应将关键路径信息以未保护方式访问。

:white_check_mark: 总结

项目 内容
问题根源 libbmc_protocol 的 source() 方法中访问 'pwd' 键失败，因构建上下文缺失或缓存损坏
为何整包成功 整包使用现成二进制缓存，跳过了 source() 源码构建阶段
根本原因 本地环境不匹配（特别是 bmc_sdk 未使用官方配套版本）
推荐方案 重新使用官方 2509 初始 bmc_sdk 环境 + 清理缓存 + 执行 bingo build -t install_sdk

:white_check_mark: 最终建议操作顺序：

rm -rf ~/sdk ~/rtos_compiler ~/.conan2/p/
# 下载官方 2509 bmc_sdk.zip，解压并复制 sdk/ rtos_compiler/ 到 ~/
cd manifest
bingo build -t install_sdk
bingo build general_hardware

如仍失败，请提供：

  • conan remote list 输出
  • conan --version
  • bmc_sdk 和 manifest 的具体来源链接

我们将进一步排查。

3

上周不管是整包构建还是组件构建都可以，且之后没有手动修改过本地sdk、bingo、bmcgo的版本，为何本周不行了，请问应该如何定位导致二进制组件不可用的具体变动点？

4

请详细列出构建general_hardware的依赖日志

5

并列出conan remote list

6

着重看依赖组件的版本和整包构建是否存在明显差异

1 个赞
7

找到原因了，虽然直接报错是libmgmt_protocol，但是异常的版本不只是这个组件，应该是存在依赖关系，还有libmc4lua和libsoc_adapter。将这两个组件的版本号修正就好了。

应该是在已经出过一次整包的情况下（二进制缓存本地都有了），我构建组件时就没有再指定conan仓，结果编译时自动从错误的conan仓拉了版本更高的组件。

8

在编译组件时可新增参数-nc，这样可以使用本地缓存不再去远程仓更新版本

1 个赞