Buildroot 配置怎么备份？用 defconfig 在新目录重建 ARM64 系统

Buildroot 配置怎么备份？用 defconfig 在新目录重建 ARM64 系统

系统能启动，程序能调试，自定义应用也已经交给 Buildroot 自动编译和安装。接下来还有一个问题：如果不用原来的 output/，这些成果还能重新构建出来吗？

执行过 make clean 后，构建产物可以重新生成；但如果配置和自定义文件没有保存好，仅靠一份旧镜像并不能恢复开发环境。

这一篇，把当前配置保存成自己的 defconfig，放进已有的 BR2_EXTERNAL 目录，再用一个新的输出目录构建系统。最后启动新镜像，检查上篇《告别手动复制：在 Buildroot 中添加自己的 ARM64 软件包》中的 debug_demo 是否仍然可用。

实验验证： 本文沿用前三篇的实验环境，记录了保存后的 defconfig、新输出目录生成的镜像与 ARM64 程序检查结果，并在 QEMU 中启动新镜像，确认系统架构为 aarch64、debug_demo 输出 v2 结果且退出码为 0。文中未单独展示配置加载和完整构建命令的返回码；验证依据是生成的产物及其在 QEMU 中的实际运行结果。

一、这次要验证什么

本次不删除原来的构建结果，也不在原目录执行 make clean。我们要完成：

当前配置
-> 保存自己的 defconfig，并保留源码与自定义文件
-> 在新 O= 输出目录加载自定义 defconfig
-> 重新构建工具链、内核和 rootfs
-> 用新镜像启动 QEMU，运行 debug_demo

检查三个结果：

这里说的“复现”是重新构建出功能符合预期的系统，不承诺两次生成的镜像逐字节一致。

二、准备环境，先保护已有成果

默认在 Ubuntu 主机终端执行命令，文中的 Bash 命令不适用于 Windows PowerShell。只有明确标注“QEMU 目标端”的命令才在目标系统中执行。

前提是已经完成上篇：debug-demo 已启用，外部源码中的程序能通过 Buildroot 进入镜像。本文的输出示例沿用上篇最后的 v2 标记。

如果 QEMU 正在运行，先在目标端执行 poweroff。系统关机后，若 QEMU 未退出，再按 Ctrl+A，松开后按 X。

在 Ubuntu 主机备份原配置：

cd ~/buildroot-2025.02.8
cp -p .config ".config.before-defconfig.$(date +%Y%m%d-%H%M%S)"

确认外部包和源码仍在：

ls -l ~/buildroot-external-demo/external.desc
ls -l ~/buildroot-external-demo/package/debug-demo/debug-demo.mk
ls -l ~/buildroot-external-demo/src/debug-demo/debug_demo.c
grep '^BR2_PACKAGE_DEBUG_DEMO=' .config

预期最后一条命令输出 BR2_PACKAGE_DEBUG_DEMO=y。若文件缺失或包未启用，先按上篇的软件包步骤恢复，不要用默认配置覆盖当前配置。

后面的命令假设只使用这一个外部目录。如果已有其他 BR2_EXTERNAL 目录，应在每条显式传入该参数的命令中保留完整路径列表，不要只留下示例目录。

三、先分清配置和文件，各自都要保存

defconfig 不是把 .config 换个文件名。Buildroot 会根据当前版本的 Kconfig 默认值，保存恢复配置所需的非默认选择。

因此，有些已启用的默认选项可能不直接出现在 defconfig 中。判断配置是否保留，应加载后检查新的 .config，而不是要求每一个符号都出现在精简文件里。

defconfig 只保存配置选择，不会把配置引用的文件打包进去。 本系列至少要保留：

先在原 Buildroot 目录查看 overlay 设置：

cd ~/buildroot-2025.02.8
grep '^BR2_ROOTFS_OVERLAY=' .config

沿用前文时，它可能仍指向 /home/embed/buildroot-2025.02.8/rootfs-overlay。本篇只换输出目录，不移动源码树，因此这个路径可以保留。 确认目录仍在，且没有此前移走的旧 debug_demo 覆盖包产物即可；没有配置 overlay 的读者无需新增。

如果自行修改过内核或 BusyBox 配置，必须按对应组件的流程另行保存。仅执行 Buildroot 的 savedefconfig，不会自动保存这些组件在构建目录里的临时修改。

同样，不要让自定义配置依赖旧 output/build 或 output/host 下的临时产物。本系列使用内部工具链，新目录会重新构建它。

