嵌入式Linux设备更新升级系统的实现

我有一个在嵌入式Linux设备上运行的应用程序，不时会对软件进行更改，有时还会对根文件系统甚至已安装的内核进行更改

在当前的更新系统中，旧应用程序目录的内容被简单地删除，新文件被复制到它上面。对根文件系统进行更改后，新文件将作为更新的一部分交付，并简单地复制到旧文件上

现在，目前的方法存在一些问题，我正在寻找改善这种情况的方法：

• 用于创建文件系统映像的目标的根文件系统没有版本控制（我认为我们甚至没有原始的rootfs）
• 手动选择进入更新的rootfs文件（而不是diff）
• 更新将不断增长，这将成为一个pita。现在在更新/升级之间存在一个分割，其中升级包含更大的rootfs更改
• 我的印象是，更新中的一致性检查如果真的实现了，就相当脆弱

要求如下：

• 应用程序更新包不应太大，并且必须能够在进行修改的情况下更改根文件系统
• 升级可以大得多，只包含进入根文件系统的内容（如新库、内核等）。更新可能需要已安装升级。
  升级是否可以包含整个根文件系统，只需在目标的闪存驱动器上执行

  dd

• 创建更新/升级包应尽可能自动

我绝对需要一些方法来对根文件系统进行版本控制。这必须以某种方式完成，我可以从中计算某种类型的

diff

，用于更新目标设备的rootfs

我已经研究过Subversion，因为我们在源代码中使用了它，但它不适合Linux根文件系统（文件权限、特殊文件等）

我现在已经创建了一些shell脚本，这些脚本可以为我提供类似于

svn diff

的东西，但是我真的很想知道是否已经存在一个用于此的工作和测试解决方案

使用这样的

diff

，我想升级会变成一个包，包含基于已知根文件系统状态的增量更新

---

你对此有什么想法和想法？您将如何实施这样一个系统？我更喜欢一个简单的解决方案，它可以在不太多的时间内实现。

< P>我相信你在这个问题上看起来是错误的——任何非原子的更新（例如DD文件系统映像，替换目录中的文件）都被设计打破了——如果在更新的过程中断电，系统是一块砖块，对于嵌入式系统来说，在升级过程中，电源可能会关闭。 我写了一篇关于如何在嵌入式Linux系统上正确进行升级/更新的白皮书[1]。它是在OLS上提出的。你可以在这里找到报纸：

---

[1] 本·约瑟夫，吉拉德。“构建与墨菲兼容的嵌入式Linux系统”，Linux研讨会。2005。

您可以记录更新并将更新闪存分成两个插槽。电源故障总是将您返回到当前正在执行的插槽。最后一步是修改日记账值。没有原子，也没有办法让它变成砖。即使它在写入日志标志时失败。没有原子更新这样的东西。曾经我这辈子从没见过。Iphone、adroid、我的网络交换机——它们都不是原子的。如果您没有足够的空间来进行这种设计，那么请修复该设计

我完全同意更新必须是原子的——我最近启动了一个开源项目，目标是为软件管理提供一种安全灵活的方式，包括本地和远程更新。我知道我的答案来得很晚，但它可能会对你下一个项目有所帮助

您可以在找到“swupdate”（项目名称）的源代码

---

Stefano

原子性对于嵌入式设备至关重要，突出显示的原因之一是电源损耗；但也可能存在其他问题，如硬件/网络问题

原子性可能有点被误解；这是我在更新程序上下文中使用的定义：

• 更新总是完全完成，或者根本不完成
• 除了更新程序之外，没有任何软件组件可以看到安装了一半的更新

使用双a/B分区布局的完整映像更新是实现这一点的最简单和最可靠的方法

对于嵌入式Linux，您可能需要更新几个软件组件，并选择不同的设计；这里有一篇关于这方面的较新论文：

文件移动到：

---

如果你正在与Yocto项目合作，你可能会感兴趣——我正在从事的开源项目。它由客户端和服务器组成，目标是使更新程序更快更容易地集成到现有环境中；无需重新设计太多或花费时间在定制/自制编码上。它还允许您通过服务器集中管理更新。

目前，有相当多的开源嵌入式Linux更新工具正在发展，每个工具的重点都不同

另一个值得一提的是，它专注于在您的目标上处理签名更新包的安全和原子安装，同时在使其适应您的应用程序和环境的方式上非常灵活。源位于GitHub上：

通常，您可以在Yocto Project Wiki页面上找到有关系统更新的当前更新解决方案的良好概述和比较：

---

非常感谢那篇文章，我会尽快看的。我知道，非原子更新实际上已被破坏，但它仍然会更好