Buildroot实战：fsoverlay与rootfs.ext2挂载，嵌入式Linux文件集成双方案详解

1. 项目概述与核心价值

在嵌入式Linux开发这条路上，相信很多朋友都经历过这样的场景：好不容易把内核、驱动调通，系统镜像也烧录到了开发板上，结果发现自己的应用程序、配置文件或者动态库还没放进去。于是，又得拿起串口线或者网线，用scp、adb或者U盘，手动把这些文件一个个拷贝到开发板的文件系统里。一次两次还行，但每次修改代码、调试、重新编译镜像后都要重复这个操作，不仅繁琐低效，更致命的是破坏了开发流程的完整性和可重复性。你今天手动拷贝的文件，可能明天就因为忘了而丢失，导致系统行为不一致，给后期维护和批量生产埋下大坑。

今天，我们就以飞凌嵌入式的OK3562开发板（搭载Linux 5.10.198内核）为例，深入聊聊如何利用Buildroot这个强大的构建工具，从根本上解决这个问题。Buildroot不仅仅是生成一个根文件系统（rootfs），它更是一套完整的自动化构建框架。其核心价值在于，它允许我们将产品所需的一切——从第三方库、自定义服务到简单的脚本和配置文件——都“编码”到构建系统中。这样，最终生成的update.img镜像就是一个开箱即用、功能完整的成品，无需任何后期手动干预。这对于需要固件OTA升级、工厂批量烧录或者追求部署一致性的项目来说，是至关重要的工程实践。

本文将详细解析两种将用户文件集成到Buildroot镜像的主流方法：一种是“一劳永逸”的源码集成法（使用fsoverlay），另一种是“灵活快捷”的镜像修改法（挂载rootfs.ext2）。我会结合在OK3562平台上的实际操作，不仅告诉你步骤，更会剖析每种方法背后的原理、适用场景，以及我踩过的那些“坑”。无论你是刚接触Buildroot的新手，还是希望优化现有工作流的老鸟，这篇文章都能给你提供可直接复现的解决方案和深度思考。

2. 环境准备与Buildroot工作流解析

在开始动手之前，我们必须先理清OK3562 SDK中Buildroot的目录结构和基本工作流。这不是枯燥的理论，而是理解后续所有操作的基础。飞凌官方提供的OK3562-linux-source源码包，其构建系统是高度定制化的，理解它才能避免“盲人摸象”。

2.1 OK3562 SDK目录结构解读

通常，解压官方SDK后，你会看到一个类似OK3562-linux-source的目录。其关键子目录如下：

OK3562-linux-source/ ├── build.sh # 核心构建脚本，封装了所有编译命令 ├── buildroot/ # Buildroot主目录 │ ├── board/ │ │ └── forlinx/ # 飞凌针对不同板子的配置目录 │ │ └── ok3562/ # OK3562专属配置 │ │ ├── fsoverlay/ # **关键目录**：文件系统覆盖层 │ │ ├── linux-5.10.198.config # 内核配置 │ │ └── post-build.sh # 镜像生成后脚本 │ ├── configs/ │ │ └── ok3562_defconfig # Buildroot系统级配置 │ ├── output/ # **编译输出目录**（编译后生成） │ │ └── OK3562_Linux/ │ │ ├── build/ # 所有软件包的构建目录 │ │ ├── host/ # 主机工具（交叉编译器等） │ │ ├── images/ # **最终生成的镜像目录** │ │ │ ├── rootfs.ext2 # 原始根文件系统镜像 │ │ │ └── update.img # 最终可烧录镜像 │ │ └── target/ # **目标系统的根文件系统**（近似于开发板上的/） │ └── ... (其他Buildroot标准目录) └── kernel/ # Linux内核源码

核心理解：

• buildroot/board/forlinx/ok3562/fsoverlay/：这是我们的“手术室”。你在这里放置的任何文件和目录结构，都会在编译时自动覆盖（合并）到最终的target/根文件系统中。这是方法一的舞台。
• buildroot/output/OK3562_Linux/images/rootfs.ext2：这是编译后生成的、尚未打包成update.img的原始EXT2格式根文件系统镜像。我们可以像挂载U盘一样挂载它，直接往里增删文件。这是方法二的舞台。
• buildroot/output/OK3562_Linux/target/：这是fsoverlay与Buildroot构建的所有软件包合并后的结果，可以把它看作rootfs.ext2解压后的内容。有时清理缓存需要手动处理这里。

