Подтвердить что ты не робот

Внедрение системы обновления/обновления встроенных устройств Linux

У меня есть приложение, которое работает на встроенном устройстве Linux, и время от времени происходят изменения в программном обеспечении, а иногда и в корневой файловой системе или даже в установленном ядре.

В текущей системе обновления содержимое старого каталога приложения просто удаляется, а новые файлы копируются поверх него. Когда изменения в корневой файловой системе были сделаны, новые файлы доставляются как часть обновления и просто копируются поверх старых.

Теперь есть несколько проблем с текущим подходом, и я ищу способы улучшить ситуацию:

  • Корневая файловая система цели, используемая для создания образов файловой системы, не является версией (я не думаю, что у нас даже есть исходные rootfs).
  • Файлы rootfs, которые входят в обновление, выбираются вручную (вместо diff)
  • Обновление постоянно растет и становится питой. В настоящее время существует разделение между обновлением/обновлением, где обновление содержит более крупные изменения rootfs.
  • У меня создается впечатление, что проверки согласованности в обновлении довольно хрупкие, если они вообще реализованы.

Требования:

  • Пакет обновления приложения не должен быть слишком большим, и он также должен иметь возможность изменять корневую файловую систему в случае, если были внесены изменения.
  • Обновление может быть намного больше и содержит только материал, который входит в корневую файловую систему (например, новые библиотеки, ядро ​​и т.д.). Для обновления может потребоваться обновление, которое необходимо установить.
    Может ли обновление содержать всю корневую файловую систему и просто сделать dd на флеш-диске цели?
  • Создание пакетов обновления/обновления должно быть максимально автоматическим.

Мне абсолютно необходим способ управления версиями корневой файловой системы. Это должно быть сделано таким образом, что я могу вычислить из него какой-то diff, который можно использовать для обновления rootfs целевого устройства.

Я уже изучал Subversion, поскольку мы используем это для нашего исходного кода, но это неуместно для корневой файловой системы Linux (разрешения файлов, специальные файлы и т.д.).

Теперь я создал некоторые сценарии оболочки, которые могут дать мне что-то похожее на svn diff, но мне бы очень хотелось узнать, существует ли уже существующее и протестированное решение для этого.

Используя такой diff, я предполагаю, что Upgrade просто превратится в пакет, содержащий инкрементные обновления, основанные на известном состоянии корневой файловой системы.

Каковы ваши мысли и идеи по этому поводу? Как бы вы реализовали такую ​​систему? Я предпочитаю простое решение, которое может быть реализовано в течение не слишком много времени.

4b9b3361

Ответ 1

Я считаю, что вы неправы в этой проблеме: любое обновление, которое не является атомарным (например, dd образ файловой системы, заменяет файлы в каталоге) нарушается по дизайну - если питание отключается в середине обновления, система - это кирпич и встроенная система, мощность может уйти в середине обновления.

Я написал технический документ о том, как правильно обновлять/обновлять встроенные системы Linux [1]. Он был представлен в OLS. Вы можете найти статью здесь: https://www.kernel.org/doc/ols/2005/ols2005v1-pages-21-36.pdf

[1] Бен-Йоссеф, Гилад. "Построение встроенных Linux-систем, совместимых с Murphy". Симпозиум Linux. 2005.

Ответ 2

Я абсолютно согласен с тем, что обновление должно быть атомарным - я недавно начал проект с открытым исходным кодом, цель которого - обеспечить безопасный и гибкий способ управления программным обеспечением с локальным и удаленным обновлением. Я знаю, что мой ответ приходит очень поздно, но это может помочь вам в следующих проектах.

Вы можете найти источники для "swupdate" (название проекта) в github.com/sbabic/swupdate.

Стефано

Ответ 3

Атомность имеет решающее значение для встроенных устройств, одна из причин, о которых идет речь, - потеря мощности; но могут быть другие, такие как проблемы с оборудованием/сетью.

Атоматичность, возможно, немного неправильно понята; это определение, которое я использую в контексте обновлений:

  • Обновление всегда завершается полностью или вообще не выполняется
  • Никакой программный компонент, кроме обновления, никогда не видит обновленного обновления.

Полное обновление изображения с использованием двойной структуры разделов A/B - это самый простой и проверенный способ достижения этого.

Для встроенного Linux существует несколько программных компонентов, которые вы можете захотеть обновить и выбрать разные варианты; здесь есть более новая статья: https://mender.io/resources/Software%20Updates.pdf

Если вы работаете с проектом Yocto, вам может быть интересно Mender.io - проект с открытым исходным кодом, над которым я работаю. Он состоит из клиента и сервера, и цель состоит в том, чтобы сделать его намного быстрее и проще интегрировать обновление в существующую среду; без необходимости перепроектировать слишком много или тратить время на обычное/доморощенное кодирование. Он также позволит вам централизованно управлять обновлениями с сервером.

Ответ 4

В настоящее время существует множество инструментов для обновления встроенных Linux с открытым исходным кодом, с разным фокусом.

Другим, о котором стоит упомянуть, является RAUC, в котором основное внимание уделяется обработке безопасных и атомных установок подписанных пакетов обновлений на вашей целевой будучи очень гибким в том, как вы адаптируете его к своему приложению и окружающей среде. Источники находятся на GitHub: https://github.com/rauc/rauc

В целом, хороший обзор и сравнение текущих решений по обновлению, которые вы можете найти на странице Wiki Yocto Project об обновлениях системы:

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

Ответ 5

Вы можете опубликовать обновление и разделить флеш обновления на два слота. Сбой питания всегда возвращает вас в текущий исполняемый слот. Последний шаг - изменить значение журнала. Не атомарный и не способ сделать его кирпичом. Даже если это не удается в момент написания флагов журнала. Нет такой вещи, как атомное обновление. Когда-либо. Никогда не видел этого в моей жизни. Iphone, adroid, мой сетевой коммутатор - ни один из них не является атомарным. Если у вас недостаточно места для такого дизайна, исправьте дизайн.