LinuxQuestions.org - Shutdown problem

- Linux - Hardware (https://www.linuxquestions.org/questions/linux-hardware-18/)

- - Shutdown problem - e1000 driver bug? (https://www.linuxquestions.org/questions/linux-hardware-18/shutdown-problem-e1000-driver-bug-4175643746/)

Shutdown problem - e1000 driver bug?

Hello:

My Sun Microsystems Ultra24 rig has a problem which up to now I’ve chalked up to a crap BIOS.
It happened with the previous (original) version it came with and with this one, which is the latest one available.

I'm on Devuan latest:

Code:

groucho@devuan:~$ uname -a

Linux devuan 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux

groucho@devuan:~$

Code:

[root@devuan groucho]# apt-get update

Hit:1 http://deb.devuan.org/merged ascii InRelease

Get:2 http://deb.devuan.org/merged ascii-updates InRelease [25.6 kB]

Hit:3 http://deb.devuan.org/merged ascii-security InRelease

Fetched 25.6 kB in 5s (4944 B/s)

Reading package lists... Done

[root@devuan groucho]#

Code:

[root@devuan groucho]# apt-get upgrade

Reading package lists... Done

Building dependency tree      

Reading state information... Done

Calculating upgrade... Done

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

[root@devuan groucho]#

Code:

[root@devuan groucho]# 

[root@devuan groucho]# apt-get check

Reading package lists... Done

Building dependency tree      

Reading state information... Done

[root@devuan groucho]#

This is the inxi output:

Code:

groucho@devuan:~$ inxi -b

System:    Host: devuan Kernel: 4.9.0-8-amd64 x86_64 (64 bit) Desktop: Xfce 4.12.3

          Distro: Devuan GNU/Linux ascii

Machine:  Device: portable System: Sun Microsystems product: Ultra 24 v: 0.00.01

          Mobo: Sun Microsystems model: Ultra 24 v: 50 BIOS: American Megatrends v: 1.56 date: 01/21/2011

CPU:      Quad core Intel Core2 Quad Q9550 (-MCP-) speed/max: 2003/2833 MHz

Graphics:  Card-1: NVIDIA G96GL [Quadro FX 580]

          Card-2: NVIDIA G96GL [Quadro FX 580]

          Display Server: X.Org 1.19.2 driver: nvidia Resolution: 3840x1024

          GLX Renderer: Quadro FX 580/PCIe/SSE2 GLX Version: 3.3.0 NVIDIA 340.106

Network:  Card-1: Intel 82566DM-2 Gigabit Network Connection driver: e1000e

          Card-2: Atheros TP-Link TL-WN821N v3 / TL-WN822N v2 802.11n [Atheros AR7010+AR9287]

Drives:    HDD Total Size: 697.9GB (16.0% used)

Info:      Processes: 191 Uptime: 45 min Memory: 691.0/7921.9MB Client: Shell (bash) inxi: 2.3.5 

groucho@devuan:~$

Description of the problem:

On shutdown, the rig will do one of three things:

1. shut down properly
2. shut down properly and after about 5s. reboot start reboot and freeze
3. freeze during the shutdown at this point ...

Code:

e1000e: EEE Tx LPI Timer

Preparing to enter sleep state S5

Reboot: Power Down

… with the fans blowing at full speed.

This happens ocasionally and I have not been able to reliably reproduce the behaviour, no idea what causes it.
It happened when I only had wireless access ie: before I had a wired connection and it also happens now.

Unfortunately, there’s no way of disabling the on board e1000e controller (you see, as this Sun MoBo has IME, that would be a no-no).

Could it be that (at least part of the issue) is caused by this bug:

https://sourceforge.net/p/e1000/mail...ssage/34986431

Apparently it was solved from kernel 3.16.49 on, but the behaviour is very similar.

See:
https://www.systutorials.com/linux-k...-linux-3-16-49

My power settings (Xfce Power Manager) are:

General
When power button is pressed: Shutdown
When sleep button is pressed: Do nothing
When hibernate button is pressed: Do nothing

System
System sleep mode: Suspend
Put sytem to sleep when inactive for: Never

This also happened with other distros I have tried before settling with Devuan.
Previous owner of the rig used a Gates OS but I don’t think he would have mentioned this anyway.

I have not found a way to log what is happening so as to be able to get a better idea of what is happening.

I’d appreciate any suggestions you may have as this is a real PITA.

Thanks in advance.

A.

Are there any wake-on-lan settings? If so, can you disable them?

Hello:

Quote:

Originally Posted by smallpond (Post 5934120)

Are there any wake-on-lan settings? If so, can you disable them?

GbE LAN Boot option in BIOS is disabled and Suspend option is set to S1 (POS), the other option being S3 (STR).
System sleep mode is set to 'Never' so I guess it wouldn't matter.

Thanks for your input.

A.

For logging it, run acpid with a '-l' option, which logs events to syslog. Don't presume that because you set something up in XFCE, it will happen. XFCE's power manager has the power to screw things up, but never to straighten them out, in my experience.

As for power saving states, S3 = suspend, S5 = hibernate. Sopmething is hibernating and nothing is going off directly.

Try booting with the boot parameter "resume=/dev/<your-swap-partition>", & enable hibernate. For power off, run

Code:

sudo shutdown -h now

Hello:

Quote:

Originally Posted by business_kid (Post 5934762)

For logging it, run acpid with a '-l' option, which logs events to syslog.

OK.
Do I add it to the boot string?
I expect that if I run it on a terminal it would not survive a reboot.

Quote:

Originally Posted by business_kid (Post 5934762)

... because you set something up in XFCE, it will happen.
XFCE's power manager has the power to screw things up, but never to straighten them ...

Good to know.

But I did not have Xfce's power manager installed and did so before posting to see what was going on.
After installing it, I applied the settings I mentioned previously.

As part of this even on-going search for a solution, I set the Suspend option in BIOS to S1 (POS), it was previously set at S3 (STR).

I have not had another episode since (knock on wood) but that does not mean anything: I've gone for a week or so without one, with me thinking I finally had it tied down and then it reared it's ugly head again.

Quote:

Originally Posted by business_kid (Post 5934762)

... S3 = suspend, S5 = hibernate.
Something is hibernating and nothing is going off directly.

Yes, that is exactly what was bugging me.
Where did it come from?
There was nothing set for the system to do that.

I've never been a fan of hibernating or any other thing other than a basic S1 suspend.
Not even with my netbooks, I simply don't trust it working properly.
Comes from my other life when I ran MS OSs.

But in any case, my rig is not a portable even though the BIOS IDs the it as one. (!)
That's what Oracle dining on Sun Microsystems got us all. 8^|

Code:

groucho@devuan:~$ inxi -b

System:    Host: devuan Kernel: 4.9.0-8-amd64 x86_64 (64 bit) Desktop: Xfce 4.12.3

          Distro: Devuan GNU/Linux ascii

Machine:  Device: portable System: Sun Microsystems product: Ultra 24 v: 0.00.01

          Mobo: Sun Microsystems model: Ultra 24 v: 50 BIOS: American Megatrends v: 1.56 date: 01/21/2011

CPU:      Quad core Intel Core2 Quad Q9550 (-MCP-) speed/max: 2003/2833 MHz

Graphics:  Card-1: NVIDIA G96GL [Quadro FX 580]

          Card-2: NVIDIA G96GL [Quadro FX 580]

          Display Server: X.Org 1.19.2 driver: nvidia Resolution: 3840x1024

          GLX Renderer: Quadro FX 580/PCIe/SSE2 GLX Version: 3.3.0 NVIDIA 340.106

Network:  Card-1: Intel 82566DM-2 Gigabit Network Connection driver: e1000e

          Card-2: Atheros TP-Link TL-WN821N v3 / TL-WN822N v2 802.11n [Atheros AR7010+AR9287]

Drives:    HDD Total Size: 697.9GB (17.4% used)

Info:      Processes: 189 Uptime: 3:47 Memory: 1269.6/7921.9MB Client: Shell (bash) inxi: 2.3.5 

groucho@devuan:~$

Thanks for your input.

Cheers,

A.

Hello:

Just an update.

Quote:

Originally Posted by Altoid (Post 5934792)

... that does not mean anything: I've gone for a week or so without one ...

It's reared it's ugly head again.

So it seems it's not the 'Suspend' setting in BIOS ie: S1 or S3 that can affect this issue.
The problem exists with either setting.

Cheers,

A.

Hello:

A further update:
I've made some headway and managed to configure ACPID -l at boot in etc/default/acpid.

Code:

# Options to pass to acpid

#

# OPTIONS are appended to the acpid command-line

# enabled 20181108 to log events to syslog 

OPTIONS="-l"

#

# Linux kernel modules to load before starting acpid

#

# MODULES is a space separated list of modules to load, or "all" to load all

# acpi drivers, or commented out to load no module

#MODULES="battery ac processor button fan thermal video"

#MODULES="all"

Now syslog says:

Code:

Dec 8 18:23:32 devuan acpid: waiting for events: event logging is on

So now I guess I can expect that the next time I get the freeze something should get logged in syslog.
Hopefully the entry will tell me what is calling for S5 in a rig that has anything S5 related turned off.

I'll have to wait for the next one and see what it is.

Cheers,

A.

Quote:

As part of this even on-going search for a solution, I set the Suspend option in BIOS to S1 (POS), it was previously set at S3 (STR).

I think that (S1) - Standby. The fans and all stay running. Pretty useless setting if you ask me. Have you looked at power settings in the BIOS?

Hello:

Quote:

Originally Posted by business_kid (Post 5935026)

Have you looked at power settings in the BIOS?

Yes.
Power Management is set to 'Disabled', Power Button Mode is set to 'On/Off'.

As I don't leave my rig on all day (if I'm not using it) day or leave the screen more than 10', I don't think it matters much if my setting is S1 or S3, but I understand your point.

Now to see what is wanting to go S5 on me instead of shutting down and why.
Where else can I look?

Thanks for your input.

Cheers,

A.

S5 is actually good, as long as you reboot the same kernel, and everything stands up S5 = off.

Hello:

Quote:

Originally Posted by business_kid (Post 5935168)

S5 is actually good, as long as you reboot the same kernel ...

I'll look into S5 as soon as I get this one figured out.

I may have made some headway.

By looking at the /var/log I found there is a pm-powersave.log, so I checked it for eth0 activity.
Sure enough:

Code:

groucho@devuan:~$ cat /var/log/pm-powersave.log | grep -i eth0

Setting Wake On Lan for eth0 to enable...Done.

--- snip ---

Setting Wake On Lan for eth0 to enable...Done.

groucho@devuan:~$

No time stamps but from the look of it, it's once at every boot.
There's a script somewhere that enables WoL but where?

With further searches on the web I found this:

https://wiki.archlinux.org/index.php/Wake-on-LAN
And in that page I found a very interesting bit:

Quote:

Originally Posted by Link

"Note that some motherboards are affected by a bug that can cause immediate or random #Wake-up after shutdown whenever the BIOS WoL feature is enabled."

With a follow up down below:

Quote:

Originally Posted by Link

Troubleshooting
Wake-up after shutdown

It is known that some motherboards are affected by a bug that can cause immediate or random wake-up after a shutdown whenever the BIOS WoL feature is enabled (as discussed in this thread for example). The following actions in the BIOS preferences can solve this issue with some motherboards:

1. Disable all references to xHCI in the USB settings (note this will also disable USB 3.0 at boot time)
2. Disable EuP 2013 if it is explicitly an option
3. Optionally enable wake-up on keyboard actions

Note: There are mixed opinions as to the value of #3 above and it may be motherboard dependent.

So the culprit is as I thought a motherboard/BIOS bug but in combination with WoL being enabled.

WRT to the options listed above, #1 won't do as I use USB a lot, #2 is not explicitly an option as my rig is from 2007 and does not have that and with #3, if my rig ever goes into S1 it wakes up with the kb/mouse so it is already enabled.

As I do not need or want WoL, I decided that the best was to disable it.
Which will also keep the motherboard bug from cropping up.

rant
It really nags me that it is enabled. Why is it enabled and who enabled it?
/rant

To check the e1000e driver settings, I used ethtool, which I only now found out about.

Code:

[root@devuan groucho]# ethtool eth0

Settings for eth0:

        Supported ports: [ TP ]

        Supported link modes:  10baseT/Half 10baseT/Full 

                                100baseT/Half 100baseT/Full 

                                1000baseT/Full 

        Supported pause frame use: No

        Supports auto-negotiation: Yes

        Advertised link modes:  10baseT/Half 10baseT/Full 

                                100baseT/Half 100baseT/Full 

                                1000baseT/Full 

        Advertised pause frame use: No

        Advertised auto-negotiation: Yes

        Speed: 100Mb/s

        Duplex: Full

        Port: Twisted Pair

        PHYAD: 1

        Transceiver: internal

        Auto-negotiation: on

        MDI-X: off (auto)

        Supports Wake-on: pumbg

        Wake-on: g

        Current message level: 0x00000007 (7)

                              drv probe link

        Link detected: yes

[root@devuan groucho]#

Just like the log file says, WoL is enabled, and ethtool can be used to set the WoL parameters:

Code:

# ethtool -s interface wol [x]

The possible settings for x are:

d (disabled)
p (PHY activity)
u (unicast activity)
m (multicast activity)
b (broadcast activity)
a (ARP activity)
g (magic packet activity). <---- this being set by the driver, it is needed for WoL to work.

MagicPacket ...
Just the name makes me uneasy.

To disable it I run the command with the 'd' option:

Code:

# ethtool -s eth0 wol d

Code:

[root@devuan groucho]# ethtool -s eth0 wol d

[root@devuan groucho]#

An then check the result ...

Code:

[root@devuan groucho]# ethtool eth0

Settings for eth0:

        Supported ports: [ TP ]

        Supported link modes:  10baseT/Half 10baseT/Full 

                                100baseT/Half 100baseT/Full 

                                1000baseT/Full 

        Supported pause frame use: No

        Supports auto-negotiation: Yes

        Advertised link modes:  10baseT/Half 10baseT/Full 

                                100baseT/Half 100baseT/Full 

                                1000baseT/Full 

        Advertised pause frame use: No

        Advertised auto-negotiation: Yes

        Speed: 100Mb/s

        Duplex: Full

        Port: Twisted Pair

        PHYAD: 1

        Transceiver: internal

        Auto-negotiation: on

        MDI-X: off (auto)

        Supports Wake-on: pumbg

        Wake-on: g                          

        Current message level: 0x00000007 (7)

                              drv probe link

        Link detected: yes

[root@devuan groucho]#

It did not stick.

I check the log again and there's no trace of my attempt.
The last entry is the same as above:

Code:

groucho@devuan:~$ cat /var/log/pm-powersave.log | grep -i eth0

Setting Wake On Lan for eth0 to enable...Done.

groucho@devuan:~$

Then I found a page with some info on this:

https://serverfault.com/questions/54704/how-to-get-ethtool-wake-on-lan-setting-to-st[quote=link]ick

It says:

Quote:

Originally Posted by link

You could use /etc/rc.local or some system boot scripts, but this wouldn't be the best way to do it. On startup your network interfaces are configured, sure, but there are other times when your network interfaces may be brought up or down and you will need this executed during those times.

You want to edit /etc/network/interfaces:

You should have a line like:

iface eth0 inet static

Underneath that, indented further, you want to create a post-up and post-down commands e.g.

iface eth0 inet static
post-up /usr/sbin/ethtool -s eth0 wol g
post-down /usr/sbin/ethtool -s eth0 wol g

Obviously, replace eth0 with the relevant interface if different.

See interfaces(5) for more information on post-up and post-down commands

I go look at /etc/network/interfaces:

Code:

groucho@devuan:~$ cat /etc/network/interfaces

auto lo

iface lo inet loopback

groucho@devuan:~$

But it is different and there's no mention of eth0.
So what to do now?

Where is the script that enables WoL, as reported by pm-powersave.log?
If I could set that to disabled it may be the solution to all this.

Thanks in advance,

A.

Quote:

No time stamps but from the look of it, it's once at every boot.
There's a script somewhere that enables WoL but where?

Wake on Lan, & Wake on Keyboard can be disabled in the BIOS, and should be if they're causing issues. It's only the Bios can wake on keyboard or lan, and then simply to boot.

Once acpid is running, The scripts for events should be in /etc/acpi; there's 'events', & 'scripts' which should be two subdirs. It's a "kneebone connected to the thigh bone connected . . " type of thing. Bios events point at scripts which do stuff.

Hello:

Quote:

Originally Posted by business_kid (Post 5935422)

Wake on Lan, & Wake on Keyboard can be disabled in the BIOS ...

In my Sun Microsystems Ultra24 BIOS I have Gbe Lan Boot 'disabled' and there's no Wake on Keyboard option available.

And like I mentioned in an earlier post, the Gbe controller is hard wired to 'Enabled'.
I think it is related to the IME.

Quote:

Originally Posted by business_kid (Post 5935422)

... only the Bios can wake on keyboard or lan ...

Makes sense but ...

For whatever reason, now I can (don't have a clue as to why it did not work before) set the e1000e WoL to disabled, but it does not survive a reboot:

Code:

[root@devuan groucho]# ethtool eth0

Settings for eth0:

        Supported ports: [ TP ]

        Supported link modes:  10baseT/Half 10baseT/Full 

                                100baseT/Half 100baseT/Full 

                                1000baseT/Full 

        Supported pause frame use: No

        Supports auto-negotiation: Yes

        Advertised link modes:  10baseT/Half 10baseT/Full 

                                100baseT/Half 100baseT/Full 

                                1000baseT/Full 

        Advertised pause frame use: No

        Advertised auto-negotiation: Yes

        Speed: 100Mb/s

        Duplex: Full

        Port: Twisted Pair

        PHYAD: 1

        Transceiver: internal

        Auto-negotiation: on

        MDI-X: off (auto)

        Supports Wake-on: pumbg

        Wake-on: g

        Current message level: 0x00000007 (7)

                              drv probe link

        Link detected: yes

[root@devuan groucho]#

Code:

[root@devuan groucho]# ethtool -s eth0 wol d

[root@devuan groucho]#

Code:

[root@devuan groucho]# ethtool eth0

Settings for eth0:

        Supported ports: [ TP ]

        Supported link modes:  10baseT/Half 10baseT/Full 

                                100baseT/Half 100baseT/Full 

                                1000baseT/Full 

        Supported pause frame use: No

        Supports auto-negotiation: Yes

        Advertised link modes:  10baseT/Half 10baseT/Full 

                                100baseT/Half 100baseT/Full 

                                1000baseT/Full 

        Advertised pause frame use: No

        Advertised auto-negotiation: Yes

        Speed: 100Mb/s

        Duplex: Full

        Port: Twisted Pair

        PHYAD: 1

        Transceiver: internal

        Auto-negotiation: on

        MDI-X: off (auto)

        Supports Wake-on: pumbg

        Wake-on: d

        Current message level: 0x00000007 (7)

                              drv probe link

        Link detected: yes

[root@devuan groucho]#

So that's one problem solved. =-)
But if it does not survive a reboot it is because it is being set to 'g' again at boot time or at log-in time.

Now, the thing is to make it stick, an issue with which I am not alone as the post I linked to previously seems to indicate.

After looking at the pm-powersave.log file I looked for scripts that could be working against my intention of shutting down WoL for good, so to speak.

And I came across the directory /usr/lib/pm-utils/power.d.

Code:

groucho@devuan:~$ ls /usr/lib/pm-utils/power.d

95hdparm-apm  disable_wol    laptop-mode  pcie_aspm  sched-powersave  wireless

anacron      intel-audio-powersave  pci_devices  sata_alpm  usb_bluetooth    xfs_buffer

groucho@devuan:~$

Interesting ...

Code:

groucho@devuan:~$ cat /usr/lib/pm-utils/power.d/disable_wol

#!/bin/sh



. "${PM_FUNCTIONS}"



command_exists ethtool || exit $NA



set_wol_status() {

    for d in "/sys/class/net/"*; do

        [ -e "$d/wireless" ] && continue

        [ -h "$d/device/driver" ] || continue

        printf "Setting Wake On Lan for %s to %s..." "${d##*/}" "$1"

        case $1 in

            disable) ethtool -s "${d##*/}" wol d>/dev/null 2>&1;;

            enable) ethtool -s "${d##*/}" wol g>/dev/null 2>&1;;

        esac

        [ "$?" -eq 0 ] && echo Done. || echo Failed.

    done

}



