更新、ロールバック、リセット

これらのコマンドは、IronFlockOS を実行するデバイスを管理します。os update はリリースをインストールし、os rollback は以前に動作していたリリースに戻し、os reset はデバイスを書き込んだばかりの状態に戻します。

ルートスロットとデータパーティション

IronFlockOS デバイスのディスクには、次のものがあります：

• 2 つのルートスロット A と B — それぞれに完全な IronFlockOS システムが入ります。一方が動作します。もう一方には以前に動作していたシステムが入っているか、書き込んだばかりのデバイスではまだ何も入っていません。IronFlockOS が使う更新ツールである RAUC は、動作していないスロットにリリースを書き込み、次にどのスロットから起動するかを記録します。
• データパーティション（/data） — アプリとそのデータ、そしてデバイスエージェントとそのデバイス設定ファイル（.flock）のコピー。両方のシステムがこれを使うため、更新やロールバックの後もアプリとそのデータはそのまま残ります。
• IRONFLOCKOS パーティション（/boot/efi にマウント） — 小さな FAT パーティション。デバイスは起動時にここで見つけた .flock ファイルで登録され、os reset はここに要求を書き込みます。

新しいシステムは、正常であることを示す必要があります。デバイスエージェントがそのシステムから IronFlock に到達し、good とマークした時点で、デバイスはそのシステムを使い続けます。起動しないシステム、またはそこまで到達しないシステムからは、次の再起動時に、以前に動作していたシステムに戻ります。ironflock status はスロットを表示します：

System:        IronFlockOS 0.13.0 (amd64-efi, base)
  Image:       ironflockos-amd64-efi-base (build 20261105T120000Z-g1a2b3c4)
  Slot A:      inactive, good
  Slot B:      booted, good, 0.13.0 installed 2026-11-05T14:00:00Z
  Next boot:   slot B

コマンドの実行場所

3 つのコマンドは、IronFlockOS を実行するデバイス上で動作し、root が必要で、実行する前に質問します。ほかのシステム（macOS、IronFlockOS ではない Linux、IronFlockOS のインストーラースティック）では、終了コード 3 で終了します。

• デバイス上で — 0.15.0 より後の IronFlockOS リリースは ironflock を備えています。デバイスにログインし、sudo を付けてコマンドを実行します。
• 別のコンピューターから — 0.15.0 以前の IronFlockOS リリースは ironflock を備えていません。Linux または macOS のコンピューターから、--host を付けて、デバイスの SSH ユーザーとしてコマンドを実行します。SSH ユーザーとは、.flock ファイルがプロジェクトオーナー用にセットアップするアカウントで、例では operator です。--host は実行のために ironflock をデバイスにコピーし、そこで sudo を通してコマンドを実行します。

ironflock --host operator@kitchen-pc os update --reboot --yes

os update と os rollback は、--yes を指定すれば複数のデバイスで同時に実行できます（--host を複数回、または --hosts を指定）。os reset は一度に 1 台のデバイスでしか実行できず、複数のデバイスでは終了コード 2 で終了します。グローバルフラグは フラグ、出力、終了コード に記載しています。

ironflock os update

デバイスのチャネルが提供する IronFlockOS のリリースを、動作していないルートスロットにインストールします。新しいシステムは次の再起動で起動します。--reboot を付けるとすぐに起動します。

ironflock os update [flags]

デバイスのチャネルは、そのデバイスエージェントが従うチャネルで、エージェントの .flock ファイルの environment から決まります。IronFlock のテストプラットフォームでは test、それ以外では production です。カタログにデバイスのチャネルがない場合は production です。ダウンロードベースは --download-base、次に IRONFLOCK_DL_BASE、次にエージェントの .flock ファイルの更新サーバー（update_url）から取得され（IronFlock アプライアンスのデバイスでは、アプライアンスのダウンロードミラーです。そのようなデバイスが到達できるのはそこだけです）、どれもなければ IronFlock クラウドです。

次の順序で動作します：

