Hi, Bastien. > I fail to see what s390-tools or the chccwdev tools have to do with this > problem.
It's possible that I may have reported this bug against the wrong package. chccwdev is part of the s390-tools package. And chccwdev fails. But the actual cause of the problem may be elsewhere. As my previous update indicates, I don't think that there's a problem with the code itself, but with the packaging. There appears to be a missing dependency somewhere. Maybe the dependency is missing in Etch too. But because I had the needed package installed in Etch, it worked. > Just to be curious, why do operate it in diag mode then? /boot is not > used in normal operation. True. I created a file in /etc/modprobe.d, which I called dasd, which looks like this: options dasd_mod dasd=0.0.0200-0.0.0203(diag) It was simpler just to tell diag to run everything. Then I ran "update-initramfs -u", followed by "shutdown -r now", and the DIAG driver took over everything upon reboot. (The linux instance uses only the four DASD devices listed above.) At the time, I didn't realize that zipl wouldn't work with the DIAG driver. I eventually got tired of switching back and forth whenever I needed to run zipl and changed the /etc/modprobe.d/dasd file to look like this: options dasd_mod dasd=0.0.0200(diag),0.0.0201,0.0.0202-0.0.0203(diag) Now I don't need to switch anymore. But there are other situations where I need to take devices online and offline dynamically. > Lenny have 2.6.26-5. Today, yes. But at one point in the evolution of Lenny it was using a 2.6.24 kernel. I haven't updated this server in several months. As a previous update indicates, I upgraded to the latest kernel, but it did not solve the problem. The problem was solved only after a bunch of new packages were installed. Which package resolved the hidden dependency I do not know. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
