ethtool and rc.d scripts
ethtool and rc.d scripts
Hello world, this is basically a question about startup/shutdown scripts, couched in wake on lan question .
WOL works once, but after startup ethtool eth0 shows Wake-on: d (disabled.) If I use sudo ethtool -s eth0 wol g, it will again work once, but is then disabled. From my searching, the answer appears to be to place the above enabling command in a startup or shutdown script, so that it will be enabled each time, and ready for the next wakeup.
So, I tried putting ethtool -s eth0 wol g in rc.local_shutdown, thinking it better to have it run at shutdown rather than startup, so that even if it became disabled during a session, it would be re-enabled at shutdown. That didn't work, and I'm not sure why not.
Do I need to use sudo in the script? (I thought perhaps the startup/shutdown scripts would run with system privileges.)
Or, does it need to go in some other script (rc.local?) With or without sudo?
Thanks for any help.
WOL works once, but after startup ethtool eth0 shows Wake-on: d (disabled.) If I use sudo ethtool -s eth0 wol g, it will again work once, but is then disabled. From my searching, the answer appears to be to place the above enabling command in a startup or shutdown script, so that it will be enabled each time, and ready for the next wakeup.
So, I tried putting ethtool -s eth0 wol g in rc.local_shutdown, thinking it better to have it run at shutdown rather than startup, so that even if it became disabled during a session, it would be re-enabled at shutdown. That didn't work, and I'm not sure why not.
Do I need to use sudo in the script? (I thought perhaps the startup/shutdown scripts would run with system privileges.)
Or, does it need to go in some other script (rc.local?) With or without sudo?
Thanks for any help.
Real men don't systemd.
Friends don't let friends systemd.
Friends don't let friends systemd.
Re: ethtool and rc.d scripts
Hello,
did you allow wake-on in the BIOS setup? Do you use a network manager and if so, is the correct WOL source selected in the configuration settings?
In the mentioned scripts in rc.d the called programs run with root rights.
If a network manager is used, such as NetworkManager or Wicd, then it is their task to consider the WOL behavior. Automatically handled by NetworkManager and Wicd.
But if you really need to enforce wake-on behavior in an unconventional way and you want to do it better than with rc.local, then for NetworkManager, use a dispatcher script in directory /etc/NetworkManager/dispatcher.d to launch the ethtool program. For Wicd, the script belongs in the directory /etc/wicd/up.
The scripts are executed when the Ethernet interface is up. This guarantees that the parameters from the ethtool call will not be overwritten by NetworkManager or Wicd. As already written, NetworkManager and Wicd can run the WOL parameterization on their own.
Finally, you should have given the full output to the manual calls to ethtool:
and
It may then be possible to deduce more from the program outputs. For these calls you have to use sudo, if you do not want to have a real superuser.
did you allow wake-on in the BIOS setup? Do you use a network manager and if so, is the correct WOL source selected in the configuration settings?
If the interface is shut down in the shutdown process, then the WOL request can not be stored anywhere. So rc.local_shutdown is the wrong place. If you have no network manager in use and if the desired WOL mode is not already activated by default, this can be activated via rc.local.
In the mentioned scripts in rc.d the called programs run with root rights.
If a network manager is used, such as NetworkManager or Wicd, then it is their task to consider the WOL behavior. Automatically handled by NetworkManager and Wicd.
But if you really need to enforce wake-on behavior in an unconventional way and you want to do it better than with rc.local, then for NetworkManager, use a dispatcher script in directory /etc/NetworkManager/dispatcher.d to launch the ethtool program. For Wicd, the script belongs in the directory /etc/wicd/up.
The scripts are executed when the Ethernet interface is up. This guarantees that the parameters from the ethtool call will not be overwritten by NetworkManager or Wicd. As already written, NetworkManager and Wicd can run the WOL parameterization on their own.
Finally, you should have given the full output to the manual calls to ethtool:
Code: Select all
sudo ethtool eth0
Code: Select all
sudo ethtool -s eth0 wol g
Re: ethtool and rc.d scripts
galmei, thank you for a very complete answer.
It does appear to be working now, so if it continues, I will leave the command in rc.local.
A bit of background: I began with my own home-built microcomputer using just a 2kB ROM monitor program, and graduated to all kinds of OS's, including FLEX and OS-9 (both 6800/68000 based), CP/M (8080/Z80), and MS-DOS among others, so I am no stranger to the command-line. However, I have been using Windows for more years than I care to think about.
During those years, I have from time to time made an attempt become familiar with (or even convert to ) Linux, but without success. I believe that is because I always concentrated too much on the GUI/Window-manager. This time, I am attempting to learn Linux from the ground up, using only the command-line (no GUI.)
With that in mind, and since this topic is about startup/shutdown scripts, how would I configure Salix to boot into multiuser command-line mode (run level 3,) rather than the current windowed default of run level 4?
In /etc/inittab, I see the lines:
which I presume I would change to:
But are there any other changes required?
WOL is enabled in the BIOS. (Actually, I couldn't find any setting specifically targeting WOL or the network interface, but do have enabled Wake-on-PCI and Wake-on-PCIE, the only settings that seem remotely related.) However, the BIOS is obviously correctly configured, since WOL does work, but then seems to become disabled under Linux. Before installing Salix, this computer had Windows installed, and WOL always worked without issue.
No network manager in use, as far as I know (see more below.)Do you use a network manager and if so, is the correct WOL source selected in the configuration settings?
I have no idea where WOL is becoming disabled. But, I have already moved the enabling command to rc.local. So far, this seems to be working.If the interface is shut down in the shutdown process, then the WOL request can not be stored anywhere. So rc.local_shutdown is the wrong place. If you have no network manager in use and if the desired WOL mode is not already activated by default, this can be activated via rc.local.
Thank you. That's what I expected, but it's good to have it confirmed.In the mentioned scripts in rc.d the called programs run with root rights.
Sorry for the lack of information.Finally, you should have given the full output to the manual calls to ethtool:andCode: Select all
sudo ethtool eth0
It may then be possible to deduce more from the program outputs. For these calls you have to use sudo, if you do not want to have a real superuser.Code: Select all
sudo ethtool -s eth0 wol g
It does appear to be working now, so if it continues, I will leave the command in rc.local.
A bit of background: I began with my own home-built microcomputer using just a 2kB ROM monitor program, and graduated to all kinds of OS's, including FLEX and OS-9 (both 6800/68000 based), CP/M (8080/Z80), and MS-DOS among others, so I am no stranger to the command-line. However, I have been using Windows for more years than I care to think about.
During those years, I have from time to time made an attempt become familiar with (or even convert to ) Linux, but without success. I believe that is because I always concentrated too much on the GUI/Window-manager. This time, I am attempting to learn Linux from the ground up, using only the command-line (no GUI.)
With that in mind, and since this topic is about startup/shutdown scripts, how would I configure Salix to boot into multiuser command-line mode (run level 3,) rather than the current windowed default of run level 4?
In /etc/inittab, I see the lines:
Code: Select all
# Default runlevel. (Do not set to 0 or 6)
id:4:initdefault:
Code: Select all
# Default runlevel. (Do not set to 0 or 6)
id:3:initdefault:
Real men don't systemd.
Friends don't let friends systemd.
Friends don't let friends systemd.
Re: ethtool and rc.d scripts
No, that's all it takes.mobius wrote: ↑28. Jul 2018, 19:04 In /etc/inittab, I see the lines:which I presume I would change to:Code: Select all
# Default runlevel. (Do not set to 0 or 6) id:4:initdefault:
But are there any other changes required?Code: Select all
# Default runlevel. (Do not set to 0 or 6) id:3:initdefault:
Re: ethtool and rc.d scripts
These are the right settings. The terms for this are very different on the various computers. On the machine I'm using right now, the property is called Power-on Source and can be set to BIOS Controlled or ACPI Controlled. It's not possible to switch off. In some other BIOS, you can only choose between On and Off.[...] but do have enabled Wake-on-PCI and Wake-on-PCIE, the only settings that seem remotely related.
On the topic Wake on LAN you will find in Wikipedia, among others, the following text:Before installing Salix, this computer had Windows installed, and WOL always worked without issue.
(Quote)
Respond to the Magic Packet and restore full power
Most WoL hardware functionally is typically blocked by default and needs to be enabled in using the system BIOS. Further configuration from the OS is required in some cases, for example, via Device Manager network card properties on Windows Operating systems. More below.
(Omission)
Linux
Wake-on-LAN support may be changed using a subfunction of the ethtool command.
(Quote end) Source https://en.wikipedia.org/wiki/Wake_on_LAN
From the omission can also be seen why it works with Windows automatically.
Well that can be checked. IfNo network manager in use, as far as I know (see more below.)
Code: Select all
ps ax | grep -i networkmanager | grep -v grep
ps ax | grep -i nm | grep -v grep
ps ax | grep -i wicd | grep -v grep
That's okay.id:3:initdefault:
Everything is done.But are there any other changes required?
Runlevel 3 can also be approached differently. Runlevel 4 in inittab is left.
For permanent use, a three is written to the append line in lilo.conf.
e.g.
Code: Select all
append="3 quiet vt.default_utf8=1 ..."
For temporary use, "Salix 3" is written to the kernel command line and also reaches runlevel 3.
In SalixLive, the kernel label might be different than Salix - I do not know.
Change: The shown usage of "sudo /usr/bin/echo -n LAN > /proc/acpi/wakeup" does not work with sudo. Rather, the user must be really supersuer. Because this example is not suitable for anyone interested, it has been removed.
Last edited by galmei on 31. Jul 2018, 02:40, edited 1 time in total.
Re: ethtool and rc.d scripts
What seems puzzling, is that with Linux (some/all distributions?,) one can turn on WoL, but it will once again become disabled after reboot. After much googling, it seems that the solution is simply to re-enable in a startup/shutdown script after each boot. This now appears to be working fine for me, so as to why it happens, I leave it to those far more knowledgeable than myself.galmei wrote: ↑30. Jul 2018, 01:34(Quote end) Source https://en.wikipedia.org/wiki/Wake_on_LAN
From the omission can also be seen why it works with Windows automatically.
There is a process running: /usr/sbin/NetworkManager, but neither of the other two.Well that can be checked. IfNo network manager in use, as far as I know (see more below.)shows no output, then none of the named network managers will run either.Code: Select all
ps ax | grep -i networkmanager | grep -v grep ps ax | grep -i nm | grep -v grep ps ax | grep -i wicd | grep -v grep
To this point, I haven't yet looked at lilo at all, though I have tinkered a bit with grub.Runlevel 3 can also be approached differently. Runlevel 4 in inittab is left.
For permanent use, a three is written to the append line in lilo.conf.
That's an interesting command. In my case, the relevant line is:Here's something to play or tinker:
The wake-on functionality can be switched on and off in /proc instead of using ethtool. For this one must apply for the preparation once:The relevant excerpt from the output on my computer looks like this:Code: Select all
lspci
On the far left is the mandatory part of the slot specification. This consists of bus:device.function. Before that, there may be an optional 'domain:' term. Then one uses also once for preparation:Code: Select all
00:14.0 Bridge: NVIDIA Corporation MCP51 Ethernet Controller (rev a3)
Code: Select all
02:00.0 Ethernet controller: Qualcomm Atheros AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0)
Here, my list shows 22 entries, but none have "02:00.0" (none have "02:" at all.) They all have S-state S4. The only ones (several of them) which show "enabled," all have names containing "USB," with the exception of this line:In the output, look for the line in which the slot information can be found. On my computer the relevant excerpt is, shown along with the column headings:Code: Select all
cat /proc/acpi/wakeup
The Device column contains the device name. This name will be used later. The device names come from the BIOS's Differentiated System Description Table (DSDT) and can be arbitrarily assigned by the manufacturers. They therefore often differ completely from manufacturer to manufacturer. The next column shows from which S-state the LAN adapter can revive the computer. Here it is S4. The status is displayed as disabled.Code: Select all
Device S-state Status Sysfs node LAN S4 *disabled pci:0000:00:14.0
Code: Select all
PS2K S4 *enabled pnp:00:07
Real men don't systemd.
Friends don't let friends systemd.
Friends don't let friends systemd.