Linux を IronFlockOS に置き換える

ironflock os install は、稼働中のマシンが起動した Linux を同じディスク上の IronFlockOS に置き換え、マシンをデバイス設定ファイル（.flock）の IronFlock デバイスにします。マシン自体で実行するか、別のコンピューターから SSH 経由で実行します。

警告：マシンが起動したディスク上のすべてが失われます。実行中のシステム、そのパッケージと設定、ユーザーアカウント、すべてのデータです。元に戻す方法はありません。まず --dry-run を付けてコマンドを実行し、計画を読んでください。

使う場面

os install は、Debian、Ubuntu、または systemd を備えたその他の Linux がすでに動作していて、USB スティックから起動できない、または起動したくないマシンに使います。制御盤内の PC、クラウド上の仮想マシン、SSH でしか到達できないマシンなどです。--host を付けると、お使いのコンピューター（Mac も可）からコマンドを実行でき、コマンドはマシンが IronFlock デバイスとしてオンラインになるまで待ちます。

次の場合は、別のコマンドを使います：

• マシンをドライブから起動できる — ironflock os flash は、IronFlockOS を USB スティック、SD カード、外付けディスクに書き込みます。--installer を付けるとインストーラースティックを書き込み、このスティックが、そこから起動した PC の内蔵ディスクに IronFlockOS をインストールします。os install が拒否するマシンのほとんどでも、インストーラースティックが解決策になります。
• マシンが Raspberry Pi である — os install がインストールするのは、UEFI マシン用のイメージ（ターゲット amd64-efi と arm64-efi）だけです。Raspberry Pi の SD カードは os flash で書き込みます。
• マシンですでに IronFlockOS が動作している — os install はこれを拒否します。そこでは ironflock os update が別のリリースをインストールします。
• マシンの Linux を残したい — ironflock agent install は、マシンをそのままの状態で IronFlock に接続します。

ironflock os install

マシンをチェックし、置き換えの計画を示して質問します。その後、IronFlockOS をメモリ上にステージングしてマシンを再起動します。マシンはシャットダウンの最後に IronFlockOS をディスクに書き込み、それを起動します。

ironflock os install [-c <device.flock>] [--disk <disk>] [--dry-run] [flags]

macOS では、コマンドは何かを調べる前に終了コード 3 で終了します。macOS からは --host を付けて実行してください。コマンドは一度に 1 台のマシンでしか実行できません。--host を複数回指定した場合や --hosts を指定した場合は、終了コード 2 で終了します。グローバルフラグは フラグ、出力、終了コード に記載しています。

フラグ

プロキシのフラグは、agent install と同じように機能します。フラグがない場合、コマンドは環境から HTTP_PROXY、HTTPS_PROXY、NO_PROXY を取得します。パスワードを含むプロキシ URL は、コマンドラインの誤り（終了コード 2）です。シークレット を参照してください。

マシンに必要なもの

• システム — Debian や Ubuntu など、systemd が PID 1 である Linux で、コンテナ内ではないこと。IronFlockOS と ReswarmOS は拒否されます。
• ファームウェア — amd64 または arm64 上の 64 ビット UEFI。EFI 変数がマウントされ（efivarfs）、書き込み可能であること。BIOS と 32 ビット UEFI は拒否されます。Secure Boot は有効でもかまいません。Secure Boot を参照してください。
• ディスク — ファームウェアがシステムを起動したディスク。GPT（GUID パーティションテーブル）と 512 バイトの論理セクターを持つ、それ自体で独立したディスク全体であること。ルートファイルシステムは、直接または LVM や LUKS を介して、このディスク上にだけあること。ディスクの容量は、イメージに必要な最小のディスクサイズ以上であること。これはカタログが示すサイズ、なければ 10 GiB、nvidia イメージでは 18 GiB です。
• メモリ — 圧縮されたイメージ、ironflock バイナリ、さらに 512 MiB が収まる利用可能なメモリ（MemAvailable）。base イメージでは、約 2 GiB のマシンです。
• ツール — lsblk と、iproute2 の ip。
• ネットワーク — 新しいシステムが使えるネットワーク経由で、直接またはプロキシを通してダウンロードサーバーに到達できること（新しいシステムが引き継ぐもの）。IronFlock アプライアンスのデバイスでは、アプライアンスのダウンロードミラーでもかまいません（ファイルの取得元）。
• .flock ファイル — -c のもの、またはマシンにインストールされたデバイスエージェントのもの。