2.2 Buildroot构建流程简析

当我们执行./build.sh all时，背后发生了一系列标准化操作：

1. 配置加载：读取ok3562_defconfig，确定要编译的架构（aarch64）、工具链、基础软件包列表。
2. 下载与解压：根据配置，下载所有选中的软件包源码（如果本地dl目录没有缓存）。
3. 打补丁与配置：对源码应用补丁，并运行各软件包自身的配置脚本（如configure,cmake）。
4. 编译与安装：交叉编译所有软件包，并将编译好的目标文件（二进制、库、配置文件）安装到output/OK3562_Linux/target/目录下。注意，此时安装的是“目标文件”，即最终要放到开发板上的东西。
5. 应用Overlay：这是关键一步。Buildroot会将board/forlinx/ok3562/fsoverlay/目录下的所有内容，递归地复制到target/目录中。如果存在同名文件，fsoverlay下的文件会覆盖target中已安装的文件。
6. 生成根文件系统镜像：将整理好的target/目录内容，打包成rootfs.ext2（或其他格式）镜像文件。
7. 生成最终镜像：将内核镜像（Image）、设备树（.dtb）和rootfs.ext2等打包成飞凌定制格式的update.img。

重要心得：理解fsoverlay是在“安装阶段”之后才被复制这一点至关重要。这意味着，如果你通过fsoverlay放置了一个文件，它不会影响任何软件包的编译过程，它只是静静地躺在最终的文件系统里。如果你想修改某个软件包（如BusyBox）本身的配置文件，应该通过Buildroot的配置系统（make menuconfig）或自定义包（package/目录）来实现，而不是直接覆盖。

3. 方法一详解：通过fsoverlay永久集成文件

这种方法是将用户文件深度集成到构建系统内部，实现“一次配置，终身受益”。所有操作都在源码目录中进行，与Buildroot构建流程完美融合。

3.1 fsoverlay机制深度解析

你可以把fsoverlay（文件系统覆盖层）想象成一张透明的硫酸纸，覆盖在已经画好底稿（即Buildroot构建的基础根文件系统）的画布上。你在硫酸纸上添加的任何笔画（文件），都会成为最终画面的一部分。其核心优势在于：

• 版本化管理：所有自定义文件与源码一同受Git等版本控制工具管理，变更历史清晰可追溯。
• 可重复构建：在任何一台配置好环境的机器上，执行完整的构建命令，都能得到一模一样的镜像，这是持续集成（CI）的基础。
• 永久有效：只要fsoverlay目录下的文件存在，后续任何针对内核、驱动的修改和重新编译，都会自动包含这些文件。

3.2 标准操作流程与示例

假设我们要集成一个自定义的可执行程序my_app、其配置文件my_app.conf和一个必要的动态库libmydata.so。

步骤1：规划与放置文件按照Linux文件系统层次结构标准（FHS），合理放置文件：

1. 在fsoverlay目录下创建目标路径。这完全模拟开发板上的根目录（/）。

   cd /path/to/OK3562-linux-source/buildroot/board/forlinx/ok3562/fsoverlay/

2. 放置可执行程序到/usr/bin（系统通用用户命令）或/usr/local/bin（本地安装软件）。通常选择/usr/bin。

   sudo cp ~/projects/my_app ./usr/bin/ sudo chmod +x ./usr/bin/my_app # 确保有执行权限

3. 放置配置文件到/etc，这是存放系统软件配置的标准位置。

   sudo cp ~/projects/my_app.conf ./etc/

4. 放置动态库到/lib（32位）或/lib64（64位）。对于OK3562（AArch64），应放在./lib64/下。但注意，Buildroot的target目录下可能链接了lib到lib64，为保险起见，可以同时检查。

   sudo cp ~/projects/libmydata.so ./lib64/

5. （可选）创建专属目录。例如，为你的应用创建数据目录。

   sudo mkdir -p ./opt/my_company/my_app/data

步骤2：执行完整编译回到SDK根目录，执行完整构建命令。这个过程会重新编译所有内容，耗时较长（取决于电脑性能）。

cd /path/to/OK3562-linux-source ./build.sh all

编译成功后，你可以在以下位置验证：

• buildroot/output/OK3562_Linux/target/usr/bin/my_app- 检查文件是否存在。
• buildroot/output/OK3562_Linux/images/rootfs.ext2- 可以通过挂载（见方法二）来检查内部文件。

