📚 课程目录第1章课程导入

1. 课程导入

在嵌入式 Linux、工业网关、车载终端与边缘计算设备中，rootfs（根文件系统）是系统能否正常启动与运行的核心载体。一次失败的升级，轻则导致业务中断，重则让设备彻底“变砖”，只能返厂或现场拆机。因此，版本升级回滚机制不是锦上添花的功能，而是量产设备必须具备的可靠性底座。本课程以“可落地、可验证、可量产”为目标，带你从原理到工程，完整构建一套 rootfs 升级与回滚体系。

一、学习目标：从“会升级”到“敢升级”

本课程的学习目标分为四个层次，层层递进：

理解原理：掌握 A/B 双分区、启动标志（boot flag）、回滚触发条件、原子切换等核心机制，理解为什么“先写备份、再切启动”比“原地覆盖”更安全。
掌握方法：能够设计升级包格式、校验策略、分区布局与启动流程，并编写升级脚本与回滚逻辑。
工程落地：在真实 rootfs 上完成分区规划、镜像制作、升级执行、失败回滚与日志追踪，形成可复用的工程模板。
排障复盘：能够定位升级失败、回滚不生效、启动卡死等典型问题，并给出可验证的修复方案。

核心判断标准：升级成功的定义不是“写完了”，而是“新系统启动成功并稳定运行，且旧系统仍可回退”。

二、核心概念：五个必须厘清的术语

在进入实战之前，先统一语言。以下五个概念贯穿全课程：

概念	含义	工程关注点
rootfs	根文件系统，包含 /bin、/etc、/lib 等系统运行所需内容	只读挂载、完整性校验、版本标识
A/B 分区	两套可独立启动的 rootfs 分区，互为备份	分区大小、镜像写入、启动切换
启动标志	记录当前应启动哪个分区的元数据（如 bootcount、slot）	掉电安全、写入原子性
回滚	新版本启动失败或校验不通过时，切回旧版本	触发条件、自动/手动、回滚次数限制
原子切换	通过一次标志写入完成启动分区切换，避免中间态	写前校验、双写确认、恢复默认

其中，启动标志的原子性是回滚机制的生命线。如果标志写入过程中掉电，设备可能既不知道启动 A 还是 B，也无法回滚。因此工程上通常采用“双副本 + 校验和”或“写新标志后再擦旧标志”的策略。

三、整体框架：升级与回滚的闭环

一套完整的 rootfs 升级回滚机制，可以抽象为“准备—写入—切换—验证—回滚”五个阶段。下图展示了各阶段之间的数据流与判断关系：

从图中可以看到，升级不是单向流程，而是一个带反馈的闭环：验证失败会触发回滚，回滚后再次进入启动验证。工程实现时，这个闭环通常由 bootloader、内核启动参数、用户态升级代理三部分协同完成。

四、实战工程概览：我们将构建什么

本课程以一个典型的嵌入式 Linux 设备为背景，rootfs 采用 squashfs 只读镜像，存储介质为 eMMC，分区布局如下：

mmcblk0p1  bootloader   (uboot)
mmcblk0p2  rootfs_a     (squashfs, 当前运行)
mmcblk0p3  rootfs_b     (squashfs, 备用)
mmcblk0p4  data         (ext4, 配置与日志)
mmcblk0p5  meta         (启动标志与版本信息)

升级时，系统将新 rootfs 写入 rootfs_b，校验通过后更新 meta 分区中的启动标志，重启后由 bootloader 读取标志并启动 rootfs_b。若新系统在限定次数内未完成“启动成功确认”，bootloader 自动切回 rootfs_a，实现回滚。

建议在 meta 分区中同时保存 slot_a 与 slot_b 的版本号、校验和、启动成功计数，便于现场排查与远程诊断。

五、常见误区与复盘要点

初学者最容易踩的坑，往往不是代码写错，而是设计假设不成立：

误区一：原地覆盖升级。直接覆盖当前 rootfs，一旦掉电或写入失败，系统无法启动，也没有旧版本可回退。
误区二：只校验写入，不校验启动。镜像写入成功不等于系统能启动，必须增加启动成功确认机制。
误区三：启动标志非原子写入。标志写入过程中掉电，可能导致 bootloader 无法判断启动分区。
误区四：回滚无次数限制。若新旧版本都启动失败，设备会陷入无限重启，必须设置回滚上限并进入恢复模式。