Change:
###### implementation <del> config.powerManagement.powerDownCommands = lines; </del> <ins> config.powerManagement.powerUpCommands = lines; </ins> }

Discussion:
Describe the bug In can be specified but only works as intended after pm-suspend command. My main use case for Wake-On-Lan is after poweroff and for this, the command is ineffective. To Reproduce As described above. Expected behavior Wake-On-Lan should work not only after suspend, but also for poweroff. Screenshots If applicable, add screenshots to help explain your problem. Additional context I am using below lines in my to work around this issue. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Maintainer information:
Wow, this module is old: I think it was contributed by but I'm not sure, they have probably changed email address. In any case, the option help says to check the man page and it says these feature are not supported by all network cards/motherboard. I also think it has to be enabled from the BIOS, did you check?
Yes, it is enabled and that's why my work-around above works It is interesting that my friend and I raised a ticket related to WOL 5 years ago as well
Hi there. I've stumbled into this as well, would appreciate if wol works after a poweroff too ;) After some digging it looks like the issue is that the service relies on which states the following: Except it only defines a pre-sleep service which doesn't get executed on shutdown. Considering power failures & other unexpected shutdowns I would feel more confident if the wol bit was to be set as early as possible at boot time, so powerUpCommand would have made more sense to me, but even that is currently broken & only works for post-resume :/ So I guess we should fix first anyway; looking at the history I don't think it ever worked maybe something used to pull pre/post at boot/poweroff times before? There are plenty of ways of doing that but I'm not sure what would be preferred. Pulling post- at boot time might have surprising side effects, so defining new powerupcommands.service / powerdowncommands.service might be best? Thanks!
I am currently learning Nix package management in depth so this might be a good thing to do when I am more comfortable with this system :-) But by all means, if you have some idea, please go ahead!

Looked a bit more: I was mistaken, powerUpCommands is included in stage-2 boot so should work for us ; as far as wakeonlan is concerned the easiest fix would be to just switch it from powerDownCommands to powerUpCommands and call it a day. That will run early on boot and after resume which is exactly what I wanted :) I don't think other users of powerDownCommands need things to run preshutdown so the simplest way forward would be to rename it to presleepCommands (to echo resumeCommands) and call it a day - someone who needs powerDownCommands the way it should be can just add it as I suggested (with an extra service on top) the day it becomes necessary. the first point is easy and should not cause any problem, if you want to try by all means go ahead -- I can do it though, please just say. I'll open a PR for the second point after that gets merged to avoid conflict (doing that first would require editing the same wakeonlan bits as you will need to edit)
Oh of course, please do go ahead! (I'm still busy learning Nix packager :-))
Trying to use this after the change: no luck here with getting wake on lan to work (expecting 'Wake-on: g' getting d after clean reboot
Could you check why and open a new issue? And please me in it. It should normally run at boot from the init script (), look for the local-cmds script and its content: I don't like the way the powerUpCommands are run, it would be much simpler/robust to define a service to start at boot, but I don't see why it wouldn't work unless you mess with the stage2 setup, at which point I'm not sure what to guarantee... Oh, what arch are you doing that on? aarch64 boot with uboot might be different?
If the ethtool command is there btw, that means later network initialisation resets it or the command happens too soon (before interface renaming?), there might be traces in journalctl. At that point it'll probably be really simpler to define a service like I currently do (note this only does boot, not return from suspend):