工控单板Linux定制：eMMC分区、A/B OTA升级与OverlayFS恢复出厂

搞工控单板的朋友应该都有这种体会：同样是跑Linux，x86服务器和嵌入式单板完全是两个物种。服务器上你随便挂载、扩容、重装，出了岔子大不了重启回滚；到了工控单板上，eMMC寿命、分区布局、升级掉电、文件系统只读这些坑一个接一个，稍不注意就是返厂。最近在给一款基于Rockchip方案的工控板做量产前的系统定制，正好把存储配置、OTA升级和OverlayFS恢复出厂这套链路完整走了一遍，这里把过程和踩过的坑整理出来，给后面接手的人省点时间。

这篇指南面向的读者有两类：一类是刚接触单板Linux、对存储分区和文件系统还不太熟的开发或运维，另一类是把工控板当小服务器用、想自己定制升级和恢复机制的老手。文章不绕弯子，直接讲存储布局怎么规划、升级固件怎么刷、OverlayFS怎么用来实现“一键恢复出厂”，以及我在实际调试中遇到的几个诡异问题和解决思路。

1. 工控单板的存储觉悟：eMMC不是硬盘，分区不是随便分的

1.1 先认清存储介质的天性差异

工控单板上最常见的存储介质是eMMC，偶尔也有用SD卡甚至SATA硬盘的，但它们的行为逻辑完全不同。eMMC本质上是一颗NAND Flash加主控的合封芯片，关键限制有三点：

• 擦写寿命：SLC/MLC/TLC各有不同的P/E周期上限，TLC普遍在1000~3000次之间。系统日志频繁写入、数据库落盘这类操作，在服务器上不痛不痒，在eMMC上就是实打实的折寿。
• 读写不对称：NAND的写入需要先擦除块，小文件频繁改写的代价远高于顺序大块写入。
• 掉电风险：写入过程中断电可能造成块映射表损坏，后果比普通硬盘的坏道严重得多。

正因如此，工控单板的存储配置逻辑和服务器完全不同。服务器追求随机读写的极致性能，工控板追求的是“在有限寿命内稳定干活”。

我这次动手之前，先做了个简单的寿命估算。手上这块板子是8GB eMMC，搭载的存储颗粒写入寿命按3000次P/E算。如果无脑让系统日志直接写根分区，每天产生约100MB日志（这在跑Modbus采集和本地缓存的场景里很常见），那么一年就是36.5GB写入，8GB容量放大到整个盘的写入放大系数大概2~3倍，算下来一颗颗粒撑不到3年——这对于设计寿命5~10年的工控设备是不可接受的。这也是我接下来做分区和数据落盘策略调整的根本动机。

1.2 一套实用的四分区布局

传统的嵌入式系统往往就是“一个根分区+一个数据分区”完事，但我在量产项目里习惯用MBR或GPT做四个分区，各司其职：

分区的核心逻辑是：系统文件与应用数据、易变数据严格分离。这样升级时只需要重写rootfs分区，config和data不受影响，恢复出厂时只需要清config和data，而rootfs用OverlayFS层重置即可。

有些板子方案允许在U-Boot里直接把env保存在独立分区（比如/dev/mmcblk0p2旁边的一个小分区），这样bootloader环境变量就不会因为rootfs升级被覆盖。别小看这个细节，我第一次做升级方案时没注意，U-Boot环境变量被新系统镜像覆盖后，整套启动参数瞬间不对，开机直接进不了系统。

2. 升级不只是拷贝文件：从OTA设计到本地刷写的完整链路

2.1 升级的三种递进方案

工控设备升级最怕什么？升级到一半断电、升级文件损坏、升级后系统起不来。所以方案设计优先级是“可恢复性”高于一切。

我在不同项目里用过三种方案，复杂度递增，可靠性也递增：

