基于meta-intel层构建自定义镜像时修改启动命令行及超时问题

我之前在基于meta-intel构建Minnowboard Turbot的自定义镜像时，也碰到过一模一样的问题——明明设置了SYSTEMD_BOOT_TIMEOUT := "0"，但启动超时还是没变化。折腾了一阵后，终于找到几个关键的解决点，分享给你：

• 确保变量设置在正确的位置
  不要随便在临时文件里设置这个变量，一定要在BitBake能正确读取的配置中：

  • 若要全局生效，在build/conf/local.conf里添加：

    SYSTEMD_BOOT_TIMEOUT := "0"
    

  • 若只想让设置作用于特定镜像，就在对应镜像的recipe（比如recipes-core/images/your-custom-image.bb）里添加：

    inherit systemd-boot
    SYSTEMD_BOOT_TIMEOUT := "0"
    

  这里用:=（立即赋值）是为了避免后续其他配置覆盖这个值。

• 验证变量是否真的生效
  有时候看起来设置了变量，但实际BitBake构建时并没有用上。可以用这个命令查看最终生效的变量值：

  bitbake -e your-custom-image | grep SYSTEMD_BOOT_TIMEOUT
  

  如果输出的不是"0"，说明你的设置被其他层或recipe覆盖了，需要调整配置优先级（比如把设置移到镜像recipe里，因为recipe的优先级高于local.conf）。

• 检查生成的systemd-boot配置文件
  构建完镜像后，挂载镜像的ESP分区（EFI系统分区），找到loader/loader.conf文件，查看里面的timeout字段。如果依然不是0，说明systemd-boot的配置生成脚本没接收到你的变量。这时候可以手动修改这个文件后重新打包镜像；或者检查meta-intel/recipes-bsp/systemd-boot/下的bbclass文件，确认SYSTEMD_BOOT_TIMEOUT是否被正确传递到配置模板中。

• 适配rmc-boot的特殊逻辑
  因为meta-intel用rmc-boot作为EFI_PROVIDER，需要确保rmc-boot的构建过程也继承了这个超时设置。可以检查meta-intel/recipes-bsp/rmc-boot/rmc-boot.inc，看看是否需要把SYSTEMD_BOOT_TIMEOUT作为参数传递给rmc-boot的构建脚本。如果里面有相关变量引用，确保你的设置能传递过去。

我当时的问题是local.conf里的设置被镜像recipe的默认配置覆盖了，改成在镜像recipe里用立即赋值后，问题就解决了。你可以按照上面的步骤逐一排查，应该能搞定启动超时的问题！

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