1. 署名付きの IronFlockOS カタログを読み取り、チャネルのリリース（または --version のリリース）にある、デバイスのイメージ用の更新バンドルを選びます。
2. どのリリースがどのスロットで動作しているか、どのリリースをどのスロットにインストールするか、そのスロットに現在何があるか、ダウンロードのサイズを示します。その後、質問します。
3. バンドルを、データパーティション上の /var/cache/ironflockos にダウンロードします。中断されたダウンロードは再開されます。ファイルは、そのサイズと SHA-256 がカタログと一致する場合にだけ使われます。
4. RAUC に、動作していないスロットへバンドルをインストールさせます。RAUC はバンドルの署名を検証し、スロットに書き込み、そのスロットを次に起動するスロットにします。スロットに以前あった内容は上書きされます。バンドルはインストール後に削除されます。
5. --reboot を付けた場合は、デバイスを再起動して新しいシステムに切り替えます。

実行中のシステムは、再起動までそのままです。アプリとそのデータは残ります。現在動作しているスロットはそのリリースを保持し、新しいリリースが起動しない場合や IronFlock に到達しない場合、デバイスはそのスロットに戻ります。

デバイスがすでにそのリリースを実行している場合、およびそのリリースがすでにもう一方のスロットにインストールされていて再起動を待っている場合は、何もインストールされず、終了コードは 0 です。後者の場合、--reboot は質問してデバイスを再起動します。

# デバイスのチャネルのリリースをインストールする。次の再起動で起動する
sudo ironflock os update
# インストールし、質問なしで再起動して切り替える
sudo ironflock os update --reboot --yes
# カタログにある古いリリースをインストールする
sudo ironflock os update --version 0.13.0

進捗は stderr に出力されます。ダウンロードとそのチェック、続いて RAUC が示す各手順です。スロット A で 0.13.0 を実行しているデバイスで、os update --yes は次のように出力します：

Download base: https://instance-registry.ironflock.com/dl (from default)
IronFlockOS catalog of 2026-11-20T09:00:00Z, signed with key 036ef3bd: production 0.14.0, test 0.14.0.
This device runs IronFlockOS 0.13.0 (ironflockos-amd64-efi-base) from slot A.
IronFlockOS 0.14.0, the release of the production channel, is installed into slot B, which holds nothing yet:
  - the bundle (580.2 MB) is downloaded into /var/cache/ironflockos
  - RAUC checks its signature and writes it into slot B
  - it starts with the next restart
Slot A keeps IronFlockOS 0.13.0: the device goes back to it when 0.14.0 does not start or does not reach IronFlock. Apps and their data stay.
Downloading: 0% (0 B of 580.2 MB)
...
Installing IronFlockOS 0.14.0 into slot B.
Installing:   0% Installing
...
Installing:  82% Copying image to rootfs.1
...
Installing: 100% Installing done.
IronFlockOS 0.14.0, the release of the production channel, is installed in slot B and starts with the next restart ('sudo reboot').

--json では、インストールは進捗のフェーズ installing としてパーセントで示されます。os update --reboot --yes --json の結果：

{"action":"installed","image":"ironflockos-amd64-efi-base","channel":"production","version":"0.14.0","running_version":"0.13.0","slot":"B","up_to_date":false,"reboot":true}

拒否する場合（終了コード 3）：

• root で実行されていない、IronFlockOS を実行していないマシンで実行された、インストーラースティック上で実行された。
• RAUC がすでにバンドルをインストールしている。IronFlock Studio がエージェント経由で開始したもの、または別の呼び出しによるものです。RAUC は一度に 1 つしかインストールしません。
• リリースに、デバイスのイメージ用のバンドルがない。
• リリースが動作中のものより古い。ただし、--version で指定した場合を除きます。もう一方のスロットにそのリリースがある場合、メッセージは os rollback を示します。
• /var/cache/ironflockos に、これからダウンロードする分の空き容量がない。メッセージにはフォルダー内にある以前の更新のバンドルが一覧表示され、それらは削除できます。

コマンドラインの誤り（終了コード 2）：--channel と --version の同時指定、バージョンとして正しくない値、カタログにないチャネルまたはリリース。

失敗する場合（終了コード 1）：カタログを検証できない、または読み取れない。ダウンロードが途中で切れた（届いた分は /var/cache/ironflockos に残り、同じコマンドで再開されます）。ダウンロードしたものがカタログのファイルではない。RAUC がバンドルを拒否した、またはインストールに失敗した。エラーには RAUC の理由が示されます。RAUC が書き込みを始めていた場合、スロットは bad とマークされて使えるシステムを含まず、デバイスは実行中のシステムを引き続き起動します。バンドルは次の試行のためにキャッシュに残ります。