四、用 savedefconfig 保存当前配置

在外部目录中创建 configs/：

mkdir -p ~/buildroot-external-demo/configs

如果已有同名 arm64_demo_defconfig，先备份；下面的保存命令会覆盖它。

在原 Buildroot 目录执行：

cd ~/buildroot-2025.02.8
make BR2_EXTERNAL="$HOME/buildroot-external-demo" \\
BR2_DEFCONFIG="$HOME/buildroot-external-demo/configs/arm64_demo_defconfig" \\
savedefconfig
echo $?

echo $? 必须紧接着命令执行。返回 0 后，再检查：

ls -l ~/buildroot-external-demo/configs/arm64_demo_defconfig
cat ~/buildroot-external-demo/configs/arm64_demo_defconfig

这里特意指定 BR2_DEFCONFIG，明确告诉 Buildroot 把精简配置写到哪里。不要假定不带路径执行 make savedefconfig 一定写入当前目录的 defconfig，也不要误覆盖官方配置文件。

这个命令保存配置，不会生成新镜像。也不要为了保存配置重新执行官方的 qemu_aarch64_virt_defconfig，那会重新加载官方默认选择。 图示：查看已保存的 arm64_demo_defconfig，可见 ARM64、内核、rootfs overlay 和 debug-demo 等配置项。

五、在新的输出目录加载配置

先定义新输出目录，后续在同一个 Ubuntu 终端继续操作：

export DEMO_OUT="$HOME/buildroot-output-arm64-demo"
test ! -e "$DEMO_OUT"
echo $?

返回 0 表示该路径尚不存在，可以用于本次新构建。若返回非 0，不要删除它；请检查已有内容或换一个未使用的目录，并重新设置 DEMO_OUT。

从 Buildroot 源码目录加载外部 defconfig：

cd ~/buildroot-2025.02.8
make O="$DEMO_OUT" \\
BR2_EXTERNAL="$HOME/buildroot-external-demo" \\
arm64_demo_defconfig
echo $?

返回 0 后检查新配置：

ls -l "$DEMO_OUT/.config"
grep '^BR2_PACKAGE_DEBUG_DEMO=' "$DEMO_OUT/.config"
grep '^BR2_ROOTFS_OVERLAY=' "$DEMO_OUT/.config"

预期自定义包仍为 BR2_PACKAGE_DEBUG_DEMO=y，overlay 设置与保存前一致，引用的目录实际存在。

arm64_demo_defconfig 能被找到，是因为 Buildroot 会在已加载外部目录的 configs/ 下查找同名配置，不需要把它复制进官方 configs/。

O= 改变了哪些位置

后面的命令始终显式传入 O="$DEMO_OUT"，避免误操作旧构建。新开终端后要重新设置这个变量，不能让它为空。

六、重新构建，不复制旧 output

确认新配置正确后执行：

make O="$DEMO_OUT" \\
BR2_EXTERNAL="$HOME/buildroot-external-demo" -j2
echo $?

新输出目录没有旧工具链和构建缓存，所以会重新构建所需工具链、内核和软件包，耗时接近一次完整构建。预先检查 Ubuntu 虚拟机的可用磁盘空间和内存，不要按单包增量构建估算时间。

下载缓存与构建产物是两回事。本例没有另行指定下载目录时，Buildroot 默认使用源码目录下的 ~/buildroot-2025.02.8/dl/；新建 O= 输出目录仍可复用这里已有的源码压缩包。make clean 不会删除这个下载缓存。如果设置了 BR2_DL_DIR 环境变量，Buildroot 则使用该变量指定的下载目录。

复用 dl/ 只表示可能不必重新下载已经缓存的源码，不会复用旧输出目录中的工具链或编译结果；缺少的源码仍可能需要联网下载。下载缓存本身也占用磁盘空间，不能把“复用缓存”理解为“不需要额外磁盘空间”。

不要复制旧 output/host、output/build、output/target 或 output/images 来让实验“通过”。 本次验证的是配置和输入文件能否重新生成系统。

返回 0 后检查：

ls -lh "$DEMO_OUT/images/Image" "$DEMO_OUT/images/rootfs.ext2"
file "$DEMO_OUT/target/usr/bin/debug_demo"

主机端只检查文件，不直接执行这个 ARM64 程序。下面是本次新输出目录中的实际检查结果：