1. 单副本rootfs直接覆写：最简单，但升级失败就只能进恢复模式或返厂。适合开发调试阶段，不适合量产。
2. A/B双分区切换：rootfs分两套（rootfs_a、rootfs_b），U-Boot根据标志位选择启动哪个。升级时写入非活动分区，写完后切换标志位。成本是存储空间翻倍，但升级失败可以自动回滚，几乎不可能变砖。
3. 增量OTA包+完整性校验：通过差分算法生成增量包，升级工具下载后先做签名和checksum校验。适合网络带宽有限的场景，但实现复杂度较高，需要管理好基版本。

我这块板子最终采用的是方案2的简版——双rootfs分区加一个misc分区存升级标志。存储虽然吃了点亏，但量产设备省下的售后成本远超这点eMMC钱。这里也提醒做选型的兄弟：8GB eMMC做A/B分区会比较紧张，裸系统压到1GB以内才有可能，否则老老实实上16GB。

2.2 手工升级的完整操作序列

先讲开发阶段我最常用的手工刷写流程，这套流程搞明白了，再理解OTA脚本就非常轻松。

首先确认当前分区布局：

cat /proc/cmdline # 查看root=参数指向哪个分区 ls -l /dev/mmcblk0*

假设新镜像包是rootfs.ext4，标准的刷写流程是：

# 写入目标分区（以/dev/mmcblk0p3为例） umount /dev/mmcblk0p3 dd if=/rootfs.ext4 of=/dev/mmcblk0p3 bs=4M conv=fsync status=progress

这里必须强调两点：

• bs=4M这个块大小在eMMC上写入速度差别很大，实测用默认512B写入8GB分区要半小时，用4M块只要三五分钟，因为NAND的物理块擦除粒度被充分利用了。
• conv=fsync是必须的，它确保dd返回时数据真正落盘，而不是停在page cache里。否则你马上断电，分区里写的可能是不完整的镜像，启动必挂。

接下来重置rootfs标志：

# 假设用misc分区存标志位，直接写一个固定结构体或字符串 echo -n "boot_rootfs_b" > /dev/mmcblk0p4 sync

然后重启即可生效。实际生产里这些操作会被封装成一个升级脚本，配合web后端或MQTT下发指令触发。但底层逻辑就这么点东西。

2.3 升级过程中的断电模拟测试

升级方案写完，不能只在正常环境里测，断电测试是必做项目。我在测试中专门用了一个能通过远程断开的插线板，对设备做随机断电，连续跑了20多次，覆盖的时机包括：

• dd写rootfs的前、中、后期
• 写misc标志位之前/之后
• 升级完成、重启出现U-Boot logo时

结果发现，只要U-Boot启动逻辑是“优先检查misc分区标志位来选rootfs”，那么即使rootfs写了一半就断电，重启后仍然能进入旧的rootfs_a正常启动，然后系统内的升级服务检查到“升级未完成”的残留标志，可以进行二次尝试或报错让运维干预。

这个A/B方案真正发挥作用的前提是：U-Boot的启动参数不要硬编码root=/dev/mmcblk0p3，而是动态拼接。如果U-Boot里写了死分区号，A/B切换就形同虚设。我在U-Boot里是通过检查misc分区的boot_part变量来设置root的：

# U-Boot环境变量示意 setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p${root_part} rootwait rw"

root_part的值在U-Boot脚本里根据misc分区内容动态赋给，这样切区逻辑就有了。这个细节做单板系统的人一定要记住，否则双分区方案会变成一个永远只在用A区的摆设。

3. OverlayFS的合并魔法：为什么它特别适合“恢复出厂”

3.1 一次看懂overlay的读写视角

OverlayFS的字面意思是“叠加文件系统”，它把两个目录叠在一起对外呈现：底层叫lowerdir（只读），上层叫upperdir（可写），再通过mount参数指定一个merged目录作为合并视图。读写操作看起来都发生在merged目录里，但实际写操作落到upperdir，读操作优先查upperdir，查不到再回落到lowerdir。

这个特性用来做恢复出厂简直是量身定做。想象一下：

