Рекомендуемые методы безопасного обновления встроенного Linux в полевых условиях

Question

Встроенным устройствам на базе Linux часто требуется механизм обновления приложений и системных файлов.Например, лабораторный прибор (не подключенный к сети) с USB-портом может получать обновления программного обеспечения с USB-накопителя.

Было бы несложно запустить скрипт для копирования файлов на место во внутренней флэш-памяти устройства.Однако существует опасность того, что устройство потеряет питание в середине обновления и в конечном итоге превратится в "кирпич".

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

С файлами ядра и системными все сложнее, поскольку они распределены по всей файловой системе.

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

Каковы ваши подходы к этому требованию?

Answer 1

Я бы выбрал тот же подход, что и с файлами приложения:Найдите критические файлы и заполните собственный раздел, создайте ссылку на них и продублируйте раздел.Во всех ваших инициализациях вы должны сначала проверить, отображаются ли все ссылки на один и тот же раздел, если нет, сбросьте их (на раздел с файлами с самой последней датой определенного файла).Если вы хотите обновить, просто скопируйте все в новый раздел, и если все в порядке (crcs ok), выполните цикл по файлам и установите для каждого ссылку из одной файловой системы в другую.

Таким образом, ваши важные файлы всегда должны находиться в нормальном состоянии.

Сценарии:

1. Сбой обновления при копировании файлов на новый раздел

   Никаких проблем, потому что ссылки по-прежнему ведут на старые рабочие файлы.

2. Сбой обновления при привязке

   Нет проблем, потому что все новые файлы действительны и уже скопированы (иначе шаг повторной привязки не запустился бы), проверка установки исправит это

Answer 2

Если вам необходимо обеспечить надежность, у вас может быть два флеш-раздела (или даже чипа), один с текущей рабочей конфигурацией и один с новой конфигурацией. Затем используйте аппаратный сторожевой таймер, который перезагрузит устройство и переключит активный загрузочный раздел флэш-памяти на «последний известный товар». конфигурации.

Answer 3

Имейте по крайней мере два раздела.Я бы предложил 4

• ботинок

• альтернативная загрузка

• резервное копирование программных данных

• изменчивые данные программы

Используйте резервную загрузку grub для альтернативной загрузки в случае сбоя загрузки.

Таким образом, если обновление завершается неудачей, альтернативный вариант работает.

НИКОГДА не обновляйте загрузчик.

Если раздел данных поврежден, переформатируйте и скопируйте поверх раздела резервных данных.

Теперь вы не сможете выйти из строя, пока флэш-диск не разрядится.Если вы используете оборудование COTS, а основным диском была, скажем, Compact flash, у вас могла бы быть физически изолированная резервная копия, скажем, на маленьком USB-ключе.

Answer 4

ИМХО, любое обновление, которое не является атомарным, может нарушить работу системы или затруднить проверку на согласованность.Я согласен, что следует избегать обновления загрузчика, поскольку его отключение небезопасно.Как правило, производитель хочет обновить прошивку с версии x.x.x до версии y.y.y, не беспокоясь о том, было ли обновлено ядро и / или отдельный файл.Обновление отдельных файлов может стать кошмаром для сервиса, потому что очень трудно понять, что запущено на оборудовании клиента.Возможно, вы смешиваете подход с двумя копиями (приложение является избыточным) с подходом с одной копией.Я думаю, что это не очень помогает, потому что целостность системы обеспечивается слабым компонентом в цепочке.Если обновление корневой файловой системы завершается неудачей, не важно, что приложение дублируется.

Подход с двойным копированием может гарантировать обновление без выхода из строя, если вам это нужно.Но для этого требуется много ресурсов, потому что все компоненты должны быть продублированы.Лично я использую запасной подход, при котором небольшой rootfs в оперативной памяти запускается в случае сбоя основного приложения или если последнее обновление не было успешным.Это резервная система, автоматически запускаемая загрузчиком, если что-то пойдет не так, обновите систему с USB-флешки (если требуется локальное обновление).

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

Может быть, вы сможете взглянуть на это.Вы можете найти исходные тексты для "swupdate" (название проекта) по адресу github.com/sbabic/swupdate.

Stefano

Answer 5

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

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

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