ファイルの取得元

コマンドには、署名付きの IronFlockOS カタログ、イメージ、イメージのハードウェアリストが必要です。これらは次の順に取得します：

1. --download-base、なければ IRONFLOCK_DL_BASE：そのサーバーだけから取得します。
2. それもなければ、.flock ファイルが更新サーバーとして指定する IronFlock アプライアンスのダウンロードミラーから取得します。つまり、その update_url が絶対 URL の http または https で、ホストが IronFlock クラウドのものでない場合です。たとえば https://registry.<domain>/dl や http://<host>:<port>/dl です。stderr には Download base: ... (from the device's .flock) と出力されます。アプライアンスには到達できても ironflock.com には到達できないマシンは、この方法で変換します。IronFlock クラウドの .flock ファイルでは、クラウドから取得します。
3. それもなければ、IronFlock クラウド https://instance-registry.ironflock.com/dl から取得します。

アプライアンスのミラーを使う場合、ファイルはまずミラーから取得し、ミラーが提供しないものは IronFlock クラウドから取得します：

• カタログ、<mirror>/ironflockos/manifest.json — その時点でミラーが提供しない場合（到達できない、エラーで応答する、または前回のカタログを保存したコピーで代用するしかない）は、アプライアンスがない場合と同じく、すべてをクラウドから取得します。ミラーが提供したカタログが拒否された場合（署名、保存したコピーより古い、大きすぎる）は、ほかのサーバーと同じくコマンドは失敗します。
• イメージ、<mirror>/ironflockos/<version>/<file> — ミラーが提供しない場合（到達できない、ファイル以外で応答する、または送られてきたものがイメージの先頭ではない）は、署名付きカタログが示す URL から取得します。os flash のキャッシュにあるファイルは、どちらにも問い合わせません。
• ハードウェアリスト、<mirror>/ironflockos/<version>/<image>-<version>.modules.alias.gz — 同じルールで、単独で判断します。

フォールバックのたびに、ミラー、ファイル、理由を示す警告が計画に加わり、--json では warnings に入ります。各ファイルの取得元は計画が 1 回だけ決めます。ステージングは計画の image.url からイメージをダウンロードし、再びフォールバックすることはありません。ミラーからもクラウドからもファイルを取得できない場合、コマンドは失敗し、両方の取得元と両方の理由を示す 1 つのエラーを出します（neither the appliance's mirror ... nor the IronFlock cloud gives ...）。

agent install と同じく、ミラーには直接接続し、クラウドにはプロキシを経由して接続します。アプライアンス独自の CA による証明書を使う HTTPS のミラーは、マシンのシステムがその CA を信頼している場合にだけ使えます。アプライアンスが応答した場合、新しいシステムはアプライアンスに到達したネットワークカードを引き継ぎます（新しいシステムが引き継ぐもの）。

何かを変更する前に

コマンドは、次の順にマシンをチェックします。最初に失敗したチェックで拒否し、終了コード 3 で、原因と（あれば）解決策を示す 1 文を出力します。その時点では何も変更されていません。

