ZimaOSを実行しているZimaCubeでWake-on-LANを設定するために、aptでethtoolをインストールする必要はありません。元のスレッドでIceWhaleのスタッフが説明しているように、ethtoolはZimaOSにすでに含まれており、ZimaCubeでは通常、Wake-on-LANがデフォルトで有効になっています。
混乱の原因は、製品向けの手順とオペレーティングシステム向けの手順が混在していたことです。ユーザーが見つけた古いガイドは、CasaOSを搭載したZimaBoard向けに書かれたもので、Debian形式のパッケージインストールが関係する場合があります。ZimaOSは異なるシステム設計を採用しているため、CasaOSのドキュメントにあるapt installコマンドをそのまま使うのは、安全な初期対応とはいえません。
古いaptコマンドがZimaOSに適さなかった理由
ユーザーは、ethtoolのインストールを指示するWake-on-LANガイドに従おうとしました。ZimaOSでは、一般的なDebianホストと同じような通常のaptパッケージ管理の手順でシステムコンポーネントを扱うことはできません。
IceWhaleのスタッフは、このユーティリティはすでに存在すると回答しました。まず確認すべきなのはこれです。システムパッケージをインストールまたは置き換えようとする前に、ZimaOSでサポートされているシェルからethtoolを実行してください。
別途用意されているZimaCubeの最新のWake-on-LANガイドでも、aptによるインストール手順ではなく、組み込みのethtoolコマンドを使用しています。
ZimaCubeのWOLはデフォルトで有効ですが、経路全体を確認する
現在のZimaCubeドキュメントによると、Wake-on-LANはデフォルトで有効です。有効になっていない場合、Linux側で使用する手順として記載されているコマンドはethtool -s eth0 wol gです。その後、ethtool eth0を実行してウェイク設定を確認します。
カスタム構成のZimaOSでは、インターフェース名が必ずしもeth0とは限りません。まず実際のEthernetインターフェースを特定してください。現在のZimaCubeガイドでは、WOLの手順が2.5GbEポートに対応していることも説明されています。そのため、このハードウェアではポートの選択が重要です。
Linux側が正しくても、ファームウェア設定によってWOLが妨げられる場合がある
Wake-on-LANには、ソフトウェア上のフラグが1つ設定されているだけでは不十分です。NICに待機電力が供給され、ファームウェアがウェイクイベントを許可し、シャットダウン後もネットワークインターフェースが適切なウェイクモードを維持する必要があります。
現在のZimaCubeの手順では、Linux側を確認する前にBIOSでWake from PMEを有効にします。マジックパケットに反応しない場合は、ethtoolの設定を何度も変更する前に、BIOS設定と電源状態を確認してください。
ZimaCubeのBIOS電源設定でも、Wake on LANはZimaOSの設定と組み合わせて使用する必要があるファームウェアオプションとして説明されています。
設定が実際にリセットされる場合にだけ、永続化の回避策を追加する
現在のWOLガイドには、再起動後にwol gを再適用するsystemdサービスの例が記載されています。確認済みのシステムで、設定が繰り返し無効な状態に戻る場合には役立ちます。
ただし、Wake-on-LANがすでに正しく報告されているZimaCubeで、最初に行うべき手順ではありません。まず再起動し、現在の値を再確認してください。設定が失われていることを確認できた場合にのみ永続化の仕組みを追加し、ZimaOSのアップデート後にも再検証してください。
リモートウェイクをトラブルシューティングする前に、同じLANからテストする
同じサブネット上にある、動作確認済みのWake-on-LAN送信元から始め、正しいMACアドレスを使用してください。ローカルでテストすれば、VPN、ルーターのブロードキャスト転送、リモートアクセスのポリシーを問題から切り離せます。
ローカルWOLは成功するのにリモートWOLが失敗する場合、主な原因はZimaCubeの設定ではない可能性が高いです。その場合は、リモートツールがどのようにLANへ到達しているか、また正しいブロードキャストドメインにマジックパケットを送信できるかを確認してください。
