組み込みLinux OTAアップデート 第1部：基礎と実装

アップデートの必要性

組み込みLinux製品がラボを離れフィールドへ出荷されると、それが如何にアップデートを受け取るかが重要な設計決定になります。

完璧なアプリケーションであれば変更不要に見えますが、現実にはソフトウェアは必ずバグを抱え、ネットワークやインターネットに接続するデバイスではセキュリティパッチが避けられません。理論的に完璧なファームウェアであっても、サードパーティライブラリの脆弱性に対応しなければなりません。

Heartbleed脆弱性（CVE-2014-0160）がOpenSSL暗号ライブラリを露見させた事例を考えてみてください。この欠陥は全ウェブサイトの約3分の2に影響し、今日でも無数の組み込みLinuxデバイスが未パッチのOpenSSLビルドを搭載したまま出荷され、悪用のリスクに晒されています。

ブロックベース vs ファイルベースのアップデート

Linuxのアップデートメカニズムは大別するとブロックベースとファイルベースに分類されます。ブロックアップデートはパーティションまたはブロックデバイス全体を1回のアトミック操作で上書きし、ファイルアップデートは個々のファイルやパッケージを置き換えます（デスクトップ/サーバの「apt-get upgrade」と同様）。

組み込みLinuxではブロックベースアップグレードが好まれます。ファイルシステム全体が単一ビルドパイプラインで生成され、製品のストレージフットプリントが固定されているためです。パーティション全体を1ステップで更新すると、ロールバックもシンプルになります：前のイメージコピーを新しいものが検証されるまで保持できます。

失敗したアップデート後のリカバリ確保

電源喪失や書き込み失敗でデバイスが使用不能状態になることは許されません。一般的な対策は、プライマリイメージのブート失敗時に引き継ぐセカンダリパーティションを維持することです。

図1. 失敗時のリカバリ – フォールバックオプション（出典: ByteSnap）

2つの一般的なパターンがあります：

• レスキューパーティション戦略 – ブートローダーが小さなレスキューイメージを起動し、アップデート完了後にメインファームウェアを起動。メインパーティションが大半のストレージを占有可能だが、2回リブート（レスキューへ、次にメインへ）が必要。
• デュアルルートFS戦略 – 2つのフルルートファイルシステムを並列保持。ブートローダーが起動時に切り替え。アップデート適用時、非アクティブイメージを上書きし、1回のリブートで完了。イメージあたりの利用可能スペースは半分になるが、高速リカバリとゼロダウンタイムを実現。

ストレージに余裕があれば、シンプルさと性能でデュアルルートFS方式が通常推奨されます。メインイメージが大きく、複製ルートFSのスペアスペースが限られる場合はレスキューアプローチが有用です。

ブートローダー自体は通常この構成ではイミュータブルです。ブートローダーを更新するには、追加のブートローダーパーティションと、切り替えを調整するボード管理コントローラ（BMC）が必要で、ハードウェア複雑性とコストが増大します。

図2. 失敗時のリカバリ – ボード管理コントローラ（出典: ByteSnap）

BMCが追加ハードウェアとファームウェアを必要とするため、ほとんどの設計者はブートローダーを可能な限り小さく信頼性高くし、OTA更新が不要になるようにします。

U-Boot環境変数の活用

U-Bootは不揮発性環境を保持し、Linuxから照会可能でブート中に操作できます。これらの変数は、アクティブパーティションのエンコード、ブート成功の追跡、フェイルオーバーロジックの調整に最適です。

典型的なパターンには：

• 新イメージへ切り替え前にフラグを設定。
• 成功ブートごとに「ブートカウント」変数をインクリメント。
• 設定可能な成功ブート閾値に達したらフラグをリセット。

この状態をU-Bootに保存することで、ブートローダーは新イメージが設定回数ブートに失敗したら自動的に前イメージへロールバックできます。

図3. U-Boot環境変数（出典: ByteSnap）