步骤3：生成与烧录镜像编译完成后，直接生成最终烧录镜像：

./build.sh updateimg

生成的update.img位于buildroot/output/OK3562_Linux/images/目录下。使用飞凌提供的烧录工具（如RKDevTool）将其烧录到OK3562开发板。

步骤4：开发板验证开发板上电启动，进入系统后：

# 检查文件是否存在 ls -l /usr/bin/my_app ls -l /etc/my_app.conf ls -l /lib64/libmydata.so # 检查动态库依赖（确保所有依赖都满足） ldd /usr/bin/my_app # 尝试运行你的程序 my_app --help

3.3 高级技巧与避坑指南

1. 文件权限与所有权：

   • Buildroot在打包时，会为fsoverlay中的文件赋予默认的所有者和权限。如果你需要特定的权限（如setuid位）或用户/组（如root:root），需要在fsoverlay中提前设置好。可以使用sudo chown root:root ./usr/bin/my_app和sudo chmod 4755 ./usr/bin/my_app（设置SUID）来修改。
   • 常见坑：从Windows环境复制到Linux下的文件，可能丢失可执行权限，导致程序无法运行。务必在放置后chmod +x。

2. 处理目录与符号链接：

   • fsoverlay支持完整的目录结构。如果你有一个复杂的应用目录（如/opt/myapp/{bin, lib, config, logs}），可以直接在fsoverlay/opt/myapp/下创建相同的结构。
   • 如果需要创建符号链接（例如，将/usr/bin/python链接到/usr/bin/python3），直接在fsoverlay中创建即可。ln -sf ../lib64/libmydata.so ./usr/lib/libmydata.so

3. 彻底清理与删除文件：

   • 仅仅从fsoverlay目录中删除文件是不够的。因为Buildroot的output/target目录有缓存机制。必须执行以下操作：

     # 1. 从fsoverlay中删除文件 rm -rf /path/to/fsoverlay/usr/bin/my_app # 2. 清理output/target中的残留文件（关键！） rm -rf /path/to/output/OK3562_Linux/target/usr/bin/my_app # 3. 重新编译 ./build.sh all

   • 更彻底的清理是删除整个output目录并重新编译（./build.sh cleanall），但耗时极长。推荐上述针对性删除。

4. 与Buildroot包系统的协作：

   • fsoverlay是最后生效的。如果你通过Buildroot的make menuconfig也安装了一个软件包（如openssh），它会在target中生成配置文件（/etc/ssh/sshd_config）。此时，如果你在fsoverlay/etc/ssh/sshd_config放置了同名文件，你的文件会覆盖包系统生成的文件。这可以用来定制默认配置。
   • 注意：覆盖系统关键文件（如/etc/passwd,/etc/inittab）需极其谨慎，可能导致系统无法启动。

4. 方法二详解：挂载rootfs.ext2临时修改镜像

这种方法直接操作已编译好的根文件系统镜像文件，适合快速迭代、临时测试，或者在不具备完整编译环境（如仅拿到一个rootfs.ext2镜像）的情况下进行修改。

4.1 方法原理与适用场景

rootfs.ext2是一个标准的EXT2/3/4文件系统镜像，就像一张虚拟的硬盘。在Linux下，我们可以使用mount命令将其挂载到一个临时目录（如/mnt/rootfs），然后像操作普通目录一样，向其内部添加、删除或修改文件。操作完成后卸载，修改就被“写回”到了镜像文件中。

最佳适用场景：

• 快速调试：编译一个完整的镜像需要30分钟以上，而你只是需要往/etc里加一个小配置文件，或者替换一个调试版本的可执行文件。
• 镜像微调：从同事或供应商那里拿到了一个现成的rootfs.ext2，需要根据当前项目进行少量定制。
• 空间不足应急：发现镜像空间不足，需要紧急扩容（后面会详细讲）。
• 逆向分析：查看一个现成镜像里包含了哪些文件和配置。

重要局限：

• 临时性：修改仅针对当前这个rootfs.ext2文件。如果后续执行了./build.sh all，基于源码重新生成的rootfs.ext2会覆盖你的所有修改。
• 不纳入版本管理：修改是直接对二进制镜像的操作，无法像fsoverlay那样通过代码diff来追踪变化。

4.2 完整操作步骤实录

假设我们已经有一个编译好的rootfs.ext2，现在需要向其中添加一个大型的数据文件dataset.tar.gz。