• lowerdir是出厂时的只读根文件系统
• upperdir是系统运行后的所有改动
• 一旦需要恢复出厂，直接把upperdir清空重建，系统就跟刚烧录完一模一样

在恢复出厂的语义上，这个方案比重做根分区快得多、安全得多，因为不需要重新擦写eMMC，避免了擦写寿命消耗和掉电风险。

3.2 工控单板上的overlay实际做法

我的具体做法是：根文件系统还是正常烧在rootfs分区（不压缩，这样升级也能直接覆写），系统启动后通过一个systemd服务或者init脚本在挂载根之前的阶段做overlay的组装。实际项目中用的overlay挂载参数如下：

mount -t overlay overlay \ -o lowerdir=/mnt/rootfs_base,upperdir=/overlay/rw,workdir=/overlay/work \ /mnt/merged

如果改用squashfs作为只读根，则需要先把squashfs解包或者直接loop挂载成只读，再做overlay组合。但工控板的CPU大多不够强劲，squashfs解压再算上层叠的IO开销不小，反而可能拖慢启动。我在没有极端闪存容量压力的情况下，直接用的ext4只读挂载作为lowerdir，性能更好也省心。

挂载完成后，关键一步是pivot_root或者chroot把实际根切到merged目录，然后让init进程从merged路径启动。这样整个系统的视角就是“一个可写的正常文件系统”，所有对/etc、/usr、/var的修改都自动走了upperdir，对下层rootfs_base完全没有影响。

3.3 恢复出厂的物理操作与执行效果

恢复出厂的脚本其实精简到只要几条命令：

# 卸载当前overlay umount /mnt/merged # 清空upperdir和工作目录 rm -rf /overlay/rw/* rm -rf /overlay/work/* # 重新挂载 mount -t overlay overlay \ -o lowerdir=/mnt/rootfs_base,upperdir=/overlay/rw,workdir=/overlay/work \ /mnt/merged # 重新挂载根并切换 exec switch_root /mnt/merged /sbin/init

注意一点：清空upperdir时一定要先卸载merged目录，不能直接删merged下的内容。因为merged只是视图，直接在merged里删除文件，实际是在upperdir里创建whiteout标记，这不但删不干净，下次挂载还会留下垃圾。我实测过这个坑，后果是恢复出厂后“死灰复燃”了一些配置，排查了半天才发现是whiteout残留。

还有一个容易忽略的问题：恢复出厂时，block count和inode count要提前预留。upperdir所在的overlay分区我一般单独格式化成一个ext4小分区（1GB足够），平时/rw写满了会导致系统盘满，这时各种服务会莫名其妙崩溃，日志都刷不出来。所以在设计时就要把overlay容量纳入整体存储规划，别死命给data分区，留下只给upperdir的空间太少。

4. 量产定制里的实战路线：分区、升级与恢复三个环节如何衔接

4.1 拿到一块裸板后的落地步骤

如果你拿到一块全新工控单板，需要从裸板烧录到具备升级和恢复能力的完整系统，我的推荐路径是：

1. 用SD卡启动一个live Linux环境（或者用厂商提供的烧录工具）把eMMC分区表和基础镜像灌进去。
2. 在SD卡环境下把分区表用fdisk或sgdisk规划好，建议直接在烧录脚本里准备好，避免后续手工fdisk。
3. 写入第一阶段镜像，包含bootloader、内核、基础rootfs。
4. 启动到目标系统，接着部署overlay机制、升级脚本、恢复出厂脚本，并做一次完整备份。
5. 用备份生成的镜像作为量产母本，后续所有设备都刷这个母本。

其中第2步分区表规划，如果设备支持GPT，建议统一用GPT，不要再用MBR。原因很简单：GPT有冗余备份表头，分区被误写后仍有容错空间，而且eMMC容量超过2TB（虽然目前单板很少见）时MBR直接废掉。我这里因为考虑兼容老版本U-Boot，最终用了MBR，但如果你可以选，无脑选GPT。

