Buildroot 定制根文件系统：从 minimal 到生产级

嵌入式 Linux 产品的核心竞争力往往不在于内核本身，而在于其承载的用户空间组件：文件系统布局、包选型、init 策略和安全加固。Buildroot 作为轻量级构建系统，能从源码交叉编译出最小化的根文件系统镜像，但实际项目中很少停留在 make qemu_arm_vexpress_defconfig 的默认状态。本文讨论如何在 Buildroot 框架内，将一个 minimal 根文件系统逐步演进为满足量产要求的生产级镜像。

一、问题背景

Buildroot 的 defconfig 提供了一条快速跑通的路径，但默认配置往往缺少量产所需的要素：文件系统只读挂载、安全补丁管理、OTA 升级支持、调试接口关闭等。直接基于默认输出构建的产品，会在后期面临大量返工。讨论范围限定在 Buildroot 2024.02 LTS 之后的版本，目标平台为 ARM Cortex-A 系列 SoC，文件系统类型为 squashfs + overlay。

二、核心思路

• 分层管理：将 rootfs 划分为只读基础层（squashfs）和可写覆盖层（overlayfs），降低写磨损风险并简化 OTA 更新。
• 最小化原则：默认 defconfig 包含大量开发用工具（strace、gdb、gcc），生产镜像应剥离，仅保留运行时必要的库和守护进程。
• config fragments：使用 Buildroot 的 BR2_PACKAGE_OVERRIDE_DIR 和 .config fragment 机制，将平台无关配置与板级定制分离，便于版本管理和跨产品复用。
• ** reproducibility**：锁定交叉编译工具链版本、内核头文件版本和每个包的哈希值，确保同一 commit 在不同时间构建出相同产物。

三、落地步骤

1. 生成基础 defconfig

make <your_board>_defconfig

2. 剥离开发工具

在 menuconfig 中取消以下包：

BR2_PACKAGE_STRACE=n
BR2_PACKAGE_GDB=n
BR2_PACKAGE_GCC=n
BR2_PACKAGE_GCC_INITIAL=n
BR2_PACKAGE_GCC_FINAL=n

3. 启用只读根文件系统

BR2_TARGET_ROOTFS_SQUASHFS=y
BR2_TARGET_ROOTFS_SQUASHFS4_BLOCKSIZE=256
BR2_ROOTFS_OVERLAY="board/your_board/rootfs_overlay"
BR2_ROOTFS_POST_SCRIPT="board/your_board/post_build.sh"

4. 添加 config fragment

在 board/your_board/ 下创建 buildroot.config.fragment：

BR2_PACKAGE_BUSYBOX_CONFIG="board/your_board/busybox.config"
BR2_INIT_SYSTEMD=y
BR2_PACKAGE_SYSTEMD=y
BR2_PACKAGE_JOURNALD=y

构建时使用：

make BR2_EXTERNAL=<path_to_your_external_tree> all

5. 锁定版本

在 external.mk 中指定每个关键包的版本和哈希：

LINUX_VERSION = 6.6.36
LINUX_SITE = kernel.org/pub/linux/kernel/v6.x
LINUX_HASH = sha256 abcdef123456...

6. 后处理脚本

在 post_build.sh 中完成镜像发布前的清理：

#!/bin/bash
# 移除调试符号
find "$TARGET_DIR" -name "*.debug" -delete
# 移除文档
rm -rf "$TARGET_DIR/usr/share/doc"
# 设置关键目录权限
chmod 700 "$TARGET_DIR/etc/shadow"

四、常见坑

• overlayfs 与 systemd 冲突：systemd 默认尝试挂载 /run 和 /tmp，在只读根文件系统下可能失败。需要在 fstab 中显式配置 tmpfs 挂载点。
• squashfs 块大小选择：块越大压缩率越高，但随机读性能越差。对于流媒体类产品建议 256KB，频繁读写的场景建议 128KB。
• BR2_ROOTFS_OVERLAY 顺序：多个 overlay 目录时，后列出的会覆盖先列出的，导致文件丢失。务必确认顺序符合预期。
• 版本锁定导致的依赖问题：锁定包版本后，手动更新某个包可能破坏依赖关系。建议定期运行 make legal-info 检查许可证合规性和依赖完整性。
• 交叉编译工具链与主机差异：使用 Buildroot 内置工具链时，主机系统更新可能影响编译。生产环境建议使用独立的交叉编译工具链。

五、检查清单

• defconfig 已基于板级配置，非通用默认
• 开发工具（strace、gdb、gcc）已在生产配置中移除
• rootfs 为 squashfs 只读 + overlay 可写方案
• post_build.sh 已执行清理和权限设置
• 关键包版本和哈希已锁定
• config fragments 已与平台无关配置分离
• systemd 服务在只读根文件系统下可正常启动
• make legal-info 无异常
• 构建产物大小在目标 Flash 容量范围内
• OTA 升级脚本已验证回滚能力

六、小结

Buildroot 的价值不在于它能跑通多少 defconfig，而在于它提供了一套可版本化、可审计的构建管线。从 minimal 到生产级的演进，本质上是将隐式的默认行为转化为显式的配置决策。每个决策都应有对应的 rationale 和验证手段，这比任何单点优化都更重要。