14

Alix 2d13 を使用して Linux ベースのアプライアンスを開発しています。

イメージ ファイルの作成、パーティションの作成、ブート ローダー (syslinux)、カーネル、initrd のインストールを処理し、ルート ファイルシステム ファイルを適切なパーティションに配置するスクリプトを開発しました。

構成ファイルは tmpfs ファイルシステム上にあり、独自のパーティションに存在する XML ファイルを読み取るソフトウェアによって、システムの起動時に作成されます。

ファイルシステムを更新する方法を探していて、2 つの解決策を検討しました。

  • ファームウェアの更新は、カーネル、initrd、および/または rootfs パーティションを含む圧縮ファイルです。このように、再起動時に、initrd は rootfs イメージを適切なパーティションに追加するように注意します。
  • ファームウェア アップデートは圧縮ファイルで、1 つはブート用、もう 1 つはルート ファイルシステム用の 2 つの tar アーカイブを含むことができます。

すべてのソリューションには独自の利点があります。-アーカイブは小さく、更新に必要な時間は短くなりますが、ルートファイルシステムにcaosを短時間で配置できます。

別の解決策として、ファイル リストを配置し、更新前/更新後のスクリプトを tar アーカイブに配置して、ファイル リストに存在しないファイルを削除することもできます。

どう思いますか？

4

3 に答える 3

18

私は次のアプローチを使用しました。これは、論文「Building Murphy-compatible embedded Linux systems」 (ここで入手可能) に多少基づいています。私はcfgshのものではなく、その論文で説明されているversions.confのものを使用しました。

  • 「メイン」ルート ファイル システムをループバック マウントすることをジョブとするブート カーネルを使用します。新しいカーネルが必要な場合は、ループバック マウントした直後に新しいカーネルに kexec を実行します。ブート カーネルの完全な init を、busybox と kexec (両方とも静的にリンク) と共に initramfs に入れることにしました。私の init は、私が書いた単純なシェル スクリプトでした。
  • 1 つまたは複数の「メイン OS」ルート ファイル システムが、「OS イメージ」ファイル システム上にディスク イメージ ファイルとして存在します。ブート カーネルは、versions.conf ファイルに基づいてこれらのいずれかを選択します。現在のファイルとフォールバック ファイルの 2 つの主要な OS イメージ ファイルのみを維持しています。現在のものに障害が発生した場合 (障害検出については後で詳しく説明します)、ブート カーネルはフォールバックを起動します。両方が失敗するか、フォールバックがない場合は、ブート カーネルがシェルを提供します。
  • システム構成は別のパーティションにあります。これは通常アップグレードされませんが、アップグレードできない理由はありません。
  • 合計 4 つのパーティションがあります: ブート、OS イメージ、構成、およびデータ。データ パーティションは、頻繁な書き込みを目的としたユーザー アプリケーション用のものです。ブートが読み取り/書き込みでマウントされることはありません。OS イメージは、アップグレード中に読み取り/書き込みのみ (再) マウントされます。config は、構成を変更する必要がある場合にのみ読み取り/書き込みでマウントされます (できれば決して変更しないでください)。データは常に読み取り/書き込みでマウントされます。
  • 各ディスク イメージ ファイルには、カーネル、init スクリプト、ユーザー プログラム (busybox、製品アプリケーションなど)、および初回起動時に構成パーティションにコピーされるデフォルト構成を含む、完全な Linux システムが含まれています。ファイルは、すべてを収めるのに必要なサイズです。OS イメージ パーティションが常に 3 つのメイン OS イメージ ファイルを収めるのに十分な大きさになるように、拡張に十分な余裕がある限り (アップグレード中は、新しいフォールバックが抽出されるまで古いフォールバックを削除しません)、私はできます。メイン OS イメージが必要に応じて拡大できるようにします。これらのイメージ ファイルは常に (ループバック) 読み取り専用でマウントされます。これらのファイルを使用すると、rootfs 内の個々のファイルをアップグレードする際の失敗に対処する手間も省けます。
  • アップグレードは、自己解凍型 tarball を tmpfs に転送することによって行われます。このスクリプトの最初は、読み取り/書き込み可能な OS イメージを再マウントし、新しいメイン OS イメージを OS イメージ ファイル システムに抽出してから、versions.conf ファイルを更新します (「murphy」論文で説明されている名前変更方法を使用)。これが完了したら、アップグレードが行われたことを示すスタンプ ファイルに触れてから、再起動します。
  • ブート カーネルは、このスタンプ ファイルを探します。見つかった場合は、それを別のスタンプ ファイルに移動し、新しいメイン OS イメージ ファイルを起動します。メイン OS イメージ ファイルは、正常に起動したときにスタンプ ファイルを削除する必要があります。そうでない場合は、ウォッチドッグが再起動をトリガーし、ブート カーネルがこれを確認して障害を検出します。
  • アップグレード中にいくつかの障害が発生する可能性があることに注意してください: アップグレード中の versions.conf の同期、およびスタンプ ファイルの変更/削除 (3 つのインスタンス)。これらをさらに削減し、私が望むすべてを達成する方法を見つけることができませんでした. 誰かがより良い提案を持っているなら、私はそれを聞きたい. OS イメージの書き込み中にファイル システム エラーや電源障害が発生する可能性もありますが、その場合でも ext3 ファイル システムが何らかの問題を解決してくれることを願っています。
于 2013-08-13T21:52:19.440 に答える
1

更新用に別のパーティションを作成できます (たとえば、Side1/Side2)。既存のカーネルである rootfs は Side1 にあり、Side2 に更新を入れて切り替えます。これにより、ウェアレベリングを減らして寿命を延ばすことができますが、デバイスのコストが高くなります。

于 2013-08-07T16:27:28.810 に答える
0

tarファイルを抽出する前にパーティションをすばやくフォーマットできます。または、イメージソリューションを使用しますが、可能な限り最小のイメージを使用し、ddの後にファイルシステムのサイズ変更を行います（ただし、読み取り専用ストレージには必要ありません）。

于 2011-03-10T22:54:49.790 に答える