ダウンロード中またはその直後の Ctrl-C は、何かをインストールまたは再起動する前に、終了コード 130 でコマンドを終了させます。同じコマンドでダウンロードを再開できます。質問に「いいえ」と答えた場合は、終了コード 4 で終了します。

ironflock os rollback

もう一方のルートスロットを起動するスロットにし、デバイスを再起動してそのスロットに切り替えます。つまり、最後の更新の前に動作していたシステムに戻ります。起動はするが正しく動作しないシステムに使います。起動しないシステム、または IronFlock に到達しないシステムからは、次の再起動時に IronFlockOS 自身が以前のシステムに戻します。

ironflock os rollback [flags]

このコマンドに固有のフラグはありません。コマンドは常にデバイスを再起動します。再起動しないロールバックは、次の再起動まで何も変えないためです。

対象になるのは、このデバイス上でシステムが起動したことのあるスロットだけです：

• 動作中に good とマークされ、その後再び試されていないシステムのスロット。試されたが一度も good とマークされなかったスロットは対象になりません。
• デバイスに書き込まれたスロット（A）。ただし、そこに何もインストールされておらず、bad とマークされていない場合に限ります。

両方のシステムが同じデータパーティションを使うため、アプリとそのデータは残ります。動作していたスロットはそのリリースを保持します。再起動後、古い方のシステムは再び正常であることを示す必要があります。デバイスエージェントがそのシステムから IronFlock に到達した時点で、デバイスはそのシステムを使い続けます。UEFI マシンでは、以前にそれを示したことのあるスロットは、2 分間動作した時点でも維持されます。それまでは、再起動で新しい方のシステムに戻ることがあります。IronFlock Studio はチャネルのリリースを再び提供し、os update がそれをインストールします。

# 質問の後、もう一方のスロットのシステムに戻す
sudo ironflock os rollback
# 質問なしで
sudo ironflock os rollback --yes

スロット B で 0.14.0 を実行しているデバイスで、os rollback --yes は次のように出力します：

This device runs IronFlockOS 0.14.0 from slot B.
Slot A holds IronFlockOS 0.13.0, which ran on this device before. The rollback makes slot A the one that starts and restarts the device now.
Slot B keeps IronFlockOS 0.14.0. Apps and their data stay: both systems use the same data partition.
The device keeps IronFlockOS 0.13.0 once it has proven itself again (the device agent reaches IronFlock from it); until then a restart can bring back 0.14.0.
Rolled back to IronFlockOS 0.13.0 in slot A: the device restarts now.

--json では、slot と version は起動するスロットとそのリリース（読み取れない場合は空）、from_slot と from_version は動作していたシステムです：

{"action":"rolled_back","slot":"A","version":"0.13.0","from_slot":"B","from_version":"0.14.0"}

拒否する場合（終了コード 3）。理由を示します：

• root で実行されていない、IronFlockOS を実行していないマシンで実行された、インストーラースティック上で実行された、RAUC がバンドルをインストールしている最中である。
• デバイスに、コマンドが知らないブートローダーがある。コマンドが知っているのは GRUB（UEFI マシン）と Raspberry Pi のブートローダーです。
• もう一方のスロットにまだ何もない（書き込んだばかりのデバイス）、試されたが good とマークされなかったシステムがある、インストールが完了しなかったため使えるシステムがない、または bad とマークされている。
• インストールされた更新、または再起動しなかったロールバックの後で、もう一方のスロットが次の再起動を待っている。sudo reboot でそのスロットを起動し、sudo rauc status mark-bad other で破棄します。

失敗する場合（終了コード 1）：RAUC がスロットを起動するスロットにできない（何も変更されていません）。再起動が失敗した（その場合、スロットは次の再起動で起動します）。質問に「いいえ」と答えた場合は、終了コード 4 で終了します。

ironflock os reset

IronFlockOS のファクトリーリセットを要求し、デバイスを再起動します。次回の起動時に、デバイスは所有者、アプリ、登録が残したものを消去し、書き込んだばかりのデバイスとして起動します。-c を付けると、新しい .flock ファイルのデバイスとして登録されます。

ironflock os reset [-c <new.flock>] [flags]

IronFlockOS 0.15.0 は、ファクトリーリセットを備えた最初のリリースです。それより古いリリースではコマンドは拒否されます。os update でより新しいリリースをインストールしてください。

リセットは、データパーティションと両方のルートスロットで、次のものを消去します：

