---

> 📺 **B站 嵌入式孙老师**：[博主个人介绍](https://www.bilibili.com/video/BV1aqj3zyEaH/)
📘 **博主书籍-京东购买链接**：[Yocto项目实战教程](https://item.jd.com/15020438.html)
📘 **加博主微信，进技术交流群**：**jerrydev**

---
# RAUC 是什么？一篇讲清嵌入式 Linux A/B OTA、回滚与服务器协作

做嵌入式 Linux 产品，OTA 真正难的并不是“下载一个新版本”。

真正的问题是：

**升级过程中断电怎么办？新系统启动失败怎么办？升级包被篡改怎么办？设备怎么自动恢复？**

RAUC 就是为这些问题设计的。

RAUC 全称 **Robust Auto-Update Controller**，可以理解为嵌入式 Linux 设备上的**可靠升级控制器**。


它最核心的作用是：

**验证升级包、安装新系统、管理 A/B Slot，并与 Bootloader 配合完成系统切换和失败恢复。**

---

## 1. RAUC 在系统中的位置

先看整个系统架构。
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-7622644/58e2619c57c6d8e6287c98050cb070a4.png)



RAUC 本质上运行在设备端。

典型关系是：

**OTA Server → RAUC → Bootloader / Rootfs A/B**

服务器负责提供升级包，RAUC 负责把升级包可靠地安装到设备。

所以 RAUC 本身并不是一个完整的云端 OTA 管理平台。

它更像设备内部的 **Update Engine**。

---

## 2. 为什么 RAUC 经常和 A/B 分区一起使用？

假设设备只有一个 Rootfs。
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-7622644/58e2619c57c6d8e6287c98050cb070a4.png)


升级时直接覆盖正在运行的系统，如果写到一半突然断电，就可能出现：

旧系统已经被破坏，新系统又没有写完整。

最终设备无法启动。

A/B 的思路则不同。

假设当前设备运行：

**Rootfs A**

升级时 RAUC 不直接覆盖 A，而是把新版本写入：

**Rootfs B**

因此：

**始终升级当前没有运行的那一侧。**

这就是 A/B OTA 最核心的设计思想。

---

## 3. 一次 RAUC 升级到底发生了什么？

下面这张图基本把整个流程串起来了。


假设：

Rootfs A 正在运行 V1.0。

服务器发布：

`V2.0.raucb`

设备获得升级包后，RAUC 大致完成：

**验证升级包 → 写入 Rootfs B → 修改启动状态 → 重启 → 尝试新系统**

设备端最典型的命令：

```bash
rauc install update.raucb
```
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-7622644/9c048f321427f3d9552b689b80aa4fa5.png)

RAUC 使用的升级包通常叫 **Bundle**，常见扩展名是：

```text
.raucb
```

例如：

```text
camera-v2.0.raucb
```

---

## 4. 为什么升级包还需要签名？

OTA 包不能下载下来以后直接写 Flash。

设备首先需要确认：

**这个升级包是不是可信的？**

因此生产系统通常会对 RAUC Bundle 做数字签名。

构建服务器生成升级包并签名，设备中的 RAUC 使用可信证书进行验证。

只有验证通过，才允许继续安装。

这样可以和 Secure Boot 形成两个不同阶段的保护：

**Secure Boot：保证启动的软件可信。**

**RAUC Bundle Signature：保证升级进去的软件可信。**

一个保护启动链，一个保护升级链。

---

## 5. 新系统写成功，不代表升级成功

这是 OTA 中非常重要的一点。

假设 RAUC 已经把 V2.0 成功写入 Rootfs B。

这只能说明：

**Flash 写入成功。**

但并不能证明：

**这个 Linux 系统真的能正常工作。**

因此下一步需要重启，并真正尝试从 Rootfs B 启动。

例如检查：

- Kernel 是否正常启动
- Rootfs 是否正常挂载
- 网络是否正常
- Camera 是否正常
- 核心应用是否正常运行

只有这些关键功能真正正常，才能认为升级成功。

---

## 6. mark-good：确认新系统可以正式使用

RAUC 中有一个很重要的操作：

```bash
rauc status mark-good
```

它表达的意思就是：

**当前系统已经验证正常，可以正式作为可启动系统。**

例如一个 Edge AI Camera，可以设计成：

Linux 启动完成后，继续检查 Camera、ISP、网络和主应用。

全部正常以后，再执行：

```bash
rauc status mark-good
```

这样会比“Linux 启动起来就认为升级成功”可靠得多。

---

## 7. 如果新系统启动失败怎么办？

这就是 A/B OTA 最大的价值。


假设：

Rootfs A 是原来的 V1.0。

Rootfs B 是刚升级的 V2.0。

如果 Rootfs B 启动正常：

**启动 → 健康检查 → mark-good → Rootfs B 成为正常系统**

如果 Rootfs B 出现：

- Kernel Panic
- Rootfs 挂载失败
- 应用异常
- Watchdog Reset

系统就不能执行正常的 mark-good。

这时候 Bootloader 可以根据 Boot Counter 和 Slot 状态，重新切换回 Rootfs A。

所以要注意：

**自动回滚并不是 RAUC 一个人完成的。**

真正的可靠升级通常依赖：

**RAUC + Bootloader + Boot Counter + Health Check + Watchdog**

RAUC 负责升级和 Slot 状态。

