[Pkg-sysvinit-devel] Bug#501351: Bug#501351: sysvinit: halt breaks wake on lan / WOL under NFS root /diskless lenny

[Harry Coin]

Petter Reinholdtsen wrote:
> [Harry Coin]
>   
>> Upgrading to lenny from etch has broken wake on lan after 'poweroff'
>> on our many Dell Optiplex headless /diskless systems.  All packages
>> are latest lenny/testing as of 6 October 2008.
>>     
>
> This is sad.
>   
Yes.
>   
>> Looking at the code I see that the latest network drivers always
>> disable WOL after ifup and before ifdown. Then, either at driver
>> unload time or ifdown time they set the WOL bit in hardware
>> according to option.
>>     
>
> It the kernel drivers behavior with respect to wake-on-lan defined
> somewhere?  As I see this, the kernel drivers have no consistent
> interface to userspace, and thus make it impossible to solve this in a
> reliably way in userspace. 
Because 'halt' has kernel-feeling options to block or do 'ifdown' and 
block or do 'disk sync', its authors must be part of the answer.   Long 
term my suggestion is both those options seem to be things the kernel 
filesystem and storage drivers should do on its way to orderly 
ending/rebooting and they properly shouldn't be part of userspace halt.

But since they are at present and since halt is the program that hangs 
when doing the right thing (asking for ifdown to set WOL) I am asking 
halt authors to engage the correct kernel maintainers to decide either 
the kernel and network driver authors must take responsibility to down 
the interface or call shutdown routines even when NFS root just before 
poweroff happens, or userspace drivers must pivot_root off the nfs root 
to a tempfs system and down the interface before calling for a system 
poweroff.   As it is, network drivers engage WOL options when downing 
the interface (though I worry some do it in the .shutdown routine).

Anyone can reproduce this problem: set up a NFS root system then try 
poweroff using and not using halt's ifdown option.  When choosing ifdown 
option, you will see halt hang just before poweroff waiting for a 
response from the NFS server that will never come because ifdown has 
happened.  In this case WOL is set in the adapters but because halt 
never actually turns the system off and never exits -- having WOL turned 
on is of no importance.  The system is effectively hung until a physical 
reboot.   In the other case,  leaving halt's ifdown option not chosen 
when using NFS root will allow halt to exit normally, but the network 
drivers routines that set the WOL bit never get called by the kernel, so 
WOL is broken although the system is turned off.


>  This make it the responsibility of the
> kernel drivers and the kernel space to come up with a solution.  If
> there is a definition on how the kernel drivers should behave, and
> user space applications can depend on this definition during shutdown,
> we can discuss how to solve this in sysvinit.  Until such definition
> show up, I have no idea how to solve this issue reliably.
>
> Please let us know how the kernel decided to handle wake-on-lan in
> network drivers, if such decision exist.
>
>   
I am asking the halt authors to forward this bug to the correct people 
since your ideas about who they are must be better than mine.

> Happy hacking,
>   

Not so much as I hope! Upgrades near release like Lenny are not supposed 
to break basic things.   The effect of this problem is wasteful usage of 
energy keeping systems that have no work to do nevertheless powered up.