1. システム — systemd が PID 1 であり、システムがコンテナではなく、IronFlockOS でも ReswarmOS でもないこと。
2. ファームウェア — 64 ビット UEFI、書き込み可能な EFI 変数、そして Secure Boot が有効な場合は、ファームウェアが起動するイメージのブートチェーン（Secure Boot）。
3. イメージ — os images が一覧表示するのと同じ、署名付きの IronFlockOS カタログから取得します。--image のイメージ、なければマシンのターゲットのベースイメージです。コマンドはイメージファイルの先頭の数 MiB を読み取ります。ファイルが os flash のキャッシュにあればそこから、なければダウンロードサーバーから読み取ります（アプライアンスのミラーが先です。ファイルの取得元 を参照）。別のハードウェア用の .flock ファイルは警告だけになります。
4. ディスク — ファームウェアの現在のブートオプションが示すパーティションを持つディスク。なければ、/boot/efi または /efi にマウントされた EFI システムパーティションを持つディスク。それもなければ、--disk で指定したディスクです。システムが起動したディスクとは別のディスクを指定した --disk は拒否されます。それ自体で独立したディスク全体ではないディスクも拒否されます。MD RAID アレイ（Intel RST が作成するものも含む）、device-mapper、ループデバイス、ネットワークブロックデバイス、メモリ上のディスクです。
5. ディスク上に構築されているもの — パーティション、リニアボリュームの LVM、cryptsetup が暗号化のためにセットアップするもの（LUKS、plain dm-crypt、BitLocker、FileVault、TrueCrypt）。それ以外はすべて拒否されます。MD RAID、bcache、マルチパス、ZFS プール、LVM のシンプール、スナップショット、キャッシュ、RAID とミラー、dm-verity、dm-integrity です。ほかのディスクはそのまま残るため、このディスクと別のディスクの両方にメンバーを持つ btrfs ファイルシステムや LVM ボリュームグループは拒否されます。ディスクを置き換えると、両方のディスク上でそれが壊れるためです。IRONFLOCKOS、rootfs-a、rootfs-b、data という名前のパーティションを持つ別のディスクがあるマシンも拒否されます。IronFlockOS は、これらの名前で自身のパーティションを見つけるためです。
6. メモリ — 上記のとおり。
7. .flock ファイル、ネットワーク、プロキシ、ドライバー — .flock ファイルは os flash と同じように読み取られ、その SSH 鍵は有効なものである必要があります。ネットワークとプロキシは、新しいシステムが引き継ぐもの で説明するとおりにチェックされます。ドライバーについては、コマンドはディスクとネットワークカードに至る経路上のデバイス（ディスク、カード、それらのコントローラーとバス）を取り出し、イメージのハードウェアリストで調べます。拒否するのは、それらのいずれかのドライバーがイメージにないことが、リストからわかる場合だけです。判断できないデバイスは警告 drivers not checked に示されます。ハードウェアリストのないリリース（0.14.0 まで）では、警告はすべてのデバイスを示します。
8. 計画と質問 — 下記を参照してください。

コマンドがイメージの先頭を読み取っている間の Ctrl-C は、終了コード 130 でコマンドを終了させます。計画の表示中や質問の待機中に端末が失われた場合も同じです。その時点では何も変更されていません。

計画と --dry-run

計画は stderr に出力されます。マシンとそのファームウェア、ディスクとその特定方法、イメージとそのファイルの取得元、メモリを示します。ディスク上のすべてが失われること、新しいシステムが引き継ぐものと引き継がないもの、警告も示します。--dry-run は計画を表示し、何も変更せず、終了コード 0 で終了します。--dry-run を付けた場合、--yes に --disk は不要です。

Compute Engine の VM では、計画は Google のゲスト環境がなくなることを警告します。gcloud compute ssh、OS Login、メタデータの SSH 鍵は機能しなくなり、シリアルコンソールは残ります。

新しいシステムが引き継ぐもの

新しいシステムは、次のものを引き継ぎます：

