Grzegorz, I have been working with Novell to fix these problems. Novell has resolved the problems and is putting the final touches on a PTF s390-tools package that contains a /sbin/zfcp_disk_configure script without these problems. You can probably get an advance copy, before the maintenance release, through your support process.
Mike O'Reilly IBM Linux Change Team Grzegorz Powiedziuk <gpowiedziuk@gmai To l.com> LINUX-390@vm.marist.edu, Sent by: Linux on cc 390 Port <linux-...@vm.mar Subject ist.edu> SLES11 - zfcp_disk_configure bug? (Could not deactivate SCSI disk) 05/15/2012 10:32 AM Please respond to Linux on 390 Port <linux-...@vm.mar ist.edu> Hi, I have small problem and tiny workaround for it. I am wondering if anyone else had issues like this. Sometimes (actually quite often), Yast complains when I try to deactivate a scsi disk. (yast->hardware->zfcp>delete) with message "Could not deactivate SCSI disk"). Unfortunately it is being removed from from Yast LUNs list so at this point there is not much I can do from Yast. Yast would not allow me to recreate it because under the hood (/sys/bus/ccw...) it wasn't completely removed. I walked through Yast logs and than through /sbin/zfcp_disk_configure script and I've narrowed the problem to those few lines of /sbin/zfcp_disk_configure code : (lines 134-219) if [ -d "$_zfcp_scsi_host_dir" ] ; then # Deregister the disk from SCSI layer for target in $_zfcp_scsi_host_dir/rport-*/target*/* ; do if [ -d $target ] ; then _zfcp_tmp_targid=${target##*/} read _zfcp_tmp_hba < ${target}/hba_id read _zfcp_tmp_wwpn < ${target}/wwpn read _zfcp_tmp_lun < ${target}/fcp_lun if [ "0x${FCP_LUN}" = "$_zfcp_tmp_lun" -a "0x${FCP_WWPN}" = "$_zfcp_tmp_wwpn" ] ; then * echo 1 > $target/delete* _zfcp_scsi_dir=$target break; fi fi done /sbin/udevadm settle else debug_mesg "No SCSI disk found for FCP disk ${FCP_WWPN}:${FCP_LUN}" fi # Re-check whether the SCSI disk is gone * if [ -d "${_zfcp_scsi_dir}" ]; then* debug_mesg "Could not deactivate SCSI disk ${_zfcp_scsi_id}" exit 7 fi I made some tests and played with this code and it looks that sometimes after it does *"echo1 > $target/delete"* there isn't enough time before it checks if it was really removed. At this point , "*[ -d "${zfcp_scsi_dir*"] is true, so it exits with "7" and debug mesg. I made a small workaround by changing a little bit second part of that code like here: if [ -d "${_zfcp_scsi_dir}" ]; then sleep 1 if [ -d "${_zfcp_scsi_dir}" ]; then debug_mesg "Could not deactivate SCSI disk $ {_zfcp_scsi_id}" exit 7 fi fi So basically if it fails (if directory still exists), it should sleep for 1 second and than try again. It looks like this solved my problem. Perhaps it will help to others. z/VM Version 5 Release 4.0, Service Level 1102 (64-bit) SUSE Linux Enterprise Server 11 (s390x) VERSION = 11 PATCHLEVEL = 2 Linux d2ora000 3.0.13-0.27-default #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) s390x s390x s390x GNU/Linux Regards Grzegorz Powiedziuk ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
<<inline: ecblank.gif>>
<<inline: graycol.gif>>
<<inline: pic38731.gif>>