4.2 升级与恢复两个机制的衔接点

最初我把升级和恢复当成两个孤立模块，后来测出几个问题才意识到它们必须配合。

• 升级完成后，upperdir里的旧环境变量残骸可能覆盖新系统的默认配置。比如新版本的软件改了某个/etc/xxx.conf的格式，但旧upperdir里还留着旧配置，启动后服务直接读错了。
• 恢复出厂如果做了，但固件本身是旧的，升级逻辑就补不上新功能。

所以我在实际量产方案中把两者设计成了互动的状态机：

这样设计的核心是：升级保留config分区中的重要配置（IP、序列号），恢复出厂保留bootloader不动，但清除用户态所有数据和配置。这样量产设备在客户现场出问题时，远程触发恢复出厂就能解决90%的软件配置问题，而不是现场返厂。

4.3 配置保留与清空的边界

这里有个常见的需求冲突：恢复出厂到底要不要保留网络配置？如果不保留，客户现场IP丢了，运维连设备都连不上；如果保留了，那恢复出厂跟重启也没区别。

我的处理方式是分两层：

• config分区中的网络配置文件独立出来，用一个软链接挂载到/etc下，默认保留，但它标记为factory_preserve。
• data分区里的数据库、日志、用户安装包等全部清空。

这样一个恢复出厂操作，设备能保持网络可达，但应用环境是“刚出厂”的状态，兼顾了可维护性和干净的恢复语义。

如果你连这个都觉得不够干净，可以把config也纳入清除范围，但务必确认现场访问设备的方式不依赖IP（比如还有串口或按键菜单），否则你等于把运维通道切断了。这个教训来自一次客户现场问题：恢复出厂太彻底，设备IP丢了，客户又没有串口调试线，最后只能派工程师跑一趟现场。

5. 升级与恢复实战中的失败现场：几个诡异的坑和排查链路

5.1 症状一：恢复出厂后部分配置残留

第一次测试恢复出厂，我执行完脚本后重启，发现设备的主机名还是改过的，但/etc/hosts却变回出厂版了。这个现象很怪，按说都在upperdir里，清空就应该都没了。

排查过程是这样的：

mount | grep overlay ls -la /overlay/rw cat /overlay/rw/etc/hostname cat /overlay/rw/etc/hosts

结果发现/etc/hostname确实已被删掉（说明upperdir清理成功），但系统中仍然读到旧的主机名。问题出在systemd的hostname缓存上：hostnamectl设置的主机名存在/var/lib/systemd/private/下，而这个目录我做了单独挂载到data分区，恢复出厂只清了upperdir，没清data，所以主机名从data分区“活”了回来。

这提醒我，恢复出厂不能只看rootfs的上层目录，还要审查哪些目录被bind mount或独立挂载了出去。常见的有：

• /var/lib/systemd（状态和随机种子）
• /var/lib/docker（容器数据）
• /etc/NetworkManager/system-connections（网络连接）

这些路径要么纳入config保留白名单，要么明确纳入清除清单。二选一，不要模糊处理。

5.2 症状二：升级后启动卡在内核panic，root分区怎么也挂不上

有次做A/B分区升级测试，新固件已经写入rootfs_b，bootflag也切换到了B，但重启后内核直接panic，提示VFS: Unable to mount root fs。第一反应是镜像没写完整，但重新回写一次后还是老样子。

最后查到U-Boot环境变量里，bootargs居然还带着旧的root=/dev/mmcblk0p3。因为U-Boot的bootargs来自env var，而env var又被固件更新脚本刷过一遍，但刷完后的值不是我期望的动态逻辑，而是“写死”的p3。

这个坑的根源是升级脚本在做分区写入时，把U-Boot env也一并覆盖了，但新env内容里包含错误的静态root参数。