case $1 in

    true) set_wol_status disable;;

    false) set_wol_status enable;;

    *) exit $NA;;

esac



exit 0

groucho@devuan:~$

I'm not well versed in bash but I think that this script can either enable or disable Wol and it will do it according to the setting of a flag somewhere ie: true) set_wol_status disable or false) set_wol_status enable.

That flag (wherever it is located) is now set to 'false'.

One thing I could do is simply make the script non-executable and see what happens but for linux/bash literacy's sake, I'd really like to find out just what makes this script tick. ie: where the damn 'false' flag is located.

I cannot make heads or tails of this disable_wol script and I have not found anything I could see had 'true' or 'false' in /sys/class/net/.

¿Does it say where the flag is?

Thanks in advance.

Cheers,

A.

Quote:

Originally Posted by Altoid

For whatever reason, now I can (don't have a clue as to why it did not work before) set the e1000e WoL to disabled, but it does not survive a reboot:

A reboot gives it a software reset. I don't know your machine, but I'm surprised there's no way to disable wake on lan. How do others with your M/B handle this? It definitely seems to be arguing a M/B & Bios argument, and you're stuck in the middle. Let's hope you don't end up having to humour it with a tftp server :-/.

Hello:

Quote:

Originally Posted by business_kid (Post 5935782)

A reboot gives it a software reset. I don't know your machine, but I'm surprised there's no way to disable wake on lan.

I'm not: the on-board Gbe controller cannot be disabled, the option is available but shaded out. (!)
I don't now if other workstation type rigs have the same setup, but the Sun Microsystems Ultra24 does.

Like I've mentioned earlier, I think this is tied to the presence IME on the board.
I've shut it down but (as I've read in a few places) it does not and that would be coherent with not being able to disable WoL on this board.

Quote:

Originally Posted by business_kid (Post 5935782)

How do others with your M/B handle this?

No idea ...
But I've found a solution, actually a temporary workaround.

Searching around, I came across this very informative page:

https://wiki.debian.org/WakeOnLan

Among other things, it says:

"Hardware
--- snip ---
Recent motherboards with onboard NICs support Wake On LAN without the need for any pins/cables."

"Firmware / BIOS
In a nice BIOS under power management you will have a clear, intuitive option labeled "Wake On LAN". Unfortunately my system wasn't so clear and has a couple options available."

See, you have to have a nice BIOS.
Not my case or the OP's.

The fellow/s who wrote this up document an issue with how PM-Utils works:

"PM-Utils Conflicts
The pm-utils package contains scripts that are run on suspend, hibernate and on resume of the system. There is one script, /usr/lib/pmutils/power.d/disable_wol, which sets the configuration for interfaces to only wake on "Magic Packet" (g), regardless of the settings you may have configured in /etc/network/interfaces (or one of the files under /etc/network/interfaces.d, or manually using ethtool or in some other way). Look for lines in the file similar to the following:

disable) ethtool -s "${d##*/}" wol d>/dev/null 2>&1;;
enable) ethtool -s "${d##*/}" wol g>/dev/null 2>&1;;