embed@embedtest:~/buildroot-2025.02.8$ ls -lh "$DEMO_OUT/images/Image" "$DEMO_OUT/images/rootfs.ext2"
-rw-r–r– 1 embed embed 12M Oct 15 20:36 /home/embed/buildroot-output-arm64-demo/images/Image
-rw-r–r– 1 embed embed 60M Oct 15 20:37 /home/embed/buildroot-output-arm64-demo/images/rootfs.ext2
embed@embedtest:~/buildroot-2025.02.8$ file "$DEMO_OUT/target/usr/bin/debug_demo"
/home/embed/buildroot-output-arm64-demo/target/usr/bin/debug_demo: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 6.12.0, stripped

ARM aarch64 确认程序面向 ARM64；stripped 表示目标文件中的调试符号已被剥除，不代表程序不能运行。镜像和内核大小会随配置变化，以上尺寸只是本次记录，不是固定要求。

七、启动新镜像，验证配置确实可用

确认没有仍在运行的 QEMU 占用同一个镜像或本机端口 5000，在 Ubuntu 主机执行：

/usr/bin/qemu-system-aarch64 \\
-M virt \\
-cpu cortex-a53 \\
-smp 2 \\
-m 1G \\
-nographic \\
-kernel "$DEMO_OUT/images/Image" \\
-append "rootwait root=/dev/vda console=ttyAMA0" \\
-drive file="$DEMO_OUT/images/rootfs.ext2",if=none,format=raw,id=hd0 \\
-device virtio-blk-device,drive=hd0 \\
-netdev user,id=net0,hostfwd=tcp:127.0.0.1:5000-:2345 \\
-device virtio-net-device,netdev=net0

这里使用的是新目录里的内核和 rootfs，不是旧 output/images/。不要同时挂载或让两个 QEMU 写入同一个镜像。

进入系统，以 root 登录后，在 QEMU 目标端执行：

uname -m
/usr/bin/debug_demo
echo $?

如果外部源码保留了 v2 输出标记，预期会看到对应的新版本文本；如果源码仍是首次版本，程序则输出 total = 100。判断标准是目标端输出与外部源码一致，不要把 v2 当成固定要求。

若 overlay 有需要验证的配置文件，还应检查它在目标端的对应路径与内容。程序能运行只能验证应用路径，不能证明 overlay 中的所有文件都正确。

本次 QEMU 目标端的实际运行记录如下。结合上面的启动命令（内核和 rootfs 均来自 $DEMO_OUT/images/），它证明新镜像启动了 ARM64 系统，debug_demo 输出了 v2 结果并以状态码 0 退出：

# uname -m
aarch64
# /usr/bin/debug_demo
debug-demo package v2: total = 100
# echo $?
0

这验证了应用在新镜像中的运行结果；若要证明 overlay 中的其他文件也已带入，还需逐项检查其目标端路径和内容。

八、后续修改仍要指定同一个 O=

后续若以新输出目录为主，打开菜单也必须指定同一个 O=：

cd ~/buildroot-2025.02.8
make O="$DEMO_OUT" \\
BR2_EXTERNAL="$HOME/buildroot-external-demo" menuconfig

保存后，这次修改的是 $DEMO_OUT/.config，不是源码根目录的旧 .config。

确认修改正确、备份已有 defconfig 后，再从这个新配置保存：

make O="$DEMO_OUT" \\
BR2_EXTERNAL="$HOME/buildroot-external-demo" \\
BR2_DEFCONFIG="$HOME/buildroot-external-demo/configs/arm64_demo_defconfig" \\
savedefconfig
echo $?

保存 defconfig 不会更新镜像；仍需对同一个输出目录执行完整 make。如果改变了架构、C 库或工具链等配置，应按 Buildroot 的重建要求使用干净构建，不能一概依赖增量构建。

修改应用源码时，仍按上篇的软件包步骤操作，并为命令加上新输出目录：

make O="$DEMO_OUT" \\
BR2_EXTERNAL="$HOME/buildroot-external-demo" debug-demo-rebuild V=1
echo $?

返回 0 后，再执行第六节的完整构建命令更新镜像。生成镜像前先关闭使用该镜像的 QEMU。

九、可选检查与后续整理

1. 配置回读比较

如果想进一步检查保存与加载是否一致，可以在第五节加载配置后、尚未做其他配置修改时，将新配置精简保存到临时文件：