• デバイスの ID — .flock ファイルのもの。このファイルは IRONFLOCKOS パーティションに置かれ、デバイスは初回起動時にこのファイルで登録されます。
• ネットワーク — ダウンロードサーバーまたはプロキシへのイメージのダウンロードに使ったネットワークカードのもの。ダウンロードベースが .flock ファイルのアプライアンスのミラーで、ミラーがカタログの要求に少しでも応答した場合（404 も含む）は、ファイルの取得元にかかわらず、ミラーへの接続に使ったカードになります。新しいデバイスが接続する先はアプライアンスだからです。DHCP の有線接続では何も必要ありません。静的アドレス（有効期限のないアドレス、手動で設定したゲートウェイとルート、systemd-resolved または /etc/resolv.conf の DNS サーバー）は、カードを恒久的な MAC アドレスで照合する NetworkManager プロファイルになります。DHCP または SLAAC と並ぶ静的アドレスは、DHCP を保ったうえで静的アドレスを追加します。WiFi では、.flock ファイルのネットワークであれば何も必要ありません。NetworkManager の WPA-PSK または WPA3-SAE プロファイルを持つ別のネットワークは、非表示かどうかにかかわらず、そのプロファイルを引き継ぎます。ほかのカードのアドレスは引き継がれず、計画が警告します。
• プロキシ — ダウンロードのプロキシが、ユーザーとパスワード、および no_proxy とともに、IronFlockOS のプロキシ設定（IRONFLOCKOS パーティション上の proxy.conf）になります。マシン自体の上のプロキシ（127.0.0.1）は、新しいシステムにはないため拒否されます。マシンのループバックで応答するミラーも同様です。アプライアンス自身のホストのエージェントが持つ、update_url に localhost を指定した .flock ファイルがこれに当たります。proxy.conf が受け付けない文字を含むプロキシ URL は拒否され、拒否の理由にはその部分が示されます。
• SSH — .flock ファイルの鍵を持つプロジェクトオーナーのアカウント。すべての IronFlockOS デバイスと同じです。

IronFlockOS 0.15.0 以降は、IRONFLOCKOS パーティションからネットワークプロファイルとプロキシ設定を取り込みます。それより古いリリースのイメージでは、ネットワークにプロファイルが必要なマシンや、ダウンロードがプロキシを経由するマシンは拒否されます。拒否の理由には、カード、その静的アドレスまたは WiFi、代わりにどうすればよいかが示されます。

新しいシステムは、古いシステムのユーザーアカウントとそのパスワードと SSH 鍵、SSH ホスト鍵（SSH クライアントには新しいホスト鍵が見えます）、パッケージ、設定、データを引き継ぎません。デバイスのアプリは IronFlock から戻りますが、このマシン上のアプリのデータは戻りません。

質問

コマンドは、質問に表示されるマシンの短いホスト名を入力するよう求めます。カーネルが完全な名前を持つマシン（Compute Engine の Ubuntu イメージ）では、完全な名前も受け付けます。それ以外の入力は、Enter だけの場合も含めて「いいえ」の回答となり、終了コード 4 になります。質問と確認 を参照してください。

--yes は、--disk でディスクを指定した場合にだけ質問に答えます。暗号化されたシステムでは、--yes には --allow-unencrypted も必要で、ない場合は終了コード 4 で終了します。端末がない場合や --json では質問できないため、--yes がなければ終了コード 4 で終了します。

質問の後：ステージングと引き渡し

再起動の前に、ディスクには何も書き込まれません。コマンドは置き換えをメモリ上にステージングします：

1. メモリ上のファイルシステムがイメージを受け取ります。計画が os flash のキャッシュからイメージを読み取った場合はそのファイル、それ以外はダウンロード（Downloading と表示）で、署名付きのカタログと照合されます（Checking）。イメージは 1 回展開され（Preparing）、計画が読み取った内容と比較されます。IRONFLOCKOS パーティション用のファイルが準備されます。
2. IronFlockOS のブートオプションが、ファームウェアのブート順序の最後、実行中のシステムのものの後ろに追加されます。ディスクが書き込まれるまでは、実行中のシステムが引き続き先に起動します。
3. stderr の Staged: は、新しいブートオプションと、書き込みの後に削除される古いシステムのブートオプションを示します。
4. コマンドは引き渡しを行います。マシンはすぐに再起動します。コマンドが SSH セッションで実行されている場合（sudo や --host 経由も含む）は、結果が先にセッションに届くよう、コマンドの終了から 10 秒後に再起動します。stdout には Handed over: ... と出力され、コマンドは終了コード 0 で終了します。

