コミュニティソリューション

ZimaOSのアップデートが緊急モードに移行:まず復旧してください

A Proxmox ZimaOS system stopped booting after the 1.3.2 update, while the previous system slot still worked and later diagnostics implicated storage dependencies and custom mount state.

要点:まず別の ZimaOS スロットを使用し、その後で緊急モードの正確な依存関係を診断する

ZimaOS 1.3.2 には、2025 年初頭、一部のサードパーティ製マシンとの既知の互換性問題がありました。この Proxmox のケースでは、スロット A は以前のリリースで起動できましたが、更新されたスロットは緊急モードに入りました。これはまさに、A/B システム設計が防ぐことを目的としている事態です。

アップデート後、永続ストレージデバイスでタイムアウトが発生し、緊急モードに入る ZimaOS の起動画面
最初の起動失敗では、ダッシュボードに到達する前に、ストレージデバイスのタイムアウトが原因で ZimaOS が緊急モードに入りました。

ステップ 1:GRUB から以前のスロットを起動する

コンソールに接続し、矢印キーで GRUB を表示して、別のシステムスロットを選択します。現在の ZimaOS は、迅速なロールバックのために引き続きデュアルシステムパーティションを使用しています。ZimaOS システムリカバリーで現在の手順を説明しています。

RAUC のRAUC スロットモデルが、基盤となるスロットの概念を提供します。

ステップ 2:最後の緊急モード行ではなく、最初に発生した本当の障害を確認する

1.3.2 の障害調査中にカーネルとプラットフォームの初期化情報を示す ZimaOS の起動ログ
2 枚目の診断スクリーンショットには、サードパーティ製 Proxmox ゲストが通常の起動を完了できなかった際のカーネル初期化の詳細が記録されています。
VirtIO SCSI ディスクと OVMF UEFI を含む ZimaOS ゲスト用 Proxmox 仮想マシンのハードウェア構成
この VM では OVMF UEFI、VirtIO ネットワーク、複数の SCSI ディスクを使用しており、障害を他のサードパーティ製仮想ハードウェアと比較する際に重要です。
ZimaOS が緊急モードに入る前に dev md zimaos のタイムアウトを示す Proxmox VNC ビュー
後のスクリーンショットでは、依存関係の失敗と緊急モードに先立って、/dev/md/zimaos で発生した正確なタイムアウトが示されました。

緊急モードは結果です。その上に表示される、最初にタイムアウトしたデバイス、マウントの失敗、または不足している依存関係を確認してください。このケースでは、後続の依存関係エラーが表示される前に、ストレージデバイスが問題として示されました。

journalctl -xb
systemctl --failed
lsblk -f
cat /etc/fstab

ステップ 3:再インストールする前にカスタム fstab エントリを確認する

起動トラブルシューティング中に /etc/fstab と overlay upper_etc fstab のカスタムエントリを表示する ZimaOS ターミナル
最後の診断上の手がかりは変更された fstab パスでした。IceWhale は、カスタムマウントエントリがアプライアンスの起動プロセスと競合した場合に、同様の起動失敗が発生すると報告しています。

同じケースの後続の展開では、もう 1 つの重要な原因が明らかになりました。手動で変更した /etc/fstab は、参照先のデバイスが存在しない場合や、マウント順序がアプライアンスの起動プロセスと競合する場合に、ZimaOS の起動を妨げる可能性があります。IceWhale は、/etc/fstab と永続オーバーレイのコピーの両方が関係する同様の障害を報告しています。

手動でカスタム RAID またはマウントエントリを追加した場合は、現在のストレージ構成と比較し、内容を理解しているエントリだけを削除してください。通常の RAID やディスクのマウントには、ZimaOS のストレージインターフェースを使用することを推奨します。

以前の 1.3.2 ドライバーバグが現在の普遍的な問題ではない理由

エンジニアリングチームは、その特定のリリースにおけるサードパーティ互換性の問題を認めました。ZimaOS は 1.3.2 以降、多くのリリースを重ねています。そのため、「1.3.2 で Proxmox VM が壊れた」という情報は、2026 年のシステムの診断ではなく、過去の証拠として扱うべきです。

ZimaOS のインストールリカバリーが、サードパーティ製 x86 ハードウェアに対する現在の基本手順です。

新規インストールでも緊急モードに入る場合

これは、問題が仮想ハードウェア、接続されたデータディスク、永続的なマウント状態、またはサポート対象外のホスト構成に関係していることを示す強い手がかりです。古いシステムパーティションだけが原因とは限りません。まず必要最小限の仮想ハードウェアで起動し、その後データディスクを 1 台ずつ追加してください。

RAID またはマウントのメタデータを編集する前にデータを保護する

起動スロットのトラブルシューティング中に、mdadm シグネチャを消去したり、アレイを再作成したりしないでください。RAID リカバリーでは、起動リカバリーとアレイリカバリーを分けて扱います。また、ZimaOS バックアップが安全対策を担います。

GRUB で修正できることと、できないことを理解する

GRUB では以前の ZimaOS システムスロットを選択できますが、壊れたデータマウントや無効なファイルシステムエントリを修復することはできません。GNU GRUB の制御で、ブートローダー層について説明しています。以前のスロットが起動した場合は、その動作する環境を使ってストレージ構成を確認し、失敗したスロットを変更する前にデータをバックアップしてください。

FAQ

ZimaOS はなぜ古いスロットでは起動するのに、新しいスロットでは起動しないのですか?

古いスロットには、以前正常に動作していたシステムイメージが残っているためです。新しいスロットには、ドライバー、マウント、または構成の問題がある可能性があります。

緊急モードはデータが失われたことを意味しますか?

いいえ。通常の起動に必要な依存関係が失敗したことを意味します。ファイルシステムが失われたと判断する前に、ストレージとマウントの状態を確認してください。

不正な fstab エントリによって ZimaOS の起動が妨げられることはありますか?

はい。満たすことのできないマウントがあると、起動が停止したり、システムが緊急モードに入ったりする可能性があります。

すぐに再インストールすべきですか?

いいえ。まず別の A/B スロットを試し、最初に失敗した依存関係を記録してください。リカバリーが現実的でない場合にのみ、再インストールしてください。

ZimaOS は Proxmox でサポートされていますか?

仮想化環境での展開は可能ですが、サードパーティ製の仮想ハードウェアによって互換性の違いが現れる場合があります。現在のリリースでテストし、ロールバック手段を確保してください。