Bootloader 负责真正决定下一次从哪个 Slot 启动。

---

## 8. RAUC 能不能管理几百、几千台设备？

可以，但需要服务器和设备 Agent 配合。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-7622644/33ab70bfdd90a574ae413a5218b76fc5.png)

一套完整产品通常分成三部分。

### OTA Server

负责：

设备管理、版本管理、设备分组、灰度发布、升级统计。

### Device Agent

负责：

连接服务器、检查新版本、下载 `.raucb`、调用 RAUC、上报结果。

### RAUC

负责：

验证升级包、安装升级包、管理 Slot、与 Bootloader 协作。

因此整个架构可以理解成：

**OTA Server → Device Agent → RAUC → Rootfs A/B**

服务器完全可以一次发布 V2.0，然后让几百、几千台设备逐步自动升级。

只是：

**Fleet Management 不是 RAUC 本身的核心功能。**

---

## 9. RAUC、SWUpdate、Mender 有什么不同？

这三个名字经常一起出现，但定位并不完全一样。
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-7622644/c9a6654c7c127a9459ba2dc90cffe1e6.png)


简单来看：

| 方案 | 主要定位 | 特点 |
|---|---|---|
| RAUC | 可靠设备端升级 | A/B、签名、Slot、回滚逻辑清晰 |
| SWUpdate | 灵活设备端升级 | 多组件和自定义升级流程更灵活 |
| Mender | 完整 OTA 平台 | Client + Server + Fleet Management |

可以这样记：

**RAUC = 可靠升级发动机**

**SWUpdate = 更灵活的升级发动机**

**Mender = 升级发动机 + OTA Server + 设备管理平台**

---

## 10. RAUC 和 SWUpdate 怎么选？

如果产品主要是：

**Linux + A/B Rootfs + 可靠回滚**

那么 RAUC 很合适。

典型组合：

```text
Yocto
+
U-Boot
+
Rootfs A
+
Rootfs B
+
RAUC
```

如果一个产品需要同时升级：

Linux Rootfs、Kernel、DTB、MCU Firmware、FPGA、AI Model、配置文件……

那么 SWUpdate 通常会更加灵活。

简单来说：

**RAUC 更强调可靠、清晰的系统级升级。**

**SWUpdate 更强调复杂、多组件升级流程。**

---

## 11. RAUC 和 Mender 怎么选？

如果公司已经拥有自己的：

IoT Cloud、设备管理服务器或者 OTA Backend，

那么可以采用：

```text
Company Cloud
      ↓
Device Agent
      ↓
RAUC
```

RAUC 专门负责设备内部的可靠升级。

如果希望直接获得：

设备管理、版本管理、批量发布、Deployment、升级统计、Web 管理界面，

那么 Mender 更接近完整解决方案。

所以：

**RAUC 不是一个“小号 Mender”。**

两者解决的问题层级并不完全相同。

---

## 12. Yocto + RAUC 是很典型的组合

对于 Yocto 产品，可以把升级直接纳入整个系统构建流程：

```text
Yocto Build
    ↓
Kernel + Rootfs
    ↓
RAUC Bundle
    ↓
product-v2.0.raucb
    ↓
OTA Server
    ↓
Device
```

CI/CD 每次发布正式版本时直接生成新的 `.raucb`。

设备拿到以后由 RAUC 安装到 Inactive Slot。

这种方式特别适合：

**工业设备、AI Camera、机器人、网关、Edge AI 和长期维护的嵌入式 Linux 产品。**

---

## 13. RAUC 真正解决的是“升级失败怎么办”

如果只是想升级一个 Rootfs，其实 Shell 都能完成：

```bash
wget rootfs.img
dd if=rootfs.img of=/dev/mmcblk0p2
reboot
```

但真正做产品以后，问题会变成：

**写 Flash 时断电怎么办？**

**Kernel 起不来怎么办？**

**Rootfs 损坏怎么办？**

**升级包被替换怎么办？**

**新应用启动不了怎么办？**

所以 OTA 真正重要的不是 Update。

而是：

**Robust Update。**

这正是 RAUC 中 **Robust** 的价值。

对于已经真正交付到客户手里的设备：

> **升级失败可以接受，但 OTA 把设备升级成砖，不能接受。**

这就是 RAUC 最核心的价值。

升级过程中断电怎么办？新系统启动失败怎么办？升级包被篡改怎么办？设备怎么自动恢复？

嵌入式 Linux OTA 为什么要用 RAUC？从 A/B 升级到自动回滚，一篇讲清楚

操作系统

后端

RAUC是嵌入式Linux设备上的可靠升级控制器，通过A/B分区、Bundle签名验证、Bootloader协作及mark-good健康检查，实现断电恢复、启动失败自动回滚和安全升级，常与Yocto、U-Boot配合使用，确保设备升级不"变砖"。

数字签名

代码解释

Bootloader

服务器

Kernel

Linux

Agent

FPGA

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

嵌入式 Linux OTA 为什么要用 RAUC？从 A/B 升级到自动回滚，一篇讲清楚-腾讯云开发者社区-腾讯云

嵌入式 Linux OTA 为什么要用 RAUC？从 A/B 升级到自动回滚，一篇讲清楚

嵌入式 Linux OTA 为什么要用 RAUC？从 A/B 升级到自动回滚，一篇讲清楚

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