步骤1：创建挂载点并挂载镜像首先，需要一个空目录作为挂载点，并确保你有足够的权限。

cd /path/to/OK3562-linux-source/buildroot/output/OK3562_Linux/images/ # 创建挂载点目录 sudo mkdir -p /mnt/ok3562_rootfs # 挂载rootfs.ext2镜像到该目录 # -o loop 选项表示将文件作为回环设备挂载 sudo mount -o loop rootfs.ext2 /mnt/ok3562_rootfs

挂载成功后，你可以通过df -h查看挂载信息，并通过ls /mnt/ok3562_rootfs浏览开发板的整个根文件系统。

步骤2：像操作普通目录一样修改内容现在，/mnt/ok3562_rootfs就是开发板根目录的映射。

# 进入挂载点 cd /mnt/ok3562_rootfs # 添加文件。注意保持合理的目录结构。 sudo cp ~/large_files/dataset.tar.gz ./opt/data/ # 修改配置文件（例如，修改网络配置） sudo vim ./etc/network/interfaces # 或者使用echo追加 # sudo echo "auto eth0" >> ./etc/network/interfaces # 删除不需要的文件（谨慎！） # sudo rm ./home/root/obsolete_script.sh # 修改文件权限和所有者 sudo chown root:root ./opt/data/dataset.tar.gz sudo chmod 644 ./opt/data/dataset.tar.gz

步骤3：卸载镜像并同步更改所有修改完成后，必须正确卸载，才能保证所有数据写入镜像文件。

# 返回到镜像所在目录 cd /path/to/OK3562-linux-source/buildroot/output/OK3562_Linux/images/ # 卸载镜像 sudo umount /mnt/ok3562_rootfs

umount命令执行成功后，你对/mnt/ok3562_rootfs所做的所有修改，就已经被安全地写回到rootfs.ext2文件中了。

步骤4：重新打包并烧录修改了rootfs.ext2后，需要用它重新生成可烧录的update.img。

# 回到SDK根目录 cd /path/to/OK3562-linux-source # 使用修改后的rootfs.ext2重新打包update.img # 注意：此命令通常只重新打包镜像，不会重新编译内核和uboot，速度很快。 ./build.sh updateimg

之后，烧录新生成的update.img即可。

4.3 核心难题：镜像空间不足的扩容解决方案

这是使用挂载法时最常遇到的错误：cp: cannot create regular file '...': No space left on device。因为Buildroot在编译时给rootfs.ext2分配了一个固定大小（比如1.7GB）。当你要添加的文件超过剩余空间时，操作就会失败。

解决方案不是盲目扩容，而是按需扩容。以下是详细步骤：

步骤1：检查镜像当前大小和使用情况

cd /path/to/OK3562-linux-source/buildroot/output/OK3562_Linux/images/ # 查看镜像文件大小 ls -lh rootfs.ext2 # 挂载镜像，查看实际使用量 sudo mount -o loop rootfs.ext2 /mnt/ok3562_rootfs df -h /mnt/ok3562_rootfs sudo umount /mnt/ok3562_rootfs

记录下df命令显示的Used和Available空间。

步骤2：计算并执行扩容（必须在未挂载状态下进行）假设我们需要将镜像扩容到2.5GB。我们通过增加文件系统的大小（块数）来实现。

# 1. 首先，检查并修复文件系统（e2fsck） sudo e2fsck -f rootfs.ext2 # -f 选项强制检查，即使文件系统看起来是干净的。 # 2. 调整文件系统大小（resize2fs） # 假设我们想扩容到2500MB。先计算需要的块数（4K/block）: 2500*1024/4 = 640000 blocks # 但更安全的方法是直接指定增加的大小。例如，增加1GB： sudo resize2fs rootfs.ext2 2500M # 或者使用更直观的方式，直接扩大到指定大小 # sudo resize2fs rootfs.ext2 2.5G # 3. 再次检查文件系统 sudo e2fsck -f rootfs.ext2

resize2fs命令会直接扩展文件系统到指定大小。如果镜像文件（rootfs.ext2这个容器）本身不够大，还需要用dd或truncate命令来扩展容器，但Buildroot生成的rootfs.ext2通常预留了稀疏空间，resize2fs可以直接利用。

步骤3：验证与后续操作扩容完成后，重新挂载镜像，你就可以自由地复制大文件进去了。