cd ~/buildroot-2025.02.8
make O="$DEMO_OUT" \\
BR2_EXTERNAL="$HOME/buildroot-external-demo" \\
BR2_DEFCONFIG="$DEMO_OUT/roundtrip_defconfig" \\
savedefconfig
echo $?

确认返回 0 后比较：

diff -u \\
"$HOME/buildroot-external-demo/configs/arm64_demo_defconfig" \\
"$DEMO_OUT/roundtrip_defconfig"
echo $?

同一版本和输入下，预期没有差异，diff 返回 0。返回 1 表示内容不同，大于 1 通常表示读取文件等错误。先查原因，不要为了消除差异直接覆盖文件。

这是可选检查，不能替代构建和启动验证。

2. 将 overlay 集中到外部目录

当前流程不需要迁移 overlay。后续若要让自定义文件集中管理，可以将其复制到外部目录的 board/arm64-demo/rootfs-overlay/，确认内容后，在对应输出目录的 menuconfig 中修改 Root filesystem overlay directories 为：

$(BR2_EXTERNAL_ARM64_DEMO_PATH)/board/arm64-demo/rootfs-overlay

在菜单中原样输入，不加外层引号。若使用多个 overlay，应保留完整列表。复制前检查目的目录，避免覆盖或重复嵌套；原目录先保留，等新配置构建验证通过后再决定是否删除。

修改后重新保存 defconfig 并构建验证，不要只移动文件却不更新配置。

3. 换机器还需要什么

可以用版本控制管理自定义配置和源码，但不需要把 output/ 整体提交进去。使用本地源码的包尤其要保存实际源码版本，不能只记录包规则里的 VERSION = 1.0。

换机器时，还需记录 Buildroot 与主机工具版本、源码获取方式，检查 overlay 等路径是否仍然可用。本篇仅计划验证同一主机上的新输出目录重建，不代表完成跨机器、离线或逐字节可复现构建。

如果公开分享实验材料，只提供已检查的示例文件。不要打包整个工作目录；确认没有凭据、内部地址或无权公开的代码，并按各组件实际许可证处理分发义务。

十、遇到问题先检查这些

1. 提示找不到 arm64_demo_defconfig

检查外部目录是否已通过 BR2_EXTERNAL 加载，以及文件是否确实位于 configs/arm64_demo_defconfig。配置名与文件名必须一致。

2. 保存完了，修改却没有进入 defconfig

先检查保存时是否指定了正确的 O=。旧构建与新构建各有自己的 .config，操作其中一个不会自动同步另一个。

其次，默认项可能被精简掉，应加载后检查完整配置，而不是手动向 defconfig 塞入全部符号。

3. 新目录构建提示 overlay 或其他文件不存在

检查实际配置中的路径及文件。确认外部目录已加载、标识名仍为 ARM64_DEMO，且文件不再依赖旧 output/ 下的临时产物。

4. 为什么重新编译工具链，不能直接用旧的

新输出目录默认重新生成自己的构建产物，这是本次验证的一部分。可复用下载缓存，但不要把旧工具链目录直接复制过去。独立 SDK 或外部工具链的使用属于另一个工作流程。

5. make clean 和 make distclean 有什么区别

Buildroot 2025.02.8 中，clean 主要清理指定输出目录的构建产物，保留当前配置；distclean 还会删除配置等文件，并可能清理源码树共享的下载目录。使用 O= 不代表所有清理影响都仅限于该目录。

本篇不需要执行它们。尤其不要为了试验清理命令，破坏仍要保留的旧构建和下载缓存。

十一、小结

前三篇解决“系统能运行、程序能调试、应用能自动构建”。这一篇再把配置和输入文件整理出来：

不仅保存旧镜像
-> 保存配置、源码与自定义文件
-> 用新输出目录重新构建
-> 启动新镜像验证

记住三个动作：用 savedefconfig 保存选择，保留配置依赖的源码和文件，用新 O= 目录构建并启动验证。 只生成一个 defconfig 文件，还不算完成恢复验证。

下一篇可以继续让应用随系统启动，把“登录后手动运行”变成“开机自动执行”。

参考资料

• Buildroot 官方手册：配置保存、外部目录、独立输出目录与项目定制。在线手册随版本更新，应同时对照 2025.02.8 源码中的 docs/manual/。
• Buildroot 2025.02.8 顶层 Makefile：savedefconfig、BR2_DEFCONFIG、O=、外部配置查找以及清理目标的实现。