Yocto自定义层检测报错：缺失bblayers.conf.backup及进程挂起

关于bblayers.conf.backup文件 #

• 这个文件不是Yocto默认自带的常规文件，它是yocto-check-layer脚本临时修改bblayers.conf时自动生成的备份。如果脚本中途被中断（比如你手动发送了中断信号），就会出现备份文件未生成或未正常清理的异常情况。
• 手动创建的话，直接把当前可用的/home/hal/build/conf/bblayers.conf内容完整复制一份，存为同目录下的bblayers.conf.backup即可，这样脚本就能识别到备份存在，不会报缺失错误。

解决yocto-check-layer挂起问题 #

结合你的WSL2 Ubuntu 18.04环境和现象，从以下方向排查：

1. 检查WSL2资源限制 #

从你提供的top结果重点留意：

• CPU占用：如果bitbake或python进程单核心跑满100%，可能是脚本处理依赖时陷入死循环；若整体CPU空闲，大概率是IO阻塞。
• 内存/swap：WSL2默认内存分配可能不足，导致进程卡顿。可以在Windows用户目录下新建/修改.wslconfig文件，添加以下配置：

  [wsl2]
  memory=8GB
  swap=4GB
  

  修改后执行wsl --shutdown重启WSL2再试。

2. 排查脚本执行卡壳点 #

从你的中断日志和源码片段来看，“Getting initial signatures”阶段是脚本调用bitbake -S none生成初始签名的过程，挂起通常和这些因素有关：

• 残留配置干扰：虽然你移除了meta-x，但如果之前加层时在local.conf中留下相关配置项，会打乱脚本执行。检查local.conf，删除所有和meta-x相关的内容。
• 版本不兼容：Ubuntu 18.04对较新的Yocto分支（如Scarthgap及以后）支持有限，要么切换到兼容的旧分支（如Dunfell），要么将Ubuntu升级到20.04及以上版本。
• 网络阻塞：如果脚本需要拉取远程依赖或签名数据，WSL2的代理配置错误会导致卡住。检查http_proxy/https_proxy环境变量是否正确，或尝试在无代理环境下运行脚本。

3. 手动分步验证定位问题 #

跳过yocto-check-layer，拆分步骤排查：

1. 单独运行bitbake -S none，观察是否挂起。如果挂起，直接排查bitbake问题：
   • 增加调试日志：bitbake -S none -D，查看输出停滞的具体步骤，针对性排查。
   • 检查权限：确保/home/hal/build下所有文件都属于当前用户，避免权限不足导致的阻塞。
2. 确认核心层完整性：检查bblayers.conf中核心层（如meta、meta-poky、meta-yocto-bsp）的路径是否正确，无文件缺失。

4. 重置构建环境 #

如果以上方法无效，尝试重置配置：

• 备份当前配置：cp -r build/conf build/conf.bak
• 重新生成配置：source poky/oe-init-build-env build，跟随提示生成新的bblayers.conf和local.conf
• 再次运行yocto-check-layer，之后逐步添加meta-x验证每一步的问题

内容的提问来源于stack exchange，提问作者hal