質問から引き渡しまでの間の Ctrl-C または SIGTERM は、ステージングを取り消します。コマンドは終了コード 130 で終了し、マシンは元の状態のままです。質問の後は、端末や SSH セッションが失われてもコマンドは止まりません。ステージングは続き、引き渡しと再起動が行われます。再起動が引き渡された後は、Ctrl-C はコマンドを終了させますが、再起動は続行します。

再起動と書き込み

シャットダウンの最後に、ironflock はメモリ上のイメージをディスクに書き込みます。マシンのコンソールには、ironflock-install: で始まる行が表示されます。その後、マシンは IronFlockOS を起動し、約 10 分以内にデバイスが IronFlock に表示されます。書き込みのログは、新しいシステムの IRONFLOCKOS パーティション上の ironflock-install.log です。

古いシステムが再び起動する場合

書き込む前に、ironflock はディスクをもう一度チェックします。条件が満たされない場合、古いシステムが変更されないまま再び起動します。ディスクが使用中または読み取り専用である、計画のディスクではない、ステージングしたイメージが破損している、または書き込み前の手順に 2 分以上かかった場合です。理由は EFI 変数 IronFlockInstall に記録されます。ironflock status は、root なしで、その OS install: の行にこれを表示します：

System:        Debian GNU/Linux 13 (trixie)
  OS install:  'ironflock os install' stopped at 2026-11-11T10:00:00Z before it wrote the disk: the disk /dev/sda is not the plan's: its size changed from 64.0 GB to 32.0 GB; nothing was changed, and this system runs as before

# マシン上で
ironflock status
# 別のコンピューターから
ironflock --host admin@machine status
# ironflock なしで：ステージ、時刻、理由を表示する
tail -c +5 /sys/firmware/efi/efivars/IronFlockInstall-7b2f7cb6-eb8f-4acd-b7fd-e92df1a035a0

--host 経由

ironflock --host admin@machine os install -c device.flock --disk /dev/sda --yes は、--host 経由のすべてのコマンドと同じように、そのマシン上でコマンドを実行します。バイナリと .flock ファイルがマシンに送られ、チェック、計画、質問はマシン上で実行され、その出力が返ってきます。バイナリと .flock ファイルのコピーを含むフォルダーは、マシン上のコマンドが終了すると削除されます。拒否や割り込みの後も同様です。--dry-run は、そのフォルダー以外、マシン上で何も変更しません。

再起動はコマンドの終了から 10 秒後に行われるため、結果は先にこちら側に届きます。質問の後は、接続が切れてもマシン上のコマンドは止まりません。接続が切れると、こちら側のコマンドは終了コード 255 で終了し、マシンが単独で処理を続けることを示します。

引き渡しの後、コマンドは最大 15 分間、マシンが IronFlockOS として戻ってくるのを待ちます：

• 15 秒ごとに、同じアドレスに .flock ファイルの SSH ユーザーとして、.flock ファイルの鍵でログインします。鍵は、お使いのユーザーだけが読める新しいフォルダー内のファイルに置かれ、待機が終わるとフォルダーは削除されます。鍵は SSH エージェントには追加されません。
• 新しいシステムのホスト鍵を、どこにも書き込まずに受け入れます。known_hosts はそのままです。
• システムが何を実行しているか、起動後にデバイスエージェントが IronFlock に接続したかどうかを読み取ります。
• その間、known_hosts にあるホスト鍵の場合に限り、古いシステムに EFI 変数 IronFlockInstall を問い合わせます。古いシステムで戻ってきたマシンがあれば、待機はすぐに終了します。

