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

Implementing an update/upgrade system for embedded Linux devices

提问by trenki

I have an application that runs on an embedded Linux device and every now and then changes are made to the software and occasionally also to the root file system or even the installed kernel.

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

In the current update system the contents of the old application directory are simply deleted and the new files are copied over it. When changes to the root file system have been made the new files are delivered as part of the update and simply copied over the old ones.

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

Now, there are several problems with the current approach and I am looking for ways to improve the situation:

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

• The root file system of the target that is used to create file system images is not versioned (I don't think we even have the original rootfs).
• The rootfs files that go into the update are manually selected (instead of a diff)
• The update continually grows and that becomes a pita. There is now a split between update/upgrade where the upgrade contains larger rootfs changes.
• I have the impression that the consistency checks in an update are rather fragile if at all implemented.

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

Requirements are:

要求是：

• The application update package should not be too large and it must also be able to change the root file system in the case modifications have been made.
• An upgrade can be much larger and only contains the stuff that goes into the root file system (like new libraries, kernel, etc.). An update can require an upgrade to have been installed.
  Could the upgrade contain the whole root file system and simply do a ddon the flash drive of the target?
• Creating the update/upgrade packages should be as automatic as possible.

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

I absolutely need some way to do versioning of the root file system. This has to be done in a way, that I can compute some sort of difffrom it which can be used to update the rootfs of the target device.

我绝对需要某种方式来对根文件系统进行版本控制。这必须以某种方式完成，我可以从中计算出diff可用于更新目标设备的 rootfs 的某种类型。

I already looked into Subversion since we use that for our source code but that is inappropriate for the Linux root file system (file permissions, special files, etc.).

我已经研究过 Subversion，因为我们将其用于我们的源代码，但这不适用于 Linux 根文件系统（文件权限、特殊文件等）。

I've now created some shell scripts that can give me something similar to an svn diffbut I would really like to know if there already exists a working and tested solution for this.

现在我已经创造了一些shell脚本，可以给我类似的东西svn diff，但我真的很想知道，如果有已经存在这样的工作和测试的解决方案。

Using such diff's I guess an Upgrade would then simply become a package that contains incremental updates based on a known root file system state.

使用此类diff，我猜升级将简单地成为包含基于已知根文件系统状态的增量更新的包。

What are your thoughts and ideas on this? How would you implement such a system? I prefer a simple solution that can be implemented in not too much time.

您对此有何想法和想法？您将如何实施这样的系统？我更喜欢一个可以在短时间内实施的简单解决方案。

采纳答案by gby

I believe you are looking wrong at the problem - any update which is non atomic (e.g. dd a file system image, replace files in a directory) is broken by design - if the power goes off in the middle of an update the system is a brick and for embedded system, power can go off in the middle of an upgrade.

我相信您对这个问题的看法是错误的 - 任何非原子更新（例如 dd 文件系统映像，替换目录中的文件）都被设计破坏了 - 如果在更新过程中断电，则系统是一个对于嵌入式系统，电源可能会在升级过程中断电。

I have written a white paper on how to correctly do upgrade/update on embedded Linux systems [1]. It was presented at OLS. You can find the paper here: https://www.kernel.org/doc/ols/2005/ols2005v1-pages-21-36.pdf

我写了一篇关于如何在嵌入式 Linux 系统上正确升级/更新的白皮书 [1]。它在 OLS 上展出。你可以在这里找到这篇论文：https: //www.kernel.org/doc/ols/2005/ols2005v1-pages-21-36.pdf

[1] Ben-Yossef, Gilad. "Building Murphy-compatible embedded Linux systems." Linux Symposium. 2005.

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

回答by MaxDeusPhallus

You can journal an update and divide your update flash into two slots. Power failure always returns you to the currently executing slot. The last step is to modify the journal value. Non atomic and no way to make it brick. Even it if fails at the moment of writing the journal flags. There is no such thing as an atomic update. Ever. Never seen it in my life. Iphone, adroid, my network switch -- none of them are atomic. If you don't have enough room to do that kind of design, then fix the design.

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

回答by sbabic

I absolutely agree that an update must be atomic - I have started recently a Open Source project with the goal to provide a safe and flexible way for software management, with both local and remote update. I know my answer comes very late, but it could maybe help you on next projects.

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

You can find sources for "swupdate" (the name of the project) at github.com/sbabic/swupdate.

您可以在 中找到“swupdate”（项目名称）的来源github.com/sbabic/swupdate。

Stefano

斯特凡诺

回答by rduio

Atomicity is critical for embedded devices, one of the reasons highlighted is power loss; but there could be others like hardware/network issues.

原子性对于嵌入式设备至关重要，突出显示的原因之一是功率损耗；但可能还有其他硬件/网络问题。

Atomicity is perhaps a bit misunderstood; this is a definition I use in the context of updaters:

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

• An update is always either completed fully, or not at all
• No software component besides the updater ever sees a half installed update

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

Full image update with a dual A/B partition layout is the simplest and most proven way to achieve this.

具有双 A/B 分区布局的完整映像更新是实现此目标的最简单且最成熟的方法。

For Embedded Linux there are several software components that you might want to update and different designs to choose from; there is a newer paper on this available here: https://mender.io/resources/Software%20Updates.pdf

对于嵌入式 Linux，您可能需要更新多个软件组件以及可供选择的不同设计；这里有一篇更新的论文：https: //mender.io/resources/Software%20Updates.pdf

File moved to: https://mender.io/resources/guides-and-whitepapers/_resources/Software%2520Updates.pdf

文件移至：https: //mender.io/resources/guides-and-whitepapers/_resources/Software%2520Updates.pdf

If you are working with the Yocto Project you might be interested in Mender.io- the open source project I am working on. It consists of a client and server and the goal is to make it much faster and easier to integrate an updater into an existing environment; without needing to redesign too much or spend time on custom/homegrown coding. It also will allow you to manage updates centrally with the server.

如果您正在使用 Yocto 项目，您可能会对Mender.io感兴趣——我正在开发的开源项目。它由客户端和服务器组成，目标是让更新程序更快速、更轻松地集成到现有环境中；无需重新设计太多或花时间在自定义/本土编码上。它还允许您使用服务器集中管理更新。

回答by ejoerns

Currently, there are quite a few Open Source embedded Linux update tools growing, with different focus each.

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

Another one that is worth being mentioned is RAUC, which focuses on handling safe and atomic installations of signed update bundles on your target while being really flexible in the way you adapt it to your application and environment. The sources are on GitHub: https://github.com/rauc/rauc

另一个值得一提的是RAUC，它专注于在目标上处理签名更新包的安全和原子安装，同时在让您适应应用程序和环境的方式上非常灵活。源代码在 GitHub 上：https: //github.com/rauc/rauc

In general, a good overview and comparison of current update solutions you might find on the Yocto Project Wiki page about system updates:

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

https://wiki.yoctoproject.org/wiki/System_Update

https://wiki.yoctoproject.org/wiki/System_Update