/etc/init.d/(halt|reboot) disables WoL

Bug #71418 reported by Bernhard Schmidt
36
This bug affects 5 people
Affects Status Importance Assigned to Milestone
sysvinit (Debian)
Fix Released
Unknown
sysvinit (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

/etc/init.d/halt and /etc/init.d/reboot use "-i" as argument. This disables the networking interfaces and renders WoL-settings unusable (at least on my board, ASUS M2N-E with nvidia forcedeth). After removal of the parameter and setting the right WoL modus with ethtool I'm able to wake-up my box from standby.

That flag should either be omitted by default or there should be a way to configure it outside the actual initscript.

Revision history for this message
AlastairP (alastairp) wrote :

A big thank you to the chap who logged this!

I've been struggling for the last six months or more to wake my Mythtv backend from my frontend and was just about to order a new motherboard when I found this bug.
(My motherboard is an Asus P5b-VM with a Realtek on board NIC).

Since making this change it now wakes up nicely. I just need to work out how to disable the R8169 driver now and replace it with Realtek's own R8168 driver.

Please can I add my voice to those requesting this bug to be fixed?

Many thanks...

Alastair

Revision history for this message
John Cass (johnpcass) wrote :

Unfortunately removing the -i argument from the halt script doesnt help me, Ubuntu still powers down the ethernet card disabling wake on lan
;-(

John

Revision history for this message
Michael Rivera (rivera) wrote :

I can confirm, that removing that "-i" from the script worked for me too.
Using 7.10 on DELL OptiPlex GX620.

Thanks Bernhard!

Daniel T Chen (crimsun)
Changed in sysvinit:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Reinhard Tartler (siretart) wrote :

at least in intrepid, it seems that you can set this in /etc/default/halt:

NETDOWN=no

what's the reason to not default this to 'no'? currently it defaults to yes, but this seems to break iscsi and wol.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

See also https://bugs.edge.launchpad.net/upstart/+bug/92685

My opinion is that the halt and reboot tools should not down interfaces.

Revision history for this message
Reinhard Tartler (siretart) wrote :

12:57:51 < siretart> Keybuk: if you have a minute, could you have a look and give your opinion on bug #71418 please?
12:57:52 < ubottu> Launchpad bug 71418 in sysvinit "/etc/init.d/(halt|reboot) disables WoL" [Low,Confirmed]
                   https://launchpad.net/bugs/71418
12:58:50 < ogra> grmbl ... doesnt work for pushed changes indeed :/
12:59:05 < Keybuk> siretart: my opinion can be found at https://bugs.edge.launchpad.net/upstart/+bug/92685 already ;)
12:59:06 < ubottu> Ubuntu bug 92685 in upstart "noisy halt if /proc/ide doesn't exist" [Wishlist,Invalid]
12:59:15 < Keybuk> "both downing drives and interfaces should be things the kernel does these days"
13:00:30 < siretart> Keybuk: I read this as agreement that the NETDOWN variable should default to 'no'. right?
13:00:50 < Keybuk> siretart: no, I'll just take the -i option out of reboot one day so it won't matter what the NETDOWN variable is :p
13:00:55 < Keybuk> it's too late to change that variable for intrepid anyway
13:02:12 < siretart> Keybuk: I still don't get how removing the '-i' can potentially harmful. could you elaborate a bit?
13:03:03 < Keybuk> siretart: the fact you don't understand why it is yes is precisely the reason it shouldn't be changed this late in a
                   cycle
13:03:20 < Keybuk> *I* don't understand why it is yes either
13:03:25 < Keybuk> but clearly someone felt it was important
13:03:47 < Keybuk> and since it has always been yes, that means by changing it, you may turn up new bugs
13:04:52 < siretart> so lets set it to yes after jaunty opens and see what breaks?
13:08:16 < Keybuk> siretart: that would be my choice

Changed in sysvinit:
status: Unknown → Fix Released
Revision history for this message
MMlosh (mmlosh) wrote :

Removing "-i" does not help me..
it was here in Hardy too and it was OK.
In Intrepid there is no difference. Network card is shut down if "-i" is used or not.

"man halt" says this: " On Linux, this is unnecessary as the kernel will do this anyway."
But this sentence was in Hardy too..

Revision history for this message
Reinhard Tartler (siretart) wrote :

Keybuk, would now be a good time to do the change and remove the "-i" parameter in jaunty?

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

I'm suffering from this problem too, but removing the "-i" does not seem to help.

I think this problem might be solved in a different way. What about adding a line (and the requisite parsing) in the /etc/network/interfaces file to configure WoL on/off?

Something like:

/etc/network/interfaces
-----------------------------------------------------
# The primary network interface
auto eth0
iface eth0 inet dhcp
wakeonlan $X
-----------------------------------------------------

Where $X is one of:
        p|u|m|b|a|g|s|d...
               p Wake on phy activity
               u Wake on unicast messages
               m Wake on multicast messages
               b Wake on broadcast messages
               a Wake on ARP
               g Wake on MagicPacket(tm)
               s Enable SecureOn(tm) password for MagicPacket(tm)
               d Disable (wake on nothing). This option clears all previous
                  options.
See:
 * http://manpages.ubuntu.com/manpages/jaunty/en/man8/ethtool.8.html

The if-scripts would then handle sending the appropriate 'ethtool -s eth0 wol $X' command on ifup/ifdown.

I'm happy to write this code if Scott and Alexander can verify the approach.

Also, Alexander asked me in IRC if ethtool could set this value correctly even if the interface is ifconfig'd down. I have verified that the answer is "yes, it can".

:-Dustin

Revision history for this message
Tomi Hukkalainen (tpievila) wrote :

The initscript now checks the defaults file, but the defaults file itself should have at least a comment about this option. But I suppose the actual problem is now fixed and released.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.