マシンで IronFlockOS が動作し、デバイスエージェントが接続している場合、待機は終了コード 0 で終了します。マシンで IronFlockOS が動作しているがエージェントが接続していない、古いシステムで戻ってきた、または 15 分以内に IronFlockOS として応答しなかった場合は 1 で終了します。DHCP によってアドレスが変わった場合、このチェックは機能しません。その場合、メッセージは IronFlock 上のデバイスとマシンのコンソールを確認するよう示します。Ctrl-C は 130 で待機を終了させ、マシンは単独で処理を続けます。

新しいシステムのホスト鍵はこちら側にとって新しいものであるため、待機では、そのアドレスでどのマシンが応答しているかを判別できません。証拠となるのは、IronFlock 上で接続済みと表示されるデバイスです。

待機には、こちら側に .flock ファイルが必要です。-c がない場合、または SSH ユーザーをセットアップしない .flock ファイルの場合は、--no-wait を指定しない限り、マシンに何かを送る前に終了コード 2 で終了します。--no-wait は引き渡しを行い、マシン上のコマンドの終了コードで終了します。

Secure Boot

Secure Boot が有効な場合、コマンドは、ファームウェアがイメージのブートチェーン（shim、次に GRUB）を起動することをチェックします：

• イメージの shim の署名が、付属の証明書を介して、ファームウェアの署名データベース（db）にある証明書までチェーンでつながり、禁止データベース（dbx）がそのいずれも失効させていないこと。または、db に shim のハッシュが記載されていること。
• dbx も、このマシン上の shim の禁止リスト（MokListX）も、イメージの shim や GRUB、または GRUB の署名に使われた証明書を記載していないこと。
• マシンの SBAT レベル（SbatLevelRT）が、shim も GRUB も失効させていないこと。

ファームウェアがイメージを起動しない場合、コマンドは拒否します。ファームウェアのセットアップで Secure Boot を無効にできます。IronFlockOS は Secure Boot なしでも起動します。shim を経由して起動しなかったシステムでは、計画は SBAT レベルと MokListX をチェックしていないことを警告します。コマンドは shim の署名値を検証せず、カーネルも調べません。署名付きのカタログがそれらを保証します。--json では、machine.secure_boot.ca が、shim の署名がチェーンでつながる db 内の証明書（Microsoft UEFI CA 2023 など）を示します。

例

# インストール済みのエージェントのデバイスの計画を表示し、何も変更しない
sudo ironflock os install --dry-run
# 新しいデバイスの計画を JSON で
sudo ironflock os install -c device.flock --dry-run --json
# 質問なしでシステムを置き換える
sudo ironflock os install -c device.flock --disk /dev/sda --yes
# 別のコンピューターから実行し、デバイスがオンラインになるまで待つ
ironflock --host admin@machine os install -c device.flock --disk /dev/sda --yes

結果

sudo ironflock os install -c device.flock --dry-run の計画（stderr）：

IronFlockOS catalog of 2026-11-20T09:00:00Z, signed with key 036ef3bd.
Machine:      debian-vm, Debian GNU/Linux 13 (trixie), amd64, UEFI without Secure Boot
Disk:         /dev/sda: Google PersistentDisk, 21.5 GB, serial persistent-disk-0 (the EFI system partition at /boot/efi is on it); it holds plain partitions
Image:        ironflockos-amd64-efi-base 0.15.0, 4.6 GB unpacked
Image file:   https://instance-registry.ironflock.com/dl/ironflockos/0.15.0/ironflockos-amd64-efi-base-0.15.0.img.gz (662.9 MB), downloaded into memory and checked against the catalog
Memory:       1.7 GB available, 1.2 GB needed
Everything on /dev/sda is lost: this system, its packages and settings, and all data. There is no way back.
The new system gets:
  - the identity of the device kitchen-pc, from device.flock
  - the network: ens4 by cable with DHCP, which needs nothing carried over
  - SSH: the account operator with the .flock's key, as every IronFlockOS device has it
It does not get:
  - the user accounts of this system, their passwords and SSH keys
  - the SSH host keys: clients see a new host key
  - the packages, settings and data of this system: the device's apps come back from IronFlock, their data on this machine does not
