元のトラブルシューティングガイドが役立つのは、CasaOSのUIより下の層から調査を始めているからです。ドライブ、NIC、PCIeカード、USBデバイスの動作に異常がある場合、まず確認すべきなのは、基盤となるLinuxシステムがそのハードウェアをまったく認識しているかどうかです。
2026年の重要な境界は、オペレーティングシステムのアーキテクチャです。2023年のガイドは、通常のDebian/Ubuntu系Linuxインストール上でCasaOSを実行することを前提としています。現在のZimaOSは、Buildrootベースでシステムの大部分が読み取り専用となっている、別個のアプライアンスOSです。読み取り専用の診断コマンドは引き続き有用ですが、一般的なDebianガイドにあるパッケージのインストールやホストの変更に関する手順をZimaOSにそのまま適用しないでください。
dmidecodeを使ってBIOSとボードの情報を確認する
dmidecode 次のようなSMBIOS/DMIデータを読み取ります：
- BIOSのベンダーとバージョン；
- リリース日；
- システム／ボード識別子；
- メモリ情報；
- UEFIなどのファームウェア機能。
ハードウェア固有の問題をBIOSアップデートと比較したり、実際に動作しているボードのリビジョンを正確に確認したりする際に役立ちます。
lspciを使ってPCIeハードウェアが列挙されていることを確認する
lspci PCIサブシステムによって認識されているデバイスを一覧表示します。GPU、SATAコントローラー、NVMeアダプター、NIC、キャプチャカードなど、その他の拡張ハードウェアが含まれます。
新しいPCIe NICが lspci場合、問題はDocker/CasaOSより下の層にあります。アプリケーションソフトウェアをインストールする前に、接続状態、電源、ファームウェア設定、レーン共有、ハードウェア互換性を確認してください。
lsusbを使ってUSBデバイスの識別情報を確認する
lsusb USBベンダーID／製品IDを報告します。これらのIDは、Wi-Fiアダプター、Coral TPUデバイス、USBストレージブリッジ、Zigbeeコーディネーターなど、1つの製品名に複数のハードウェアリビジョンが存在する可能性のある周辺機器の診断に特に役立ちます。
dmesgを使ってドライバーと起動時のハードウェアメッセージを確認する
dmesg 次の情報を表示できます：
- カーネルドライバーのバインド；
- ファームウェアの読み込み失敗；
- USBの切断・再接続イベント；
- ストレージI/Oエラー；
- NICのリンク状態の変化；
- PCIe/AERエラー。
関係のない起動ログを何千行も投稿するのではなく、関連するセクションだけを抽出または保存します。
lsblkを使って「ディスクが検出されない」状態と「ディスクがマウントされていない」状態を切り分ける
lsblk ディスク、パーティション、ファイルシステムの関係、マウントポイントを表示します。ドライブが lsblk しかし、CasaOSのファイルUIに表示されないことは、Linux自体からドライブが認識されていないこととは別の障害です。
修復コマンドの前に読み取り専用の確認を優先する
Part 1の原文が最も優れているのは、観察方法を教えている点です。たとえば次のようなコマンドです dmidecode, lspci, lsusb, dmesg、および lsblk ストレージやパッケージを変更せずに、問題の層を特定できます。
ディスクの再フォーマット、ドライバーの再インストール、所有者の再帰的な変更、Dockerの再構築を行う前に、これを実行してください。
CasaOSとZimaOSではホスト変更のルールが異なります
CasaOSは通常、汎用Linuxホスト上で実行されます。そこでは apt 利用できる場合があります。ZimaOSはBuildrootベースであり、IceWhaleの現在のCLIガイダンスによると、rootであってもシステムフォルダーの大半は読み取り専用のままです。
ZimaOSで同じハードウェアを使用する場合は、現在のZimaOS CLIの範囲を使用してください。
ハードウェア側から上位層へ診断する
推奨される順序は次のとおりです。
- BIOS／ファームウェアがハードウェアを検出する。
- Linuxのバス列挙がデバイスを認識する。
- カーネルドライバーがバインドする。
- OSが使用可能なインターフェース／ブロックデバイスを作成する。
- CasaOS／ZimaOSがUIに表示する。
- Docker／アプリケーションがデバイス／パスを受け取る。
いきなり第6層に進むと、多くのハードウェア問題がアプリのバグのように見えてしまいます。
blkidを使用してファイルシステムの種類とUUIDを特定する
Part 1の原文では、次も使用しています。 blkid 後 lsblk。これは別の疑問に答えるものです。パーティションに実際に含まれているファイルシステムまたはLVMメンバーのシグネチャは何か、また、それを識別するUUID／PARTUUIDは何か？
これは、ディスクがLinuxでは認識されるものの、マウントやストレージマネージャーが想定されるファイルシステムを認識しない場合に役立ちます。何も再フォーマットする前に、出力を記録してください。
ドライバーやストレージを変更する前にハードウェアの証拠を保存する
再現可能なサポート報告を作成するには、次の情報と併せて関連するコマンドの出力を取得してください。
- ボードのモデルとBIOSバージョン。
- オペレーティングシステムのバージョン。
- デバイスのモデルとPCI／USB ID。
- 問題の直前に何が変わったか。
- ハードウェアがBIOS、Linux、CasaOS／ZimaOSのUIのそれぞれで認識されるかどうか。
これにより、ドライバーがないのか、ケーブルの故障、未対応のファイルシステム、またはコンテナのマッピングに問題があるのかを切り分けられます。
LinuxハードウェアトラブルシューティングFAQ
不明なPCIeカードに対して、最初に何を実行すべきですか？
lspci PCIサブシステムがデバイスを認識しているかを、読み取り専用で最も迅速に確認できます。
USBのベンダーID／製品IDを確認するには何が最も役立ちますか？
lsusb.
ガイドで想定されているDebianパッケージの前提をZimaOSでも使用できますか？
診断の考え方は維持しつつ、ZimaOS固有の拡張機能とドライバーのルールに従ってください。
