You do not need to install ethtool with apt to configure Wake-on-LAN on ZimaCube running ZimaOS. In the source thread, IceWhale staff clarified that ethtool is already included in ZimaOS and that Wake-on-LAN is normally enabled by default on ZimaCube.
The confusion came from mixing product and operating-system instructions. The older guide the user found was written for ZimaBoard with CasaOS, where Debian-style package installation can be relevant. ZimaOS uses a different system design, so copying apt install commands from CasaOS documentation is not a safe default.
Why the Old apt Command Did Not Fit ZimaOS
The user tried to follow a Wake-on-LAN guide that told them to install ethtool. ZimaOS does not expose a normal apt package-management workflow for system components in the same way as a general Debian host.
IceWhale staff responded that the utility was already present. That is the correct first check: run ethtool from the supported ZimaOS shell before trying to install or replace system packages.
The separate current ZimaCube Wake-on-LAN guide also uses the built-in ethtool command rather than an apt installation step.
ZimaCube WOL Is Enabled by Default, but Verify the Whole Path
The current ZimaCube documentation says Wake-on-LAN is enabled by default. If it is not active, the documented Linux-side command is ethtool -s eth0 wol g, followed by ethtool eth0 to verify the wake setting.
Do not assume the interface name is always eth0 on every custom ZimaOS installation. Identify the actual Ethernet interface first. The current ZimaCube guide also notes that its WOL procedure supports the 2.5GbE port, so port choice matters on that hardware.
Firmware Settings Can Block WOL Even When Linux Is Correct
Wake-on-LAN requires more than one software flag. The NIC must receive standby power, the firmware must permit wake events, and the network interface must retain the appropriate wake mode after shutdown.
The current ZimaCube procedure enables Wake from PME in BIOS before checking Linux. If a magic packet does nothing, verify the BIOS setting and power state before repeatedly changing ethtool.
ZimaCube BIOS power settings also identify Wake on LAN as a firmware option that must be paired with ZimaOS configuration.
Only Add Persistence Workarounds If the Setting Actually Resets
The current WOL guide includes a systemd service example for reapplying wol g after reboot. That can be useful when a verified system repeatedly returns to a disabled state.
It should not be the first step on a ZimaCube that already reports Wake-on-LAN correctly. First reboot and re-check the current value. Add a persistence mechanism only if you can demonstrate that the setting is being lost, and revalidate it after ZimaOS updates.
Test from the Same LAN Before Troubleshooting Remote Wake
Start with a known-good Wake-on-LAN sender on the same subnet and use the correct MAC address. Local testing removes VPN, router broadcast forwarding, and remote-access policy from the problem.
If local WOL succeeds but remote WOL fails, the ZimaCube setting is probably not the primary issue. At that point investigate how the remote tool reaches the LAN and whether it can deliver a magic packet to the correct broadcast domain.