Then the machine restarts, writes IronFlockOS from memory at the end of its shutdown and starts it; the device appears in IronFlock within about ten minutes.
Warning: drivers not checked: whether IronFlockOS ironflockos-amd64-efi-base 0.15.0 drives virtio-pci of the disk (/sys/devices/pci0000:00/0000:00:03.0), virtio-pci of the network card (/sys/devices/pci0000:00/0000:00:04.0) is not known: the hardware list of this release does not name the drivers built into its kernel
Warning: this is a Compute Engine VM: it keeps its address, but loses Google's guest environment, so 'gcloud compute ssh', OS Login and metadata SSH keys stop working; the serial console stays. With Shielded VM's integrity monitoring on, the first boot of IronFlockOS fails its check until the baseline is learned again
Dry run: nothing was changed.

sudo ironflock os install -c device.flock --disk /dev/sda --yes の実行では、同じ計画が表示され、その後にステージングと引き渡しが続きます：

Staging IronFlockOS in memory: nothing is written to /dev/sda before the restart, and Ctrl-C until then leaves the machine as it was.
Downloading: 100% (662.9 MB of 662.9 MB)
Checking: 100% (662.9 MB of 662.9 MB)
Preparing: 100% (662.9 MB of 662.9 MB)
Staged: the image is in memory and checked against the catalog and the plan; the boot option Boot0003 for IronFlockOS is at the end of the boot order, and goes first after the write.
The old system's boot option Boot0001 (debian) is deleted after the write.
Handed over: the machine restarts now, writes IronFlockOS onto /dev/sda at the end of its shutdown (the console shows it) and starts it; the device kitchen-pc appears in IronFlock within about ten minutes. If it does not, see the machine's console; a machine that comes back with its old system has the reason in its EFI variable IronFlockInstall.

--json では、結果は計画を表す 1 つの JSON オブジェクトです。--dry-run ではすぐに出力されます。それ以外では引き渡しの後に、dry_run が false で staging を含んで出力され、--host 経由では待機の後に wait も含んで出力されます。stderr には進捗が JSON 行として出力され、それ以外は何も出力されません（出力と JSON）。シークレットを含むフィールドはありません。IRONFLOCKOS パーティション用のファイルは名前とサイズで示され、プロキシ URL はパスワードなしで示されます。上のドライランの結果を、改行を加えて示します（コマンドは 1 行で出力します。... は例で省略した部分です）：

{"dry_run":true,
 "machine":{"hostname":"debian-vm","os":"Debian GNU/Linux 13 (trixie)","architecture":"amd64","secure_boot":{"enabled":false},"memory_available":1651179520,"memory_needed":1220587675},
 "disk":{"device":"/dev/sda","devnum":"8:0","size":21474836480,"model":"Google PersistentDisk","serial":"persistent-disk-0","sysfs":{"vpd83":"0:persistent-disk-0"},"guid":"a6c1e3f4-0b2d-4c8e-9f1a-2b3c4d5e6f70","found_by":"esp","esp":"/boot/efi","storage":["partitions"],"encrypted":false},
 "image":{"image_id":"ironflockos-amd64-efi-base","version":"0.15.0",...,"raw_size":4564471808,"min_disk_size":10737418240,"guid":"...","ironflockos":{"guid":"d53fd016-10da-40c6-8d85-a4eae33538af","start":1048576,"size":268435456},"shim_sha256":"...","head_size":269484032,"head_sha256":"..."},
 "device":"kitchen-pc","device_file":"device.flock","flock":"/home/admin/device.flock",
 "network":{"interface":"ens4","mac":"42:01:0a:84:00:02","kind":"wired","addressing":"dhcp","carried":"nothing","addresses":[],"gateways":[],"dns":[]},
 "proxy":null,"ssh_user":"operator","files":[{"path":"device.flock","size":1234}],
 "drivers":{"checked":false,"devices":[...]},"not_carried_over":[...],"delayed_reboot":false,"warnings":[...]}

拒否する場合

