要点：ZimaCubeのネットワークが失われたのか、OS全体がフリーズしたのかをまず判断する
「ルーターから消えた」と聞くとNICの問題のように思えますが、このスレッドからは、より有力な手がかりが得られました。モニターとキーボードを接続すると画面は表示されているのに、マシンはキーボード入力に反応しませんでした。これは単なるDHCPリースの欠落ではなく、システムのフリーズです。この区別ができると、トラブルシューティングの内容は大きく変わります。
次の障害に備えてローカルコンソールを使う
一時的にモニターとキーボードを接続したままにします。リモートアクセスが停止したら、電源を入れ直す前にコンソールを確認します。ZimaOSコンソールのキーを試し、画面が更新されるか、入力を受け付けるかを確認します。
ローカル入力が機能しているのにルーターにデバイスが表示されなくなった場合は、イーサネット、DHCP、ネットワークサービスを確認します。ローカル入力も反応しない場合は、画面を記録し、OS、カーネル、ハードウェアのハングとして扱います。
uptimeで再起動とハングを見分ける
uptime
last -x | head
journalctl -b -1 -p warning..alert
journalctl -b -1 -k復旧後、uptime を使えばサーバーが実際に再起動したかどうかを確認できます。前回の起動時のログには、強制的な電源サイクルの前に発生したカーネル障害、ストレージのタイムアウト、OOMキル、ドライバーエラーなどが記録されている場合があります。前回の起動時のログでは、ジャーナルの起動履歴を選択できます。
ルーターの夜間スケジュールを根本原因だと決めつけない
有几位用户禁用了 Wi-Fi 计划或路由器重启，但仍能重现中断。这表明“路由器关闭了 Wi-Fi”不足以解释该问题。服务器使用的是有线连接，而且之后的故障也发生在白天。请将路由器事件记录在时间线中，但在归咎于路由器之前，必须先确认存在可重复的相关性。
恢复后检查当前以太网状态
ip addr
ip route
ethtool YOUR_INTERFACE
dmesg | grep -i -E 'link|ether|nic|reset|timeout'当前 ZimaOS 会分别显示物理以太网链路状态、协商速率和已分配的 IP。下次如果仅发生网络故障，请将路由器端口状态与本地接口状态进行比较。ZimaOS 网络接口提供当前的网络控制项。
如果仅发生网络故障期间控制台仍能接受命令，ethtool 可以在不重启的情况下显示链路状态、协商速率和驱动程序信息。ethtool 网络检查有助于区分操作系统仍在运行但链路失效的情况与整台机器完全冻结的情况。
不要将反复强制重置作为常规恢复方式
每天多次长按电源按钮可能导致文件系统和数据库损坏，尤其是在进行大规模传输或 RAID 活动期间。如果控制台已冻结且没有正常关机路径，可能不得不强制断电一次，但只要条件允许，请先收集证据。
在诊断间歇性系统卡死时，ZimaOS 备份尤为重要。
稳定性测试期间减少变量
不要同时更改路由器、客户端、存储和应用设置，而应暂时停止非必要应用、禁用不需要的 USB/PCIe 设备，仅保留一条确认正常的以太网连接路径，并避免同时进行数 TB 级迁移。如果冻结现象消失，请一次重新启用一个工作负载。这样获得的信息远比一次性更改所有设置有价值得多。
ZimaOSの復旧機能は、安定性テストでシステムスロットやインストールに問題が明らかになった場合の、現在のシステム復旧の境界を提供します。
過去の1.2.x系の報告をZimaOS 1.7にそのまま適用すべきではない理由
このスレッドは2024年のもので、IceWhaleは1.2.x系で安定性に関する問題を積極的に修正していました。現在のZimaOSでは、カーネル、ネットワーク、メモリ、ストレージ、ファイルサービスに多くの変更が加えられています。このスレッドは、コンソールとネットワーク、再起動とハング、ログと推測を区別する診断方法を学ぶために利用し、現代の一晩中の切断がすべて同じ2024年のバグだと主張するために使わないでください。
ハードウェアを疑うべきタイミング
現行の安定版リリースでも、最小限のアプリと正常なストレージ／ネットワーク環境でフリーズが続く場合は、メモリ診断を実行し、温度、電源、PCIeデバイス、ディスク／コントローラーのエラーを調べてください。異なるOSやネットワーク環境でも完全なフリーズが再現するなら、調査対象をZimaOS自体より下の層に移すべきです。
ZimaCube 2プラットフォームは、初代ZimaCubeのハードウェア筐体と後継プラットフォームを区別する際に役立ちます。
よくある質問
なぜZimaCubeがルーターから見えなくなるのですか？
ネットワークだけの障害、再起動、または完全なシステムハングの可能性があります。どれに該当するか判断する前に、ローカルコンソールと直前のブートログを確認してください。
ディスクのスタンバイによってZimaCube全体が見えなくなることはありますか？
ディスクのスタンバイによってサーバー全体が休止すると考えてはいけません。キーボード入力とネットワークの両方が停止する場合は、システム全体のフリーズとして診断してください。
毎晩再起動するようスケジュールすべきですか？
スケジュールした再起動で不安定さが隠れることはありますが、原因は特定できません。再起動を恒久的な回避策にする前に、ログと制御したテストを利用してください。
ハードリセットする前に何を収集すべきですか？
コンソールを撮影し、キーボードの反応を確認し、ルーターのリンク／DHCP状態を記録し、時刻を控えてください。再起動後に、直前のブートのカーネルログと警告ログを収集します。
大容量ファイルの転送がフリーズの原因になることはありますか？
ストレージ、メモリ、ドライバー、または温度に関する問題が明らかになることはありますが、裏付けとなるログがなければ、転送そのものが根本原因とは言えません。制御した負荷で再現してください。