sudo mount -o loop rootfs.ext2 /mnt/ok3562_rootfs cp ~/large_file.bin /mnt/ok3562_rootfs/home/root/ df -h /mnt/ok3562_rootfs # 查看空间变化 sudo umount /mnt/ok3562_rootfs

关键注意事项：

• 顺序绝对不能错：一定是先umount，再e2fsck和resize2fs，最后再mount。对已挂载的文件系统进行resize2fs是危险操作。
• 不是无限扩容：物理存储介质（开发板eMMC）的大小是上限。OK3562通常有8GB或16GB eMMC，但分配给根文件系统的分区大小在设备树中定义。镜像文件大小超过分区大小会导致烧录失败或启动失败。一般镜像大小控制在分区大小的80%以内比较安全。
• 预留空间：建议日常保持根文件系统至少有15-20%的剩余空间，以保证系统正常运行和日志写入。

5. 两种方法对比与选型策略

经过上面的详细拆解，我们来从多个维度系统对比一下这两种方法，这能帮助你在实际项目中做出最合适的选择。

特性维度	方法一：fsoverlay (源码集成)	方法二：挂载rootfs.ext2 (镜像修改)
集成阶段	编译时。文件在构建过程中被集成。	编译后。对已生成的镜像文件进行修改。
修改持久性	永久。修改保存在源码树中，重新编译自动包含。	临时。仅针对当前镜像文件，重新编译后丢失。
版本控制	天然支持。所有自定义文件可作为源码一部分进行Git管理。	不支持。修改的是二进制文件，难以跟踪差异。
操作复杂度	中。需要理解Buildroot目录结构，但步骤标准化。	低。类似操作U盘，直观简单。
所需时间	长。需要触发完整或部分重新编译，耗时数十分钟。	极短。仅挂载、拷贝、卸载，几分钟完成。
自动化能力	高。可轻松融入CI/CD流水线，实现全自动构建。	低。通常为手动操作，难以自动化。
风险性	低。遵循构建系统规则，不易破坏系统一致性。	中。直接操作镜像，误删系统文件风险高。
典型应用场景	1. 产品固件开发 2. 需要版本管理的配置 3. 团队协作项目 4. 工厂量产烧录	1. 快速调试与测试 2. 紧急修复或打补丁 3. 分析现有镜像内容 4. 镜像空间不足应急扩容

选型决策指南：

1. 追求“一次构建，处处运行”的工业化流程，请坚定不移地选择方法一（fsoverlay）。这是嵌入式Linux开发的最佳实践。它将所有依赖固化在构建过程中，确保了从开发、测试到生产环境的一致性。任何通过方法二能做的事情，都应该思考是否能转化为方法一的配置。

2. 在以下情况，方法二（挂载修改）是更好的选择：

   • 探索与学习：当你刚拿到一个板子，想快速看看它的文件系统里有什么，或者尝试某个配置是否有效。
   • 调试与验证：在漫长的编译等待中，你需要快速验证一个猜想（比如某个库文件是否缺失）。挂载修改可以立刻验证，节省大量时间。
   • 处理第三方镜像：你拿到了一个供应商提供的封闭镜像（只有rootfs.ext2），需要做一些客制化。
   • 紧急扩容：这是方法二最具不可替代性的场景。当镜像因空间不足无法添加文件时，挂载扩容是最直接的解决办法。

3. 混合使用策略：在实际项目中，我通常采用“方法一为主，方法二为辅”的策略。

   • 所有正式的、需要纳入版本管理的应用程序、配置和资源文件，都通过fsoverlay集成。
   • 在开发调试阶段，如果需要频繁修改某个大型数据文件（比如一个几百MB的AI模型），为了节省编译时间，可以先用方法二挂载更新。但一旦调试稳定，必须立即将最终版文件放入fsoverlay，并执行一次完整编译，以确保流程的完整性。
   • 将扩容操作作为标准流程的一部分。在项目初期，就通过修改Buildroot配置（BR2_TARGET_ROOTFS_EXT2_SIZE），将rootfs.ext2的默认大小设置得充裕一些，避免后期频繁扩容。

6. 实战进阶：常见问题排查与深度优化

掌握了基本方法，我们来看看那些容易踩坑的地方和更高阶的玩法。

6.1 问题排查清单

问题1：通过fsoverlay添加的文件，在开发板上找不到。