次の場合、コマンドは終了コード 3 で拒否し、何も変更されません：

• コンテナ、systemd が PID 1 でないシステム、IronFlockOS（そこでは os update がリリースをインストールします）、ReswarmOS。
• BIOS、32 ビット UEFI、イメージのないアーキテクチャ、マウントされていない EFI 変数（拒否の理由に mount コマンドが示されます）、または読み取り専用でマウントされた EFI 変数（mount -o remount,rw が示されます）。
• イメージの shim または GRUB を起動しない Secure Boot。
• コマンドが特定できないディスク（--disk で指定してください）、システムが起動したディスクではない --disk、パーティション、ディスクがない。それ自体で独立したディスク全体ではない、または lsblk が一覧表示しないディスク。GPT のないディスク。
• 別のディスク上、複数のディスクにまたがる、ZFS 上、またはどのディスク上にもない（ライブシステム）ルートファイルシステム。
• 512 バイト以外の論理セクター、小さすぎるディスク、コマンドが分解しないストレージスタック、このディスクと別のディスクにまたがる btrfs ファイルシステムまたは LVM ボリュームグループ、IronFlockOS のパーティション名を持つ別のディスク。
• メモリ不足。
• コマンドが引き継がないネットワーク、マシン自体の上のプロキシまたはマシンのループバック上のアプライアンスのミラー、proxy.conf を受け付けないイメージでのプロキシ、proxy.conf が受け付けない文字を含むプロキシ、読み取れないアクティブな NetworkManager プロファイル。
• イメージにディスクまたはネットワークカードのデバイスのドライバーがないことを示す、リリースのハードウェアリスト。
• 動作しない iproute2 の ip。ネットワークを読み取れません。
• 質問の後、ステージングが何かを変更する前：計画のディスクではなくなったディスク、すでにマウントポイントである /run/initramfs、そのままでは実行できない計画。

次のものはコマンドラインの誤り（終了コード 2）で、何かを変更する前にチェックされます：

• --dry-run 以外での、--disk なしの --yes。
• デバイスエージェントがインストールされていないマシンでの -c の省略。--no-wait なしの --host 経由での、-c の省略、または SSH ユーザーをセットアップしない .flock ファイル。
• カタログにない --image、マシンとは別のターゲット用の --image、またはインストーラースティック（os flash --installer が書き込むもの）。
• パスワードを含むプロキシ URL、および agent install が拒否するその他のプロキシのフラグ。
• 複数のマシン（--host の複数回指定、--hosts）。

失敗する場合

次の場合、コマンドは終了コード 1 で失敗し、何も変更されません：

• .flock ファイルが有効なものでない、またはその SSH 鍵が有効なものでない。
• os images と同じく、カタログを検証できない、または取得できない。アプライアンスのミラーを使う場合は、ミラーからもクラウドからも取得できない。
• イメージファイルの先頭をダウンロードできない（getting the image ...。アプライアンスのミラーを使う場合は、ミラーからもクラウドからも）、またはコマンドが知っている IronFlockOS イメージではない。ミラーがカタログを提供しなかったためにカタログをクラウドから取得した場合、エラーはカタログの警告 the appliance's mirror ... gives no IronFlockOS catalog now (...) で始まり、両方のサーバーを示します。
• ダウンロードのローカルアドレスがどのネットワークカードにも属していない。マウントテーブル、ブロックデバイス、メモリを読み取れない。EFI 変数を解析できない。
• 質問の後：イメージファイルがカタログのものでない、または計画が読み取ったものと異なる（メッセージは両方の値を示します）、ダウンロードが失敗した、ファームウェアがブートオプションを受け付けない、または再起動を開始できない。ステージングは取り消されます。取り消しも失敗した場合、メッセージは再起動を求めます。再起動で、残ったものが削除されます。

URL に含まれている可能性のあるユーザーとパスワードを付けて、URL が出力されることはありません。

終了コード

すべてのコマンドにおける各コードの意味は、フラグ、出力、終了コード に記載しています。