> 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. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
