Your message dated Sun, 04 Nov 2018 13:06:31 +0800
with message-id <[email protected]>
and subject line please talk to upstream
has caused the Debian Bug report #501351,
regarding sysvinit: halt breaks wake on lan / WOL under NFS root /diskless lenny
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
501351: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501351
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: sysvinit
Version: 2.86.ds1-61
Severity: important
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.
Previously the systems would respond to etherwake 'magic packets'. Now, they
don't. The adapters are 3c59x or e100 based, one per system. ethtool reports
wake on lan is enabled.
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. However, when the root filesystem is NFS, the system
halt doesn't do ifdown as when that is forced on under NFS root, that causes
halt to hang waiting for now-disable
d NFS to satisfy calls - this blocks halt operations forever.
So, no ifdown when NFS root means the WOL enablement bits aren't set in the
drivers -- breaking WOL.
The only way I got it to work under etch was to modify the drivers. Also there
was a problem in the binary halt distribution not calling ifdown, compling from
standard source (same version
) did work (odd, that).
But the drivers have changed quite a bit since .18 and the right place to deal
with this I think is above the driver level. What network driver routine is
always called even on NFS root s
ystems after it is certain no further kernel or userspace filesystem accesses
will occur? Either the halt routine has to change so it operates the same way
NFS root or local root, or net d
river writers need to know for sure what the last driver call will be when
powering off in an NFS root setup.
I was considering changing halt to create a tiny tempfs root file system, then
doing a pivot_root to it inside halt so ifdown could proceed. But the hack
rating was just too high.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages sysvinit depends on:
ii initscripts 2.86.ds1-61 Scripts for initializing and shutt
ii libc6 2.7-13 GNU C Library: Shared libraries
ii libselinux1 2.0.65-5 SELinux shared libraries
ii libsepol1 2.0.30-2 Security Enhanced Linux policy lib
ii sysv-rc 2.86.ds1-61 System-V-like runlevel change mech
ii sysvinit-utils 2.86.ds1-61 System-V-like utilities
sysvinit recommends no packages.
sysvinit suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
tags 501351 upstream moreinfo
thanks
Hi,
This is sad but we have to move on. Please raise this issue to the
kernel upstream. Thanks you for trusting us.
Yours,
Benda
--- End Message ---
