Bug#499833: chccwdev cannot set device offline in Lenny
> You always showed direct usage of /sys.
Yes. But since "echo" with redirection was no longer working, I thought maybe
the procedure had changed. To make sure, I invoked
chccwdev -d 0.0.0201
I figured that if the procedure had changed, chccwdev would know the new
way to get the device offline. But it didn't work either. Now I had a
failure that I could tie to a specific package. The utility reported that
it had set the device offline, but
cat /proc/dasd/devices
showed that it was still online.
> /sys/bus/ccw/devices/0.0.0302# cat online
> 0
> /sys/bus/ccw/devices/0.0.0302# echo 1 > online
> /sys/bus/ccw/devices/0.0.0302# cat online
> 1
> /sys/bus/ccw/devices/0.0.0302# mount /boot302
> /sys/bus/ccw/devices/0.0.0302# umount /boot302
> /sys/bus/ccw/devices/0.0.0302# cat online
> 1
> /sys/bus/ccw/devices/0.0.0302# echo 0 > online
> /sys/bus/ccw/devices/0.0.0302# cat online
> 0
> /sys/bus/ccw/devices/0.0.0302# uname -a
> Linux waldi02.zseries.org 2.6.26-1-vserver-s390x #1 SMP Wed Sep 10 22:54:59
UTC 2008 s390x GNU/Linux
Yes, I know the procedure. And it used to work. But then it quit working
at some point. But today's new packages and package upgrades seem to have
solved the problem. I don't know why. There was no kernel upgrade.
I don't know if it was an upgrade to an existing package or a new package
that solved the problem.
> Take a look at /var/log/dpkg.log, I expect udev and/or
> sysconfig-hardware.
Here is the complete list of new packages and package upgrades from today
that somehow fixed the problem. This information is from /var/log/dpkg.log.
Unfortunately, no distinction is made between new packages and updated
packages, as far as I can tell. I know that I already had some version
or other of some of these packages. For example, gcc, libc6-dev, and make
I know were already installed.
binutils 2.18.1~cvs20080103-7
bzip2 1.0.5-1
libgomp1 4.3.1-9
gcc-4.3 4.3.1-9
gcc 4:4.3.1-2
linux-libc-dev 2.6.26-5
libc6-dev 2.7-13
linux-source-2.6.26 2.6.26-5
make 3.81-5
libstdc++6-4.3-dev 4.3.1-9
g++-4.3 4.3.1-9
g++ 4:4.3.1-2
libtimedate-perl 1.1600-9
dpkg-dev 1.14.22
build-essential 11.4
gettext 0.17-3
intltool-debian 0.35.0+20060710.1
po-debconf 1.0.15
kernel-package 11.001-0.1
libcompress-raw-zlib-perl 2.012-1
libio-compress-base-perl 2.012-1
libio-compress-zlib-perl 2.012-1
libcompress-zlib-perl 2.012-1
libdigest-sha1-perl 2.11-2+b1
libdigest-hmac-perl 1.01-7
libfile-remove-perl 1.42-1
libio-stringy-perl 2.110-4
libmime-types-perl 1.24-1
libmailtoolsperl 2.03-1
libobject-realize-later-perl 0.18-1
liburi-perl 1.35.dfsg.1-1
libuser-identity-perl 0.92-2
libmail-box-perl 2.082-2
libsys-hostname-long-perl 1.4-2
libmail-sendmail-perl 0.79-5
libncurses5-dev 5.6+20080830-1
Incidentally, after yesterday's "aptitude update" followed by
"aptitude dist-upgrade", the one and only network device (other than lo)
was not recognized upon reboot. I found nothing on the Debian site
about this. By searching the Internet, I eventually found that erasing
the file /etc/udev/rules.d/70-persistent-net.rules and rebooting
solved that problem. This is not germane to this particular bug unless
my solution to that problem somehow caused this one. But I doubt it.
The file in question was regenerated upon reboot, but the regenerated
version of the file did not assign a false MAC address to eth0.
--
Reply to: