組み込みLinuxを安全にフィールド更新するための推奨テクニック

Question

組み込みLinuxベースのデバイスには、多くの場合、アプリケーションとシステムファイルを更新するメカニズムが必要です。たとえば、USBポートを備えた（ネットワーク化されていない）ラボ機器は、USBスティックからソフトウェアの更新を取得できます。

スクリプトを実行してファイルをデバイスの内部フラッシュメモリの所定の場所にコピーするのは簡単なことです。ただし、更新の途中でデバイスの電源が失われ、ブリックが発生する危険があります。

アプリケーションファイルの状況は、アプリケーションディレクトリを複製し、1つのコピーを更新し、古いディレクトリと新しいディレクトリをすばやく交換して、障害ウィンドウを最小限に抑える余地があるため、少し簡単です。

カーネルとシステムファイルはファイルシステム全体に分散しているため、これらのファイルは扱いにくいです。

重要なファイルを識別するために、ファイルシステムでハードリンクとソフトリンクを使用しました。ファイルとアーカイブにハッシュを使用して、ファイルの整合性を検証します。更新されたファイルシステムからの起動に失敗した場合に、フォールバックを提供するためにカーネルで緊急ramfsを使用することを検討しました。

この要件へのアプローチはどのようなものですか？

Answer 1

アプリケーションファイルと同じアプローチを使用します。 重要なファイルを作成し、独自のパーティションを完成させ、それらにリンクし、パーティションを複製します。すべてのinitで、最初にリンクが同じパーティションにすべて表示されるかどうかを確認する必要があります。そうでない場合は、それらをリセットします（特定のファイルの最新の日付を持つファイルのパーティションに）。更新したい場合は、すべてを新しいパーティションにコピーし、すべてが正常であれば（crcs ok）ファイルをループし、1つのファイルシステムから他のファイルシステムへの各リンクを設定します。

これにより、重要なファイルは常に正常な状態になります。

シナリオ：

1. 新しいパーティションにファイルをコピー中に更新が失敗します

   リンクは古い動作中のものにまだ表示されるため問題ありません。

2. リンク中に更新が失敗します

   すべての新しいファイルが有効で既にコピーされているため（再リンク手順が開始されない場合）、問題はありません。セットアップはこれを修正します

Answer 2

信頼性を確保する必要がある場合は、2つのフラッシュパーティション（またはチップ）を使用できます。1つは現在の構成で、もう1つは新しい構成です。次に、ハードウェアウォッチドッグを使用して、ユニットをリセットし、アクティブなブートフラッシュパーティションを「最後の既知の良好な」パーティションに切り替えます。設定。

Answer 3

少なくとも2つのパーティションがあります。 4をお勧めします

• boot

• 代替ブート

• プログラムデータのバックアップ

• 揮発性データのプログラム

ブートが失敗した場合、grubフォールバックブートを使用して代替ブートします。

更新が失敗した場合、代替が機能します。

ブートローダーを更新しないでください。

データパーティションがトーストされている場合、バックアップデータパーティションを再フォーマットしてコピーします。

これで、フラッシュディスクが死ぬまで失敗することはありません。 COTSハードウェアを使用していて、メインディスクがコンパクトフラッシュである場合、物理的に分離されたバックアップ、たとえば小さなUSBキーを使用できます。

Answer 4

アトミックではない更新は、システムを破壊したり、一貫性のチェックを非常に困難にしたりします。ブートローダーは安全に電源オフされないため、ブートローダーの更新は避けなければならないことに同意します。 一般的に、製造業者は、カーネルや単一のファイルが更新されても気にすることなく、ファームウェアx.x.xからバージョンy.y.yへの更新を望んでいます。単一のファイルを更新することは、顧客のハードウェアで何が実行されているかを理解するのが非常に難しいため、サービスにとって悪夢になる可能性があります。デュアルコピーアプローチ（アプリケーションは冗長）とシングルコピーアプローチを混在させているのかもしれません。システムの整合性はチェーン内の弱いコンポーネントによって行われるため、これはあまり役に立たないと思います。ルートファイルシステムの更新が失敗した場合、アプリケーションが複製されることは重要ではありません。

デュアルコピーアプローチでは、必要に応じて、サービスを停止することなく更新を保証できます。ただし、すべてのコンポーネントを複製する必要があるため、多くのリソースが必要です。個人的に、フォールバックアプローチを使用します。メインアプリケーションが失敗した場合、または最後の更新が成功しなかった場合、RAMの小さなrootfsが開始されます。何か問題が発生した場合にブートローダーによって自動的に起動されるこのフォールバックシステムは、USBペンからシステムを更新します（ローカル更新が必要な場合）。

これらの問題に関するOSSプロジェクトを見つけたことがなく、以前の経験に基づいて、最近新しいプロジェクトを開始しました。いくつかの製品を実行していますが、顧客は満足しています。

多分あなたはそれを見ることができます。 ＆quot; swupdate＆quot;のソースを見つけることができます。 （プロジェクトの名前） github.com/sbabic/swupdate 。

ステファノ

Answer 5

ここで達成しようとしているのは、更新プロセスの原子性だと思います。組み込みデバイスにとって原子性は非常に重要です。強調されている理由の1つは電力損失です。しかし、ハードウェア/ネットワークの問題のような他のものがあるかもしれません。更新のコンテキストで原子性に使用する定義は次のとおりです。

• 更新は常に完全に完了するか、まったく完了しません
• アップデーター以外のソフトウェアコンポーネントには、半分インストールされたアップデートが表示されることはありません

Embedded Linuxには、更新する必要のあるいくつかのソフトウェアコンポーネントと、選択するさまざまなデザインがあります。これに関する論文がここにあります： https：// mender .io / user / pages / 04.resources / _white-papers / Software％20Updates.pdf