[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: