嵌入式 Linux 的 OTA 更新，第 1 部分 – 基础知识和实施

更新的需要

一旦嵌入式 Linux 产品离开实验室并进入现实世界，如何更新设备的问题将成为需要考虑的重要问题。

更新并不总是必要的，但很难想出任何软件都没有在某个时候发现的错误。即使您的软件是完美的，如果设备在网络或互联网上与任何开源库通信，安全更新也可能成为必要。

以 CVE-2104-01650 (Heartbleed) 为例。此漏洞影响了 OpenSSL 加密库，进而影响了网络上三分之二的网站。即使是现在，三年后，仍有许多嵌入式 Linux 设备运行未防御版本的 OpenSSL，对攻击开放。

阻止与文件更新

在谈论更新 Linux 时，您可能会看到提到了“块”和“文件”更新系统。这是指通过直接写入块设备或更新单个文件来执行更新，一次更新整个分区。您可能熟悉 Desktop 或 Server Linux 的文件更新系统（例如“sudo apt-get upgrade”）。

在嵌入式 Linux 中，基于块的升级是可行的方法，因为它们具有原子性，并且整个文件系统通常是嵌入式 Linux 构建系统的输出。我们希望每个嵌入式设备上的存储空间对于特定产品是恒定的，因此我们每次都创建相同大小的分区。这种类型的更新与某种后备或恢复映像密切相关。

发生故障时的恢复

我们绝不希望设备处于无法使用的状态（例如，如果发生停电）。我们可以通过确保在更新过程中出现任何问题时始终可以“回退”到另一个分区来解决这个问题。

图 1. 发生故障时的恢复 – 回退选项（来源：ByteSnap）

在上面，您可以看到停电时回退模式的两种可能实现。在左侧，Bootloader 引导一个救援分区，然后引导到主分区。在右侧，Bootloader 基于交换机启动两个分区之一。

引导加载程序应该实现一些方法来确定引导是否成功，如果没有，它应该返回到救援分区（左图），或之前的工作分区（右图）。

救援方法（左手）允许为主分区提供更多空间，而双 rootfs 方法（右手）要求空间在两个分区之间或多或少地平均分配。如果空间不是问题，那么建议使用双 rootfs 方法，因为它会导致更少的停机时间。通过救援方法更新需要两次重启，一次进入救援分区，然后另一次回到主分区。双rootfs方式只需重启一次即可随时更新。

在这些系统中无法安全更新的是引导加载程序（或实际上是救援分区）。如果您也希望能够更新引导加载程序，则需要两个单独的引导加载程序分区，以及某种板管理控制器来实现两者之间的切换逻辑。

图 2. 发生故障时的恢复 – 板管理控制器（来源：ByteSnap）

这当然是一个复杂的解决方案，需要额外的微控制器、一套新的固件和更复杂的硬件设计（它用于某些设备，例如包含单独的智能平台管理接口 (IPMI) 控制器的设备） .因此，您的目标应该是构建一个功能强大、范围较小、因此不需要更新的引导加载程序。

U-Boot 环境变量

U-boot 实现了一个可以存储变量的非易失性“环境”。这些甚至可以从 Linux 访问（以各种方式，取决于环境的存储方式，详见 elinux.org。

这是实现上述“切换”的最明显方式。它还可以用于存储有关先前启动成功或失败的信息，以便在启动失败的情况下可以反转开关并恢复工作分区。

图 3. U-boot 环境变量（来源：ByteSnap）