解决方式是在升级脚本里明确增加一步：写入完成/切换bootflag之前，先设置正确的U-Boot环境变量，并验证实际启动后/proc/cmdline是否满足预期。可以在U-Boot里加一个“最小启动默认值”逻辑：如果在固定超时时间内没有读到有效的bootflag，就自动回退到rootfs_a。这样即使升级脚本把env搞得一团糟，设备也能以旧系统兜底启动，而不是卡死。

5.3 症状三：overlay的upperdir写满，系统进入只读地狱

还有一次是长时间跑测试后，overlay的upperdir分区满了，系统日志疯狂报No space left on device，但rootfs_base明明还有大量空闲。许多人第一反应是扩容rootfs，实际是upperdir所在的独立分区满了。

定位方式：

df -h

如果看到overlay挂载点的Use%已经100%，而/dev/mmcblk0p3（rootfs_base）才用了30%，问题就清楚了。解决办法是先清理upperdir里的明显垃圾（日志、apt缓存、临时文件），再考虑是否要给/overlay单独分配更大分区。

我的最终方案是：在系统里加一个systemd定时任务或inotify监视脚本，当/overlay使用率超过80%时自动压缩/清理/滚动日志，并在日志里留下告警。工控设备按年运行，这个守护机制不是可选项，而是必备品。

5.4 避坑清单总结

把这次调试过程中的关键经验汇总一下：

1. dd写eMMC务必用大块（bs=4M/8M）+fsync落盘，否则速度和完整性都不可靠。
2. U-Boot的启动参数必须动态配置root分区，写死分区号等于放弃A/B回滚能力。
3. 恢复出厂清空upperdir前先卸载merged视图，不要直接在merged里删除文件，避免whiteout残留。
4. 审查所有独立挂载/bind mount的目录，别让它们在恢复出厂后复活旧配置。
5. 升级脚本不要随手覆盖U-Boot env，如果覆盖必须验证bootargs，并提供回退机制。
6. 给upperdir/日志等易写满的分区留好余量，并部署自动清理，工控设备超长稳定运行靠的是机制，不是运气。

6. 实操体验与后续可扩展的方向

这次把存储、升级和OverlayFS恢复出厂整套链路走通之后，最直接的感受是：工控单板的系统定制跟普通服务器运维完全是两种思维方式，服务器的思路是“出了问题重启/重装”，工控板的思路是“无论什么故障，都要能在现场或远程、在保留通信链路的前提下快速恢复”。OverlayFS在这里不只是省空间的小技巧，它把“恢复出厂”的代价降到了秒级，并且不消耗eMMC的擦写寿命，这在以前用dd全盘重写方案的时代是不可想象的。

后面如果再往下走，有几个方向我觉得值得继续折腾。

• 把OTA升级从本地脚本升级为完整的差分增量方案，用类似zsync或自研的块级差分工具，把升级包从几百MB压到几十MB，这样窄带环境下的远程升级成功率会高很多。
• 给恢复出厂增加“保留IP”的Web交互界面，现场人员不需要懂Linux命令，点个按钮就能完成恢复。
• 再就是可以把整条链路编排进CI/CD里，每次新固件构建后自动做一次“升级+恢复出厂”冒烟测试，确保新版本不会破坏这个机制本身。

最后分享一个小技巧：我在量产母本系统里会预先放一个/opt/tools/rescue.sh脚本，内容就是“恢复出厂”的完整逻辑，但它会先检测当前分区剩余空间和关键服务状态，给出风险提示后才执行。别小看这个确认步骤，它在测试阶段救了我好几次——有一次脚本参数写错了，差点把config分区也一并清了，有了确认提示总算拦下来。

工控设备是拿来生产用的，稳定性和可恢复性永远是第一位的。这套存储配置、升级和恢复方案，我建议你在自己的板子上先完整测试几轮断电场景再上产线，尤其是U-Boot环境变量和overlay的挂载顺序这两块，最容易藏雷。折腾完你就会发现，其实底层逻辑并不复杂，关键是每一步都要想清楚“如果这步失败了，系统会退到哪里”。