• アプリとそのデータ、Docker のコンテナ、イメージ、ボリューム。
• IronFlock におけるデバイスの ID：デバイスエージェントとその .flock ファイルのコピー、そのデータベースとサービス。ホスト名は ironflockos に戻り、マシン ID は新たに生成されます。
• SSH ユーザーとそのほかのすべてのユーザーアカウント、そのホームフォルダーと sudo のルール。
• ログ、SSH ホスト鍵、ダウンロードした更新、リアルタイムチューニング。
• --keep-network なしの場合：ネットワークプロファイル（WiFi を含む）、プロキシ設定（proxy.conf）、PTP 設定（ptp.conf）。

ルートスロットにある IronFlockOS システム（実行中のシステムと、もう一方のスロットにシステムがあればそのシステム）と、それらについての RAUC の記録は保持されるため、更新とロールバックはこれまでどおり機能します。--keep-network を付けると、上記のネットワーク設定も保持されます。パッケージや /etc 内のファイルなど、システム自体に手動で加えた変更は元に戻しません。それを元に戻すには、os flash で IronFlockOS をディスクにあらためて書き込みます。

次の順序で動作します：

1. デバイスが要求どおりに実行できないもの（下記）を拒否し、-c の .flock ファイルをチェックします。5 MiB 以下の *.flock という名前のファイルで、secret と device_key を持ち、name と serial_number が単純な名前である JSON オブジェクトである必要があります。
2. 何が消去され、何が残り、デバイスがどのように戻ってくるか、最後のリセットがどうなったかを stderr に示し、デバイスの名前を入力するよう求めます。この名前は、ironflock status が表示する、エージェントの .flock ファイルにある名前、または登録されていないデバイスではホスト名です。それ以外の入力は、Enter だけの場合も含めて「いいえ」の回答になります。
3. デバイス自身のチェックが要求を受け付けた後、IRONFLOCKOS パーティションに要求を書き込みます。すでにある要求は置き換えられます。この要求は、独自に 3 回の試行を持つ新しい要求です。
4. -c を付けた場合は、デバイスは最も新しい .flock ファイルで登録されるため、パーティションからほかのすべての .flock ファイルを削除し、新しい .flock ファイルをそこに書き込みます。これが失敗した場合、要求は再び削除されます。
5. デバイスを再起動します。次回の起動時に、デバイスは数秒（低速な SD カードでは数分）で自身をリセットし、もう一度再起動して、新しい SSH ホスト鍵を持つ書き込んだばかりのデバイスとして起動します。

リセット後、-c を付けた場合は、デバイスはその .flock ファイルのデバイスとして登録され、その SSH ユーザーとして SSH で接続できます。-c を付けない場合は、IRONFLOCKOS パーティション上の .flock ファイルを待ち、コンソールからしか操作できません。SSH ユーザーも IronFlock への接続もありません。デバイスへの SSH 接続は、--host のものも含めて再起動で切れます。-c を付けない場合、接続は戻りません。

注意：デバイスにネットワーク経由でしか到達できない場合は、-c で新しい .flock ファイルを指定してください。指定しないと、デバイスをオンラインに戻すために、誰かがデバイスの前で作業する必要があります。

失敗した試行ではデバイスは再起動しません。デバイスはそのままの状態で起動し、人による起動か更新による起動かにかかわらず、次回の起動時に再試行します。3 回失敗するとリセットは断念され、デバイスはその時点の状態で起動します。古いデータが残っていれば、デバイスは古い ID のままオンラインで以前と同じデバイスとして動作し、要求とともに置かれた .flock ファイルとプロキシ設定は削除されます。完了したか断念された要求が再び実行されることは、どのスロットでも、どの更新の後でもありません。応答しないディスクでは、1 回の試行に最大 25 分かかることがあります。失敗したリセットや断念されたリセットは、ironflock status の Last reset: の行に表示されます。

質問の前に、コマンドはデバイスが記録した最後のリセットを示します：

# デバイスをリセットする。その後、デバイスは .flock ファイルを待つ
sudo ironflock os reset
# リセットし、new-device.flock のデバイスにする
sudo ironflock os reset -c new-device.flock
# 質問なしで、ネットワーク設定を保持する
sudo ironflock os reset --keep-network --yes
# 別のコンピューターから、IronFlockOS 0.15.0 で
ironflock --host operator@edge-01 os reset -c new-device.flock

最後のリセットが断念されたデバイス edge-01 で、質問に名前を入力した場合、os reset -c kitchen-pi.flock は次のように出力します：

