ZimaCube以外のハードウェアでのZimaOS RAIDトラブルシューティング

ZimaOSがドライブを認識しているにもかかわらず、RAID作成画面で誤ったベイに割り当てられたり、選択可能なスロットが空白になったり、一部のディスクしか表示されなかったりする場合は、まず現在のRAID健全性の問題と、このスレッドで説明されている古いZimaCube以外のディスクマッピング問題を切り分けてください。2ページ目の内容は主に、DIYハードウェアにおけるZimaOS 1.2.xおよび初期の1.3.xの挙動を反映しています。

現在のZimaOS RAIDトラブルシューティングでは、ドライブ数、ディスクの健全性、個別のフォーマット、空のマウントポイント、再起動から確認します。古いスロットマッピングの回避策を検討するのは、これらのチェックを行った後、かつ現在のバージョンで同じマッピング不具合を再現できる場合に限ってください。

古いディスクマッピングバグの症状

ZimaCube以外のハードウェアを使用する複数のユーザーから、物理的に接続したドライブが予期しない仮想位置に表示されるとの報告がありました。ストレージページではベイ4、5、6にディスクが表示される一方、RAIDダイアログでは手前の位置にあるディスクが想定され、次へボタンが使用できなかったり、ドライブが選択肢から隠れたりすることがありました。

ZimaCube以外のディスクが予期しないベイに割り当てられている、古いZimaOSのストレージ画面 — 古いZimaOSビルドでは、DIYハードウェアのディスクが予期しないベイ位置に割り当てられていました。

ベイ4、5、6にディスクが表示された、古いZimaOSストレージマネージャー — ストレージインターフェースではディスクを認識できても、RAID選択モデルでは使いにくい状態になっている場合がありました。

認識とRAID適格性は異なる2つの層だった

使用できないディスクスロットが表示された、LincStationハードウェア上の古いZimaOS RAID作成画面 — DIYシステムではストレージが一覧に表示されても、RAID選択ワークフローが未完了のままになる場合があります。

この区別は現在でも役立ちます。ディスクが lsblk カーネルがブロックデバイスを認識していることを示します。ファイルまたはストレージマネージャーに表示されることは、別の層でも認識されていることを示します。RAIDで選択できる状態になると、さらに別の適格性およびUI層が加わります。

いずれかの層で問題が発生した場合は、すぐに消去するのではなく、ディスクがどの段階で表示されなくなるのかを記録してください。ファイルシステムの状態、既存のRAIDメタデータ、マウント状態、現在のインターフェースで新しいアレイに使用可能なディスクと認識されているかどうかを確認します。

ZimaCube以外のRAIDトラブルシューティング事例における、古いZimaOSの「新しいハードドライブ」パネル — ストレージ層ではドライブを検出できても、RAIDワークフローでは期待どおりに割り当てられない場合がありました。

DIYハードウェアで選択できるディスクベイが1つしかない、古いZimaOSのRAID0画面 — 別のスクリーンショットには、RAID作成側でも同じ不一致が示されています。検出されたストレージが、期待される選択可能なベイに反映されていません。

システム構成を編集する前に現在のRAIDチェックを実行する

現在の公式RAIDトラブルシューティングガイドでは、少なくとも2台のドライブがあること、ディスクの健全性、各ディスクを正常にフォーマットできること、使用するRAIDマウントポイントが空であることを確認し、作成を再試行する前に再起動することを推奨しています。

現在のZimaOS RAIDトラブルシューティングチェックリストは、破壊的な思い込みを避けられるため、DIYハードウェアでも最初に確認すべき項目です。

SataStartNumberは、バージョン固有のコミュニティ回避策でした。

古いスレッドでは、IceWhaleチームの回答により、初期のZimaOSのUIロジックがZimaCubeのスロット配置に強く結び付いていたことが認められました。ユーザーには、次の項目を使ってディスクコントローラーの配置を確認するよう案内されました。 lsblk -o hctl また、特定のDIYシステムでは、次の設定を調整します。 SataStartNumber 内 /etc/casaos/local-storage.conf.

これにより仮想ベイのマッピングが修正されたと確認したユーザーもいましたが、その後、新しいZimaOSリリースでは同じ回避策を維持しなくても環境が修正されたと報告したユーザーもいました。したがって、これは歴史的な互換性対策であり、現在も普遍的に必要なものではありません。

古いものを適用しないでください SataStartNumber 別のマザーボードの値。コントローラーのトポロジーはシステムごとに異なり、現行のZimaOSでは同じ前提が使われていない可能性があります。

スクリーンショットが示す、バージョンの違いが重要である理由

ディスクベイのマッピング修正後の、旧ZimaOSのStorage Manager — あるユーザーは後に、マッピングの問題が解決された後、ディスクが想定された初期ベイ位置に配置されていることを示しました。

初期の1.3.1ベータビルドを示すZimaOSのバージョン画面 — スレッドの一部は、現行の1.7.xインターフェースよりはるかに古い、初期の1.3.xビルドでテストされていました。

ZimaOS 1.7.1には、特定のシナリオでRAIDステータスが不正確に表示される問題の修正も含まれています。これでDIYベイのマッピングに関するあらゆる問題が解決したとは限りませんが、2024年の設定編集を行う前に、現行ビルドで問題を再現するべきもう1つの理由になります。

5台のディスクを使うシェル回避策を一般的な手順にしないでください

後の参加者は8 TBのNVMeデバイスを5台使用していました。5台目のデバイスは別の場所では表示されていたにもかかわらず、UI上でRAID作成用に公開されたのは4台だけで、ユーザーは最終的に次のコマンドを使ってRAID5を手動で拡張しました。 mdadm.

5台のNVMeデバイスを検出し、そのうち1台に通常とは異なるスロット番号が割り当てられていた、旧ZimaOSのストレージビュー — 5台目のNVMeはシステム上では表示されていましたが、最初の4台とは異なる方法でマッピングされていました。

5台のLinux RAIDメンバーデバイスが表示された、旧ZimaOSのディスク一覧 — ディスク一覧とRAID作成インターフェースでは、使用可能なディスクの集合が一致していませんでした。

5台のNVMeを使用したトラブルシューティング事例における、旧ZimaOSのRAID5選択画面 — RAID5のワークフローは、どのディスクが表示され、どのディスクが選択可能だったかを比較するための証拠の一部でした。

選択可能なNVMeドライブが4台のみ表示された、旧ZimaOSのRAID5作成画面 — 通常のRAID5選択手順では、5台目のデバイスが表示されませんでした。

5台目のディスクを組み込んでいた際の、旧ZimaOS RAID5の状態 — ユーザーは最終的にシェルからアレイを拡張しましたが、その手順は一般的な推奨事項としてここでは再掲しません。

低レベルコマンドでアレイを停止、再構成、拡張すると、デバイス一覧やメタデータに関する前提が間違っていた場合、データが失われる可能性があります。ディスクは認識されているもののRAID UIで使用できない現行システムでは、重要なデータをバックアップし、バージョン情報とともにエスカレーションしてください。 lsblk 古いシェル手順をそのままコピーするのではなく、出力、コントローラーのトポロジー、スクリーンショット、既存のアレイ状態を確認してください。