Obviously, if you have set an interface to Wake on LAN in the event of a unicast packet or "Magic Packet" (ug), then suspend using pm-suspend, for example, this script will set the interface to "Magic Packet" only (g) as part of the suspension process.

---
Note:
As you can surely gather, this guy does not know how to make the disable_wol script run with a 'true' flag.
ie: for different reasons, has the same problem I do.
---

You can detect the problem, once you know what you're looking for, by noticing through ethtool after a resume that the "Wake-on" settings for interfaces have been set to "g".

A simple fix (that will not interfere with package updates) is to add a file with the same name, disable_wol to the local configuration directory, /etc/pm/power.d/. This overrides the script in /usr/lib/pm-utils/power.d/disable_wol."

From this write-up I learned two things:

1. PM-Utils runs the /usr/lib/pmutils/power.d/disable_wol script on suspend/resume/hibernate, everytime.
2. As it is run everytime, it overrides any setting you've put in place previously.

I did not have PM-Utils installed in my default Devuan setup and installed it to investigate the shutdown problem as I did not have an interface to check the settings.

What I did was copy the /usr/lib/pmutils/power.d/disable_wol script to the local configuration directory, /etc/pm/power.d/ and modified it so that when it is run it will disable WoL whether the flag (wherever it is) is set to 'true' or 'false'.

Code:

    disable) ethtool -s "${d##*/}" wol d>/dev/null 2>&1;;

    enable) ethtool -s "${d##*/}" wol d>/dev/null 2>&1;;

This works prefectly well for the time being and will survive any update of PM-Utils.

I could uninstall PM-Utils but the motheorboard bug/WoL combination that caused the reboot on shutdown issue that prompted this thread was already there before I installed it so it is evident that WoL was being set without PM-Utils intervention.

I still don't know where the 'true'/'false' setting is.
ie: what is telling the disable_wol that the flag is 'false'.

Any ideas?

Thanks for your input.

Cheers,

A.