2つのZimaOSブートスロットが両方とも失敗し、コンソールにオーバーレイのマウントエラー、スーパーブロックの読み取り失敗、またはNVMe I/Oエラーが表示される場合は、最初からストレージプールの再構築を始めないでください。まず、障害がブートデバイスにあるのか、それとも別のデータディスクにあるのかを確認します。
2026年6月のこのケースでは、読み取り専用の診断により、ブート用NVMeでメディアエラーが繰り返し発生している一方、大容量のBtrfsデータプールは別のディスク上にあることが分かりました。ユーザーはブートドライブを交換してZimaOSを再インストールし、その後、データプールが残っていることを確認しました。
まずブートデバイスとデータプールを分けて確認する
スレッドのレスキューシェル出力には、ZimaOSのブート／データパーティションを含む約119 GBのNVMeと、別に存在する複数ディスク構成のBtrfsプールが示されていました。この区別により、復旧計画が変わりました。ブート用NVMeの故障は、ストレージプールの故障を自動的に意味するわけではありません。
まずは読み取り専用のコマンドを実行します。
lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS
blkid
cat /proc/cmdlineディスクやパーティションを対象とするコマンドを実行する前に、正確なデバイス名を書き留めてください。
カーネルログで実際のI/Oエラーを確認する
元のケースでは、ブートデバイスに対してcritical medium error、Buffer I/O error、EXT4のマウント失敗、NVMeエラーが繰り返し記録されていました。これらのメッセージは、一般的なブート画面のパニックよりも、ストレージ障害を強く示す証拠です。
dmesg -T | grep -Ei 'nvme|I/O error|Buffer I/O|EXT4|superblock|reset|timeout|critical|media'エラーが一貫してブート用NVMeを指し、データディスクに障害が報告されていない場合は、調査をブート経路に集中させてください。
SMARTの「PASSED」だけではメディアエラーを否定できない
スレッドでは、NVMeのSMARTヘルス概要が依然としてPASSEDと表示されていましたが、詳細カウンターには76件のメディア／データ整合性エラーが記録され、カーネルにはすでに読み取り失敗が記録されていました。読み取り専用のファイルシステムチェックでも、読み取り不能なブロックに遭遇して中断していました。
正しいデバイス名を確認したうえで、smartctl -x /dev/nvmeXn1やnvme smart-log /dev/nvmeXn1などを使って詳細なヘルスデータを確認してください。全体的なヘルス状態を示す単一のワードだけを診断の根拠にしないでください。
まずは読み取り専用のファイルシステムチェックを行う
コミュニティでは、影響を受けたEXT4オーバーレイパーティションに対してe2fsck -fnを実行し、修復を書き込まずにファイルシステムを検査しました。この読み取り専用チェックでも読み取り不能なブロックに遭遇し、ハードウェア障害の診断がさらに裏付けられました。
マウント中のファイルシステムに対して、書き込みモードのfsckを決して実行しないでください。また、パーティション名を推測しないでください。ブートSSDが物理的に故障している場合、書き込みを繰り返すと復旧が難しくなる可能性があります。
スロットAとスロットBの両方が失敗する理由
ZimaOSは、ZimaOSシステム復旧ガイドに記載されているA/Bシステムスロットを使用します。ただし、どちらのブート選択肢も、ブートデバイス上の正常な共有ストレージコンポーネントに依存しています。そのため、オーバーレイやブート用NVMeに障害があると、両方のスロットで起動を完了できない場合があります。
交換がより安全な方法になる場合
元のケースで、ブート用NVMeにカーネルのメディアエラー、SMARTの詳細なメディアエラーカウンター、読み取り不能なファイルシステムブロックが確認された後、コミュニティは、そのSSDを信頼できないものとして扱い、その場で修復しようとしないよう助言しました。ユーザーはSSDを交換し、ZimaOSの再インストールに成功しました。
再インストール中は、データディスクを明確に識別し、既存のプールを初期化したり再作成したりしないでください。ZimaOSインストールのトラブルシューティングガイドはブートインストール側の対応に役立ち、再インストール後のストレージ復旧ガイドでは重要な原則を再確認しています。つまり、すでにデータが入っているプールを再作成しないでください。
要点
このケースでは、カーネルパニックはブート用NVMeの故障によるものであり、別のデータプールが破壊されたことを示すものではありませんでした。読み取り専用で診断し、どのデバイスにI/Oエラーが発生しているかを確認し、データディスクには手を加えないでください。元のユーザーは故障したブートドライブを交換してZimaOSを再インストールし、既存のデータプールが無事だったことを確認しました。
