I have recently upgraded 15.6 to 16.0 using the migration tool. Wake on lan worked ok on 15.6. On 16.0, ethtool fails to enable wol. I have not made any changes to the bios. Typical results of ethtool run shown below.
type or paste code here
~> sudo /usr/sbin/ethtool eth0 -s eth0 wol g
[sudo] password for root:
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
master-slave cfg: preferred slave
master-slave status: slave
Port: Twisted Pair
PHYAD: 0
Transceiver: external
MDI-X: Unknown
Supports Wake-on: pumbg
Wake-on: d
Link detected: yes
~>
The migration tool did not produce a wol.service file. Created one with the location and contents given by hcvv.
Rebooted. Wol does not work automatically, attempt to activate with ethtool gives the same result as above - Wake-on is still d
Nope. That is not the purpose and job of the opensuse-migration-tool. It only adds the required repos and performs a zypper dup (and some small other scripts).
That is nonsense. I created one because I wanted WOL being active at that system after every shutdown. That was my purpose. What others need WOL for and why is their business. The distribution is not responsable for that.
To begin with: the partner of enable is disable, not stop. Then: one indeed stop a service that is started with stop. But: as this service is of type oneshot, it will stop after it's task is done (the task being: arming the WOL for g`). The service is then not running and thus can not be stopped.
To begin with: the partner of enable is disable, not stop.
Then: one indeed stops a service that is started with stop.
But: as this service is of type oneshot, it will stop after itās task is done (the task being: arming the WOL for g). The service is then not running and thus can not be stopped. And of course the action(s) done when it is started will not be undone.
I do not quite understand what your strain of thoughts is.
You report that on your system setting WOL to g does not function on 16.0, where it did so on 15.6.
You may then think this is a general bug on 16.0. Thus I show that it still functions on my system with 16.0. Just as a start to debug the problem. I do so by showing that it is on g and by showing the command I did achieve that with. That command happens to be in a systemd service, but that is of secondary importance.
Now, instead of going from there to investigate your problem further, you start copying my implementation (and then complain because my implementation is not part of a recommended package in the distribution).
So please can you explain if you still have the problem and give us information of the point we are now so we can start searching further from that point on.
The problem, as stated in my original post, is that in 16.0 I cannot enable wol by giving an ethtool command at the bash command prompt.
You have shown how ethtool does the job within a systemd service, and that works for me too.
I am typing this on a computer that still runs 15.6, and ethtool works ok from the command line; this computer does not have a wol.service file.
So the question is why does ethtool work differently in 15.6 and 16.0 when started from the command line?
[Perhaps I am expecting too much from the migration tool - I had naively assumed that what worked in 15.6 would also work in 16.0 after migration.]
If you want to know why ethtool does not longer work, do a systemctl cat of that service and you will know. Would be also good to share the output of that command here so other can also learn something fro it.
It should. But as long as we can not understand what is wrong we can not name a culprit.
The strange thing here is that the systemd service has exact he same command as you tried. Thus I do not understand why it does not function āstandaloneā, but it does when inside the service.
Thus I would try to start from the begin and then show all details. Starting with showing the present situation, then setting WOL to g and then showing the new situation. I know you did something similar in your post #1, but this is a proves a bit more:
as root
ethtool eth0 | grep Wake
ethtool -s eth0 wol g
ethtool eth0 | grep Wake
(And of course with your systemd function disabled).
PLease try to understand what the problem is by reading from the start.
It is NOT the case that the service does not work anymore. On the contrary. It looks that function does work where the simple command does not. And the contents of the service is above, because the OP copied mine to test.
Problem solved - stupidity (on my part)
If you look closely at the first post in this thread, you will see that in the example posted, the ethtool command is incorrect! It contains the string āeth0ā twice, but the first one should not be there. After correcting this error, ethtool works from the command line as expected.
Thanks to those who posted suggestions, and apologies to those whose time was wasted. And a black mark to ethtool for not giving a diagnostic on improper input.
Interesting that the error was not noticed by any of those who repliedā¦
I should have looked better. In fact I wondered why setting to g listed all that text. What is more, I should have repeated by copy/paste what you did. But I did not want to because i did not want to change the status on my system.
Yes, paying more attention should probably have solved this earlier, but I guess you found out in the end by this topic triggering some brain cells deep inside. And then comes the Eureka.