• 检查点1：编译是否成功。确认./build.sh all命令执行到最后没有报错，并且生成了新的update.img。
• 检查点2：文件路径是否正确。确认你在fsoverlay中放置文件的路径，与开发板上期望的路径完全一致。区分/usr/bin和/usr/local/bin。
• 检查点3：target目录缓存。尝试手动删除output/OK3562_Linux/target下对应的文件，然后重新编译。这是最常见的原因。
• 检查点4：文件权限。通过ls -l检查target目录下的文件是否有正确的可执行权限（对于二进制文件）。

问题2：添加的自定义程序无法运行，提示“Not found”或“Permission denied”。

• “Not found”：通常是因为动态链接器找不到依赖的库。使用交叉编译工具链的readelf或ldd命令在主机上检查程序的依赖。

  # 在主机上，使用SDK中的交叉工具链 /path/to/OK3562-linux-source/buildroot/output/OK3562_Linux/host/bin/aarch64-linux-readelf -d your_app | grep NEEDED

  确保所有列出的libxxx.so都存在于fsoverlay/lib64/或Buildroot已编译的库中。对于C++程序，特别注意libstdc++.so。
• “Permission denied”：检查文件权限。确保在fsoverlay中或挂载修改后，使用chmod +x赋予了执行权限。

问题3：系统启动失败，卡在某个阶段。

• 如果修改了fsoverlay：检查是否覆盖了关键系统文件，如/etc/inittab,/etc/fstab,/etc/profile。建议先备份原文件，再放置自定义文件进行对比。
• 如果操作了rootfs.ext2：检查是否误删了系统关键目录或文件，如/lib,/sbin/init。尝试用原始的rootfs.ext2备份恢复。
• 查看内核启动日志：通过串口查看启动信息，卡住的地方通常会有错误输出。

问题4：挂载rootfs.ext2时，提示“wrong fs type, bad option, bad superblock”。

• 镜像文件可能已损坏。尝试重新编译一个干净的镜像。
• 确保使用的是-o loop选项挂载EXT2/3/4文件系统。

6.2 高级技巧：自动化与集成

1. 使用脚本管理fsoverlay：对于文件较多的项目，可以在fsoverlay目录外维护一个独立的files/目录，然后编写一个部署脚本（如deploy_overlay.sh），用rsync或cp -r同步到fsoverlay中。这样便于独立管理应用文件。

   #!/bin/bash OVERLAY_DIR="board/forlinx/ok3562/fsoverlay" SRC_DIR="my_app_files/" rsync -av --delete $SRC_DIR/ $OVERLAY_DIR/ echo "Files synced to overlay."

2. 在fsoverlay中运行自定义脚本：Buildroot支持在构建的不同阶段运行脚本。你可以在fsoverlay中放置一个脚本（如my_post_install.sh），然后在board/forlinx/ok3562/post-build.sh中调用它。这样可以实现更复杂的安装后配置，比如动态生成配置文件、创建数据库等。

   # 在post-build.sh末尾添加 if [ -f "${TARGET_DIR}/my_post_install.sh" ]; then chmod +x "${TARGET_DIR}/my_post_install.sh" /bin/sh "${TARGET_DIR}/my_post_install.sh" rm -f "${TARGET_DIR}/my_post_install.sh" # 执行后删除 fi

3. 处理设备节点和特殊文件：fsoverlay中无法直接创建设备节点（如/dev/ttyS1）。这些节点通常在系统启动时由udev或mdev动态创建。如果你的应用依赖特定的设备节点，应该通过修改/etc/udev/rules.d/下的规则文件来实现，而不是在fsoverlay中放置一个静态节点。

4. 优化镜像大小：频繁添加文件可能导致镜像膨胀。可以：

   • 在Buildroot配置中(make menuconfig)移除不需要的软件包。
   • 使用strip命令剥离二进制文件的调试符号。
   • 对于rootfs.ext2，在打包前可以使用e2fsck -f -y和resize2fs -M尝试缩小镜像（但需谨慎，确保留有足够空间）。

两种方法，一个目标，就是让嵌入式系统的构建和部署变得可控、高效。从初期的快速验证到最终的量产固化，理解并熟练运用fsoverlay和rootfs.ext2挂载，就如同掌握了嵌入式Linux系统定制的两把钥匙。坚持将一切变更代码化、版本化（偏向方法一），同时在调试中灵活运用快捷手段（方法二），这之间的平衡与取舍，正是嵌入式工程师日常工作的艺术所在。希望这篇结合了原理、步骤和实战经验的长文，能帮你更从容地应对OK3562乃至其他嵌入式平台上的系统定制工作。