This device runs IronFlockOS 0.15.0 from slot B and is the IronFlock device edge-01.
The last factory reset of this device: gave up after 3 attempts at 2026-11-11T09:00:00Z: the data partition is not the partition named data on the disk of the root slot; /data holds the old data; left of the old owner: the data partition, the booted root slot, the other root slot; the device stayed the device it was, online with its old identity, and the .flock and proxy.conf that came with the request were removed.
What can be done: request the reset again, as this command does now, with three new attempts; or write IronFlockOS to the device's disk anew ('ironflock os flash'), which clears everything.
The factory reset restarts the device now. During the next boot the device resets itself, in seconds (minutes on a slow SD card), and restarts once more. It clears:
  - the apps with their data, and Docker's containers, images and volumes
  - the device's identity at IronFlock: the agent with its copy of the .flock and its database; the hostname goes back to ironflockos
  - the SSH user and every other user account, with their home folders
  - the logs, the SSH host keys and the downloaded updates
  - the network profiles (the WiFi among them), the proxy setting and the PTP setting
It keeps IronFlockOS 0.15.0 in slot B, which runs, and IronFlockOS 0.14.0 in slot A, so updates and rollbacks work as before.
It does not undo what was changed by hand in the system itself, such as a package or a file in /etc.
Then the device starts as a freshly written one with kitchen-pi.flock, which goes onto its IRONFLOCKOS partition: it enrolls as kitchen-pi and can be reached over SSH as operator, with the device key of that .flock and new SSH host keys.
An attempt that fails does not restart the device: it comes up as it is, and its next start tries again; after three failed attempts the reset gives up, and the device starts with what is there. 'ironflock status' shows a failed or given-up reset.
An SSH connection to the device, also the one of --host, ends with the restart.
? Type the device's name, edge-01, to reset it: edge-01
Factory reset requested: the device restarts now, resets itself and enrolls as kitchen-pi.

os reset --keep-network --yes --json の結果：

{"action":"reset","device":"edge-01","keep_network":true}

拒否する場合（終了コード 3）。理由と対処方法を示します：

• root で実行されていない、IronFlockOS を実行していないマシンで実行された、インストーラースティック上で実行された、RAUC がバンドルをインストールしている最中である。
• その IronFlockOS にファクトリーリセットがない。より新しいリリースが備えており、os update でインストールできます。
• /boot/efi がマウントされた IRONFLOCKOS パーティションではない。そこに何もマウントされていない、または FAT 以外のファイルシステムがマウントされている。
• リセットが開始している。リセットは次回の起動時に続行され、それまでは何も変更すべきではありません。メッセージには最後の試行が示されます。
• -c なしで、IRONFLOCKOS パーティション上に .flock ファイルがある。リセット後、デバイスは .flock ファイルを待たずに、そのファイルで登録されてしまいます。
• 次回の起動が、good とマークされた実行中のシステムにならない。更新またはロールバックが再起動を待っている場合は、sudo reboot でそれを起動し、sudo rauc status mark-bad other で破棄します。実行中のシステムがまだ good とマークされていない場合は、sudo rauc status mark-good で維持するか、os rollback で戻ります。
• デバイス自身のチェックが要求を受け付けない。何も要求されず、メッセージにはデバイスの理由が示されます。

失敗する場合（終了コード 1）：

• マウントテーブルを読み取れないため、/boot/efi が IRONFLOCKOS パーティションかどうかを判断できない。何も書き込まれません。
• -c の .flock ファイルが有効なものでない。
• 要求または .flock ファイルを書き込めない、またはほかの .flock ファイルを削除できない。要求は取り消され、エラーは何が削除されたかを示します。
• 再起動が失敗した。その場合、デバイスは次回の起動時に自身をリセットします。/boot/efi/factory-reset.conf と .flock ファイルを IRONFLOCKOS パーティションから削除すると、リセットは取り消されます。

コマンドが要求を書き込んでいる間の Ctrl-C、SIGTERM、SSH セッションの喪失は、コマンドに要求を取り消させます。コマンドは終了コード 130 で終了し、デバイスは再起動しません。質問で名前を誤って入力すると、終了コード 4 で終了します。

すべてのコマンドの終了コードは、フラグ、出力、終了コード で説明しています。--host 経由では、終了コード 255 は SSH 接続が失敗したことを意味します。