Hello community, here is the log from the commit of package s390-tools for openSUSE:Factory checked in at 2017-12-12 21:19:08 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/s390-tools (Old) and /work/SRC/openSUSE:Factory/.s390-tools.new (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "s390-tools" Tue Dec 12 21:19:08 2017 rev:15 rq:555142 version:2.1.0 Changes: -------- --- /work/SRC/openSUSE:Factory/s390-tools/s390-tools.changes 2017-11-29 10:51:41.850745197 +0100 +++ /work/SRC/openSUSE:Factory/.s390-tools.new/s390-tools.changes 2017-12-12 21:19:12.037344172 +0100 @@ -1,0 +2,43 @@ +Thu Dec 7 23:08:31 UTC 2017 - [email protected] + +- Added the following two patches (bsc#1071166): + s390-tools-sles15-zdev-Enable-running-chzdev-from-unknown-root-devices.patch + s390-tools-sles15-zdev-Fix-zdev-dracut-module-aborting-on-unknown-root.patch + +------------------------------------------------------------------- +Tue Dec 5 17:49:35 UTC 2017 - [email protected] + +- Added the following patches (bsc#1070836): + s390-tools-sles15-cpuplugd-Improve-systemctl-start-error-handling.patch + s390-tools-sles15-mon_tools-Improve-systemctl-start-error-handling.patch + s390-tools-sles15-lsluns-do-not-scan-all-if-filters-match-nothing.patch + s390-tools-sles15-lsluns-do-not-print-confusing-messages-when-a-filter.patch + s390-tools-sles15-lsluns-fix-flawed-formatting-of-man-page.patch + s390-tools-sles15-lsluns-enhance-usage-statement-and-man-page.patch + s390-tools-sles15-lsluns-clarify-discovery-use-case-relation-to-NPIV-a.patch + s390-tools-sles15-lsluns-point-out-IBM-Storwize-configuration-requirem.patch + s390-tools-sles15-lsluns-document-restriction-to-zfcp-only-systems.patch + s390-tools-sles15-lsluns-complement-alternative-tools-with-lszdev.patch + +------------------------------------------------------------------- +Tue Dec 5 15:46:44 UTC 2017 - [email protected] + +- Added "--no-root-update" to all the chzdev calls in the following + scripts for bsc#1071165: + ctc_configure + dasd_configure + qeth_configure + zfcp_disk_configure + zfcp_host_configure + +------------------------------------------------------------------- +Thu Nov 30 20:22:09 UTC 2017 - [email protected] + +- Added the following patches (bsc#1068538) + * s390-tools-sles15-cpi-add-unit-install-section.patch + * s390-tools-sles15-zipl-remove-invalid-dasdview-command-line-option.patch + * s390-tools-sles15-ziomon-re-add-missing-line.patch +- Modified s390-tools-sles15-zdev-Use-correct-path-to-vmcp-binary.patch to + point to the correct line in the common.mk file. + +------------------------------------------------------------------- New: ---- s390-tools-sles15-cpi-add-unit-install-section.patch s390-tools-sles15-cpuplugd-Improve-systemctl-start-error-handling.patch s390-tools-sles15-lsluns-clarify-discovery-use-case-relation-to-NPIV-a.patch s390-tools-sles15-lsluns-complement-alternative-tools-with-lszdev.patch s390-tools-sles15-lsluns-do-not-print-confusing-messages-when-a-filter.patch s390-tools-sles15-lsluns-do-not-scan-all-if-filters-match-nothing.patch s390-tools-sles15-lsluns-document-restriction-to-zfcp-only-systems.patch s390-tools-sles15-lsluns-enhance-usage-statement-and-man-page.patch s390-tools-sles15-lsluns-fix-flawed-formatting-of-man-page.patch s390-tools-sles15-lsluns-point-out-IBM-Storwize-configuration-requirem.patch s390-tools-sles15-mon_tools-Improve-systemctl-start-error-handling.patch s390-tools-sles15-zdev-Enable-running-chzdev-from-unknown-root-devices.patch s390-tools-sles15-zdev-Fix-zdev-dracut-module-aborting-on-unknown-root.patch s390-tools-sles15-ziomon-re-add-missing-line.patch s390-tools-sles15-zipl-remove-invalid-dasdview-command-line-option.patch ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ s390-tools.spec ++++++ --- /var/tmp/diff_new_pack.HMbqkN/_old 2017-12-12 21:19:13.293283542 +0100 +++ /var/tmp/diff_new_pack.HMbqkN/_new 2017-12-12 21:19:13.293283542 +0100 @@ -122,6 +122,21 @@ Patch15: s390-tools-sles15-Fix-truncation-warning.patch Patch16: s390-tools-sles15-iucvterm-include-ctype-for-toupper.patch Patch17: s390-tools-sles15-zdev-Use-correct-path-to-vmcp-binary.patch +Patch18: s390-tools-sles15-cpi-add-unit-install-section.patch +Patch19: s390-tools-sles15-zipl-remove-invalid-dasdview-command-line-option.patch +Patch20: s390-tools-sles15-ziomon-re-add-missing-line.patch +Patch21: s390-tools-sles15-cpuplugd-Improve-systemctl-start-error-handling.patch +Patch22: s390-tools-sles15-mon_tools-Improve-systemctl-start-error-handling.patch +Patch23: s390-tools-sles15-lsluns-do-not-scan-all-if-filters-match-nothing.patch +Patch24: s390-tools-sles15-lsluns-do-not-print-confusing-messages-when-a-filter.patch +Patch25: s390-tools-sles15-lsluns-fix-flawed-formatting-of-man-page.patch +Patch26: s390-tools-sles15-lsluns-enhance-usage-statement-and-man-page.patch +Patch27: s390-tools-sles15-lsluns-clarify-discovery-use-case-relation-to-NPIV-a.patch +Patch28: s390-tools-sles15-lsluns-point-out-IBM-Storwize-configuration-requirem.patch +Patch29: s390-tools-sles15-lsluns-document-restriction-to-zfcp-only-systems.patch +Patch30: s390-tools-sles15-lsluns-complement-alternative-tools-with-lszdev.patch +Patch31: s390-tools-sles15-zdev-Enable-running-chzdev-from-unknown-root-devices.patch +Patch32: s390-tools-sles15-zdev-Fix-zdev-dracut-module-aborting-on-unknown-root.patch BuildRoot: %{_tmppath}/%{name}-%{version}-build ExclusiveArch: s390 s390x @@ -195,6 +210,21 @@ %patch15 -p1 %patch16 -p1 %patch17 -p1 +%patch18 -p1 +%patch19 -p1 +%patch20 -p1 +%patch21 -p1 +%patch22 -p1 +%patch23 -p1 +%patch24 -p1 +%patch25 -p1 +%patch26 -p1 +%patch27 -p1 +%patch28 -p1 +%patch29 -p1 +%patch30 -p1 +%patch31 -p1 +%patch32 -p1 cp -vi %{S:22} CAUTION ++++++ ctc_configure ++++++ --- /var/tmp/diff_new_pack.HMbqkN/_old 2017-12-12 21:19:13.433276784 +0100 +++ /var/tmp/diff_new_pack.HMbqkN/_new 2017-12-12 21:19:13.433276784 +0100 @@ -106,11 +106,11 @@ fi if [ "${ON_OFF}" == 0 ]; then - debug_mesg "chzdev -d ${DEV_TYPE} ${CTC_READ_CHAN}" - chzdev -d ${DEV_TYPE} ${CTC_READ_CHAN} + debug_mesg "chzdev -d ${DEV_TYPE} --no-root-update ${CTC_READ_CHAN}" + chzdev -d ${DEV_TYPE} --no-root-update ${CTC_READ_CHAN} elif [ "${ON_OFF}" == 1 ]; then - debug_mesg "chzdev -e ${DEV_TYPE} ${CTC_READ_CHAN} ${PARM_LIST}" - chzdev -e ${DEV_TYPE} ${CTC_READ_CHAN} ${PARM_LIST} + debug_mesg "chzdev -e ${DEV_TYPE} --no-root-update ${CTC_READ_CHAN} ${PARM_LIST}" + chzdev -e ${DEV_TYPE} --no-root-update ${CTC_READ_CHAN} ${PARM_LIST} else mesg "You must specify a 0 or a 1 for the online/offline attribute." usage exit 1 ++++++ dasd_configure ++++++ --- /var/tmp/diff_new_pack.HMbqkN/_old 2017-12-12 21:19:13.457275625 +0100 +++ /var/tmp/diff_new_pack.HMbqkN/_new 2017-12-12 21:19:13.457275625 +0100 @@ -125,11 +125,11 @@ fi if [ "${ON_OFF}" == 0 ]; then - debug_mesg "chzdev -d dasd ${CCW_CHAN_ID}" - chzdev -d dasd ${CCW_CHAN_ID} + debug_mesg "chzdev -d dasd --no-root-update ${CCW_CHAN_ID}" + chzdev -d dasd --no-root-update ${CCW_CHAN_ID} elif [ "${ON_OFF}" == 1 ]; then - debug_mesg "chzdev -e dasd ${CCW_CHAN_ID} ${PARM_LIST}" - chzdev -e dasd ${CCW_CHAN_ID} ${PARM_LIST} + debug_mesg "chzdev -e dasd --no-root-update ${CCW_CHAN_ID} ${PARM_LIST}" + chzdev -e dasd --no-root-update ${CCW_CHAN_ID} ${PARM_LIST} else mesg "You must specify a 0 or a 1 for the online/offline attribute." usage exit 1 ++++++ qeth_configure ++++++ --- /var/tmp/diff_new_pack.HMbqkN/_old 2017-12-12 21:19:13.561270605 +0100 +++ /var/tmp/diff_new_pack.HMbqkN/_new 2017-12-12 21:19:13.561270605 +0100 @@ -151,11 +151,11 @@ fi if [ "${ON_OFF}" == 0 ]; then - debug_mesg "chzdev -d qeth ${QETH_READ_CHAN}" - chzdev -d qeth ${QETH_READ_CHAN} + debug_mesg "chzdev -d qeth --no-root-update ${QETH_READ_CHAN}" + chzdev -d qeth --no-root-update ${QETH_READ_CHAN} elif [ "${ON_OFF}" == 1 ]; then - debug_mesg "chzdev -e qeth ${LAYER_MODE} ${PARM_LIST} ${QETH_READ_CHAN}" - chzdev -e qeth ${LAYER_MODE} ${PARM_LIST} ${QETH_READ_CHAN} + debug_mesg "chzdev -e qeth --no-root-update ${LAYER_MODE} ${PARM_LIST} ${QETH_READ_CHAN}" + chzdev -e qeth ${LAYER_MODE} --no-root-update ${PARM_LIST} ${QETH_READ_CHAN} else mesg "You must specify a 0 or a 1 for the online/offline attribute." usage exit 1 ++++++ s390-tools-sles15-cpi-add-unit-install-section.patch ++++++ Subject: [PATCH] [BZ 160944] cpi: add missing Install section to service unit From: Hendrik Brueckner <[email protected]> Description: cpi: add missing Install section to service unit Symptom: Enabling the cpi service unit fails because it does not include information about where to install it. Problem: An install section is missing. Solution: Add an install section. Reproduction: Issue systemctl enable cpi. Upstream-ID: - Problem-ID: 160944 Signed-off-by: Hendrik Brueckner <[email protected]> --- systemd/cpi.service.in | 3 +++ 1 file changed, 3 insertions(+) --- a/systemd/cpi.service.in +++ b/systemd/cpi.service.in @@ -38,3 +38,6 @@ EnvironmentFile=/etc/sysconfig/cpi # # Sending data to the HMC/SE ExecStart=@toolslib_path@/cpictl -e + +[Install] +WantedBy=multi-user.target ++++++ s390-tools-sles15-cpuplugd-Improve-systemctl-start-error-handling.patch ++++++ Subject: [PATCH] [BZ 161563] cpuplugd: Improve systemctl start error handling From: Gerald Schaefer <[email protected]> Description: cpuplugd, mon_tools: Improve systemctl start error handling Symptom: "systemctl start cpuplugd/mon_procd/mon_fsstatd" does not report any errors in case the startup fails. Problem: For type=simple, systemd forks/execs the process and if that is successful, it immediately returns. There is no way to find out if the initial startup fails. Solution: Use type=fork and run the process in the background. In this case systemd waits until the initial process returns. In addition, use PIDFile and ensure that the pid file is already available when the initial process returns. To achieve this, use startup synchronization via pipe. Reproduction: Add invalid values to the config files and start the daemons with "systemctl start cpuplugd/mon_procd/mon_fsstatd". Upstream-ID: 82c8148983fc09e9bfa5bf852b2d39571f8475a0 Problem-ID: 161563 Upstream-Description: cpuplugd: Improve systemctl start error handling Currently "systemctl start cpuplugd" does not report any errors in case the startup fails. Example: # mv /etc/cpuplugd.conf /etc/cpuplugd.conf.xxx # systemctl start cpuplugd The reason is that for type=simple systemd forks/execs cpuplugd and if that is successful immediately returns. There is no way to find out if the initial startup fails. Fix this by using type=fork and running cpuplugd in the background. In this case systemd waits until the initial process returns. In addition use PIDFile and ensure that the pid file is already available when the initial cpuplugd process returns. To achieve this, replace the daemon() function by our own implementation that introduces startup synchronization via pipe. Without that systemd would print the following warning: systemd[1]: cpuplugd.service: PID file /var/run/cpuplugd.pid not readable (yet?) after start: No such file or directory With this patch, an early startup error like in the example above, is now reported correctly in "systemctl start": # systemctl start cpuplugd Job for cpuplugd.service failed because the control process exited... See "systemctl status cpuplugd.service" and "journalctl -xe" for ... # journalctl -ex | grep cpuplugd Nov 16 15:52:27 ... cpuplugd[5096]: Opening configuration file failed: No such file or directory Signed-off-by: Michael Holzheu <[email protected]> Acked-by: Gerald Schaefer <[email protected]> Signed-off-by: Gerald Schaefer <[email protected]> --- cpuplugd/cpuplugd.h | 2 - cpuplugd/daemon.c | 60 ++++++++++++++++++++++++++++++++++++++++++-- cpuplugd/main.c | 4 -- systemd/cpuplugd.service.in | 5 ++- 4 files changed, 63 insertions(+), 8 deletions(-) --- a/cpuplugd/cpuplugd.h +++ b/cpuplugd/cpuplugd.h @@ -197,10 +197,10 @@ int is_online(int cpuid); long get_cmmpages_size(); void parse_options(int argc, char **argv); void check_if_started_twice(); -void store_pid(void); void handle_signals(void); void handle_sighup(void); void reload_daemon(void); +int daemonize(void); int check_cmmfiles(void); void check_config(); void set_cmm_pages(long size); --- a/cpuplugd/daemon.c +++ b/cpuplugd/daemon.c @@ -9,6 +9,10 @@ * it under the terms of the MIT license. See LICENSE for details. */ +#include <fcntl.h> +#include <sys/stat.h> +#include <sys/types.h> + #include "cpuplugd.h" const char *name = NAME; @@ -49,7 +53,7 @@ void print_version() /* * Store daemon's pid so it can be stopped */ -void store_pid(void) +static int store_pid(void) { FILE *filp; @@ -57,10 +61,62 @@ void store_pid(void) if (!filp) { cpuplugd_error("cannot open pid file %s: %s\n", pid_file, strerror(errno)); - exit(1); + return -1; } fprintf(filp, "%d\n", getpid()); fclose(filp); + return 0; +} + +/* + * Run daemon in background and write pid file + */ +int daemonize(void) +{ + int fd, pipe_fds[2], startup_rc = 1; + pid_t pid; + + if (pipe(pipe_fds) == -1) { + cpuplugd_error("cannot create pipe\n"); + return -1; + } + pid = fork(); + if (pid < 0) + goto close_pipe; + if (pid != 0) { + /* Wait for startup return code from daemon */ + if (read(pipe_fds[0], &startup_rc, sizeof(startup_rc)) == -1) + cpuplugd_error("cannot read from pipe\n"); + /* On success daemon has written pid file at this point */ + exit(startup_rc); + } + /* Create new session */ + if (setsid() < 0) + goto notify_parent; + /* Redirect stdin/out/err to /dev/null */ + fd = open("/dev/null", O_RDWR, 0); + if (fd == -1) + goto notify_parent; + if (dup2(fd, STDIN_FILENO) < 0) + goto notify_parent; + if (dup2(fd, STDOUT_FILENO) < 0) + goto notify_parent; + if (dup2(fd, STDERR_FILENO) < 0) + goto notify_parent; + /* Create pid file */ + if (store_pid() < 0) + goto notify_parent; + startup_rc = 0; +notify_parent: + /* Inform waiting parent about startup return code */ + if (write(pipe_fds[1], &startup_rc, sizeof(startup_rc)) == -1) { + cpuplugd_error("cannot write to pipe\n"); + startup_rc = 1; + } +close_pipe: + close(pipe_fds[0]); + close(pipe_fds[1]); + return startup_rc ? -1 : 0; } /* --- a/cpuplugd/main.c +++ b/cpuplugd/main.c @@ -418,13 +418,11 @@ int main(int argc, char *argv[]) check_config(); if (!foreground) { - rc = daemon(1, 0); + rc = daemonize(); if (rc < 0) cpuplugd_exit("Detach from terminal failed: %s\n", strerror(errno)); } - /* Store daemon pid */ - store_pid(); /* Unlock lock file */ flock(fd, LOCK_UN); close(fd); --- a/systemd/cpuplugd.service.in +++ b/systemd/cpuplugd.service.in @@ -13,10 +13,11 @@ Documentation=man:cpuplugd(8) man:cpuplu After=remote-fs.target [Service] -ExecStart=@usrsbin_path@/cpuplugd -f -c /etc/cpuplugd.conf +ExecStart=@usrsbin_path@/cpuplugd -c /etc/cpuplugd.conf ExecReload=/bin/kill -HUP $MAINPID KillMode=process -Type=simple +Type=forking +PIDFile=/var/run/cpuplugd.pid [Install] WantedBy=multi-user.target ++++++ s390-tools-sles15-lsluns-clarify-discovery-use-case-relation-to-NPIV-a.patch ++++++ Subject: [PATCH] [BZ 161888] lsluns: clarify discovery use case, relation to NPIV and to zfcp auto LUN scan From: Jens Remus <[email protected]> Description: lsluns: Fix filter handling and documentation enhancements. Symptom: lsluns lists all LUNs discovered in the FC SAN despite user given filter(s) that do not match anything: # lsluns -c 0.0.5080 No valid combination found for adapter '0.0.5080'. Removing from resource list. No valid parameters left, using all available resources in system. Scanning for LUNs on adapter 0.0.5090 ... lsluns prints the message "No valid combination found for {adapter|port} '...'. Removing from resource list." for every adapter and port filter that does not contribute to the final filtered results. The formatting of the lsluns (8) man page is flawed. lsluns is used in unexpected or even unsupported ways. Problem: Scanning can be resource consumptive. So if a user already wants to filter, possibly to reduce resource consumption, he does not want to happen to scan everything and thus consume the worst case of resources. The message "No valid combination found for {adapter|port} '...'. Removing from resource list." is potentially confusing. It is unclear which combination is being referred to, especially if only one single adapter or port filter was specified. There is also no differentiation whether the denoted adapter or port exists for its own or not. It just does not exist in the final filtered results. The formatting of the lsluns (8) man page is flawed. The lsluns usage text and lsluns (8) man page lack the information on the intended use cases, requirements, and restrictions. Solution: Print a message and exit when all filters match nothing. Do not print confusing messages when a filter matches nothing. Fix man page formatting. Enhance usage text and man page. Clarify discovery use case, relation to NPIV and to zfcp auto LUN scan. Point out IBM Storwize configuration requirements. Document restriction to zfcp-only systems. Reproduction: Use lsluns and specify adapter bus-ID and/or target port WWPN filter(s) that do not match anything. Either specify inexistent bus-IDs and/or WWPNs or invalid filter arguments. Upstream-ID: 0daa7ba0b558ff22fa1c1e014e754cbd08366c00 Problem-ID: 161888 Upstream-Description: lsluns: clarify discovery use case, relation to NPIV and to zfcp auto LUN scan Signed-off-by: Steffen Maier <[email protected]> Reviewed-by: Jens Remus <[email protected]> Signed-off-by: Michael Holzheu <[email protected]> Signed-off-by: Jens Remus <[email protected]> --- zconf/lsluns | 3 +++ zconf/lsluns.8 | 18 ++++++++++++++++++ 2 files changed, 21 insertions(+) --- a/zconf/lsluns +++ b/zconf/lsluns @@ -174,6 +174,9 @@ $PROGRAM_NAME [-c <busid>] ... [-p <wwpn List LUNs discovered in the Fibre Channel (FC) Storage Area Network (SAN). This causes extra SAN traffic for each target port WWPN. + Discovering LUNs only makes sense for NPIV-enabled FCP devices + without zfcp automatic LUN scan. zfcp automatic LUN scan is available + as of kernel version 2.6.37, if not disabled with zfcp.allow_lun_scan=0. $PROGRAM_NAME -a [-c <busid>] ... [-p <wwpn>] ... [-h] [-v] --- a/zconf/lsluns.8 +++ b/zconf/lsluns.8 @@ -46,6 +46,24 @@ encryption, use other tools such as or .BR "lsscsi \-tv" . +.SS Details on lsluns without -a option + +.TP +Prerequisite +Discovering LUNs only makes sense for NPIV-enabled FCP devices +without zfcp automatic LUN scan. zfcp automatic LUN scan is available +as of kernel version 2.6.37, if not disabled with zfcp.allow_lun_scan=0. + +With available and enabled zfcp automatic LUN scan, +the kernel already performs LUN discovery. + +.TP +Temporary LUN Attachment +If not attached already, lsluns temporarily attaches LUN 0 +(or if this fails the WLUN 0xc101000000000000) during runtime. +Do not terminate lsluns with a signal. Signals interfere +with the removal of temporarily attached LUNs. + .SH OPTIONS .TP .BR \-a ", " \-\-active ++++++ s390-tools-sles15-lsluns-complement-alternative-tools-with-lszdev.patch ++++++ Subject: [PATCH] [BZ 161888] lsluns: complement alternative tools with lszdev From: Jens Remus <[email protected]> Description: lsluns: Fix filter handling and documentation enhancements. Symptom: lsluns lists all LUNs discovered in the FC SAN despite user given filter(s) that do not match anything: # lsluns -c 0.0.5080 No valid combination found for adapter '0.0.5080'. Removing from resource list. No valid parameters left, using all available resources in system. Scanning for LUNs on adapter 0.0.5090 ... lsluns prints the message "No valid combination found for {adapter|port} '...'. Removing from resource list." for every adapter and port filter that does not contribute to the final filtered results. The formatting of the lsluns (8) man page is flawed. lsluns is used in unexpected or even unsupported ways. Problem: Scanning can be resource consumptive. So if a user already wants to filter, possibly to reduce resource consumption, he does not want to happen to scan everything and thus consume the worst case of resources. The message "No valid combination found for {adapter|port} '...'. Removing from resource list." is potentially confusing. It is unclear which combination is being referred to, especially if only one single adapter or port filter was specified. There is also no differentiation whether the denoted adapter or port exists for its own or not. It just does not exist in the final filtered results. The formatting of the lsluns (8) man page is flawed. The lsluns usage text and lsluns (8) man page lack the information on the intended use cases, requirements, and restrictions. Solution: Print a message and exit when all filters match nothing. Do not print confusing messages when a filter matches nothing. Fix man page formatting. Enhance usage text and man page. Clarify discovery use case, relation to NPIV and to zfcp auto LUN scan. Point out IBM Storwize configuration requirements. Document restriction to zfcp-only systems. Reproduction: Use lsluns and specify adapter bus-ID and/or target port WWPN filter(s) that do not match anything. Either specify inexistent bus-IDs and/or WWPNs or invalid filter arguments. Upstream-ID: e5f9279295780bd297f58cc23319878fadbc80f1 Problem-ID: 161888 Upstream-Description: lsluns: complement alternative tools with lszdev Signed-off-by: Steffen Maier <[email protected]> Reviewed-by: Benjamin Block <[email protected]> Reviewed-by: Jens Remus <[email protected]> Signed-off-by: Michael Holzheu <[email protected]> Signed-off-by: Jens Remus <[email protected]> --- zconf/lsluns | 3 ++- zconf/lsluns.8 | 7 +++++-- 2 files changed, 7 insertions(+), 3 deletions(-) --- a/zconf/lsluns +++ b/zconf/lsluns @@ -192,7 +192,8 @@ $PROGRAM_NAME -a [-c <busid>] ... [-p <w This causes extra SAN traffic for each attached LUN. For all other uses, such as listing attached LUNs or properties other than -encryption, use other tools such as "lszfcp -D" or "lsscsi -tv". +encryption, use other tools such as "lszfcp -D" or "lsscsi -tv" +or "lszdev zfcp-lun -ii". Limit the listing by specifying one or more adapters (FCP device bus-IDs) or target port WWPNs or both. --- a/zconf/lsluns.8 +++ b/zconf/lsluns.8 @@ -48,7 +48,9 @@ For all other uses, such as listing atta encryption, use other tools such as .B lszfcp \-D or -.BR "lsscsi \-tv" . +.BR "lsscsi \-tv" +or +.BR "lszdev zfcp-lun \-ii" . .SS Details on lsluns without -a option @@ -135,4 +137,5 @@ indicates that the device is encrypted. .SH "SEE ALSO" .BR lszfcp (8), -.BR lsscsi (8) +.BR lsscsi (8), +.BR lszdev (8) ++++++ s390-tools-sles15-lsluns-do-not-print-confusing-messages-when-a-filter.patch ++++++ Subject: [PATCH] [BZ 161888] lsluns: do not print confusing messages when a filter matches nothing From: Jens Remus <[email protected]> Description: lsluns: Fix filter handling and documentation enhancements. Symptom: lsluns lists all LUNs discovered in the FC SAN despite user given filter(s) that do not match anything: # lsluns -c 0.0.5080 No valid combination found for adapter '0.0.5080'. Removing from resource list. No valid parameters left, using all available resources in system. Scanning for LUNs on adapter 0.0.5090 ... lsluns prints the message "No valid combination found for {adapter|port} '...'. Removing from resource list." for every adapter and port filter that does not contribute to the final filtered results. The formatting of the lsluns (8) man page is flawed. lsluns is used in unexpected or even unsupported ways. Problem: Scanning can be resource consumptive. So if a user already wants to filter, possibly to reduce resource consumption, he does not want to happen to scan everything and thus consume the worst case of resources. The message "No valid combination found for {adapter|port} '...'. Removing from resource list." is potentially confusing. It is unclear which combination is being referred to, especially if only one single adapter or port filter was specified. There is also no differentiation whether the denoted adapter or port exists for its own or not. It just does not exist in the final filtered results. The formatting of the lsluns (8) man page is flawed. The lsluns usage text and lsluns (8) man page lack the information on the intended use cases, requirements, and restrictions. Solution: Print a message and exit when all filters match nothing. Do not print confusing messages when a filter matches nothing. Fix man page formatting. Enhance usage text and man page. Clarify discovery use case, relation to NPIV and to zfcp auto LUN scan. Point out IBM Storwize configuration requirements. Document restriction to zfcp-only systems. Reproduction: Use lsluns and specify adapter bus-ID and/or target port WWPN filter(s) that do not match anything. Either specify inexistent bus-IDs and/or WWPNs or invalid filter arguments. Upstream-ID: c993ad89c544dd162005a9a1e582b51667c46b66 Problem-ID: 161888 Upstream-Description: lsluns: do not print confusing messages when a filter matches nothing lsluns printed potentially confusing messages when a filter or combination of filters matched nothing: No valid combination found for adapter '0.0.1906'. Removing from resource list. No valid combination found for port '0x50050763071845e3'. Removing from resource list. ... To the user it is potentially unclear which 'combination' is actually being referred to, as only one part of the combination is mentioned, and what the ominous 'resource list' is. The later information is merely useful for a developer to debug the script. Such a message was written for every user supplied filter that did not contribute anything to the resulting subset that is being listed, although the filter actually might match something when used standalone. Additionally those messages were printed to stdout instead of stderr. As there is no debug or verbose switch and the information level of those messages is low, we may simply discard them. Reported-by: Steffen Maier <[email protected]> Signed-off-by: Jens Remus <[email protected]> Reviewed-by: Steffen Maier <[email protected]> Reviewed-by: Benjamin Block <[email protected]> Signed-off-by: Michael Holzheu <[email protected]> Signed-off-by: Jens Remus <[email protected]> --- zconf/lsluns | 15 --------------- 1 file changed, 15 deletions(-) --- a/zconf/lsluns +++ b/zconf/lsluns @@ -215,7 +215,6 @@ sub get_env_list my $p_ref_list = shift(); my @res ; my %res_hash; - my @t_arr; @res = </sys/bus/ccw/drivers/zfcp/*.*.*/0x*>; return () if (!@res); @@ -226,20 +225,6 @@ sub get_env_list next if (@$p_ref_list && "@$p_ref_list" !~ /$p/); push @{ $res_hash{$a} }, $p; } - foreach my $a (sort @$a_ref_list) { - if ("@{[keys %res_hash]}" !~ /$a/) { - print "\tNo valid combination found for adapter '$a'. ", - "Removing from resource list.\n"; - } - } - - push @t_arr, map { @{$res_hash{$_}} } keys %res_hash; - foreach my $p (@$p_ref_list) { - if ("@t_arr" !~ /$p/) { - print "\tNo valid combination found for port '$p'. ", - "Removing from resource list.\n"; - } - } if (!%res_hash) { print "$PROGRAM_NAME: Adapter and/or port filter(s) did not match anything\n"; ++++++ s390-tools-sles15-lsluns-do-not-scan-all-if-filters-match-nothing.patch ++++++ Subject: [PATCH] [BZ 161888] lsluns: do not scan (all) if filters match nothing From: Jens Remus <[email protected]> Description: lsluns: Fix filter handling and documentation enhancements. Symptom: lsluns lists all LUNs discovered in the FC SAN despite user given filter(s) that do not match anything: # lsluns -c 0.0.5080 No valid combination found for adapter '0.0.5080'. Removing from resource list. No valid parameters left, using all available resources in system. Scanning for LUNs on adapter 0.0.5090 ... lsluns prints the message "No valid combination found for {adapter|port} '...'. Removing from resource list." for every adapter and port filter that does not contribute to the final filtered results. The formatting of the lsluns (8) man page is flawed. lsluns is used in unexpected or even unsupported ways. Problem: Scanning can be resource consumptive. So if a user already wants to filter, possibly to reduce resource consumption, he does not want to happen to scan everything and thus consume the worst case of resources. The message "No valid combination found for {adapter|port} '...'. Removing from resource list." is potentially confusing. It is unclear which combination is being referred to, especially if only one single adapter or port filter was specified. There is also no differentiation whether the denoted adapter or port exists for its own or not. It just does not exist in the final filtered results. The formatting of the lsluns (8) man page is flawed. The lsluns usage text and lsluns (8) man page lack the information on the intended use cases, requirements, and restrictions. Solution: Print a message and exit when all filters match nothing. Do not print confusing messages when a filter matches nothing. Fix man page formatting. Enhance usage text and man page. Clarify discovery use case, relation to NPIV and to zfcp auto LUN scan. Point out IBM Storwize configuration requirements. Document restriction to zfcp-only systems. Reproduction: Use lsluns and specify adapter bus-ID and/or target port WWPN filter(s) that do not match anything. Either specify inexistent bus-IDs and/or WWPNs or invalid filter arguments. Upstream-ID: 398f9ceac8c20705f573671bde4bc482967f5c13 Problem-ID: 161888 Upstream-Description: lsluns: do not scan (all) if filters match nothing Fix the following undesired behavior of lsluns to scan all resources if the user provided filters did not match anything: No valid combination found for adapter '5080'. Removing from resource list. No valid parameters left, using all available resources in system. Scanning for LUNs on adapter 0.0.5080 ... Scanning can be resource consumptive. So if a user already wants to filter, possibly to reduce resource consumption, he does not want to happen to scan everything and thus consume the worst case of resources. Instead print a message to inform the user why nothing was scanned. Reported-by: Steffen Maier <[email protected]> Signed-off-by: Jens Remus <[email protected]> Reviewed-by: Steffen Maier <[email protected]> Reviewed-by: Benjamin Block <[email protected]> Signed-off-by: Michael Holzheu <[email protected]> Signed-off-by: Jens Remus <[email protected]> --- zconf/lsluns | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) --- a/zconf/lsluns +++ b/zconf/lsluns @@ -219,7 +219,6 @@ sub get_env_list @res = </sys/bus/ccw/drivers/zfcp/*.*.*/0x*>; return () if (!@res); -reload: foreach my $entry (@res) { my $a = ${[split('/', $entry)]}[-2]; my $p = ${[split('/', $entry)]}[-1]; @@ -243,12 +242,7 @@ reload: } if (!%res_hash) { - print "\nNo valid parameters left, ", - "using all available resources in system.\n\n"; - @$a_ref_list = (); - @$p_ref_list = (); - @t_arr = (); - goto reload; + print "$PROGRAM_NAME: Adapter and/or port filter(s) did not match anything\n"; } return %res_hash; } ++++++ s390-tools-sles15-lsluns-document-restriction-to-zfcp-only-systems.patch ++++++ Subject: [PATCH] [BZ 161888] lsluns: document restriction to zfcp-only systems From: Jens Remus <[email protected]> Description: lsluns: Fix filter handling and documentation enhancements. Symptom: lsluns lists all LUNs discovered in the FC SAN despite user given filter(s) that do not match anything: # lsluns -c 0.0.5080 No valid combination found for adapter '0.0.5080'. Removing from resource list. No valid parameters left, using all available resources in system. Scanning for LUNs on adapter 0.0.5090 ... lsluns prints the message "No valid combination found for {adapter|port} '...'. Removing from resource list." for every adapter and port filter that does not contribute to the final filtered results. The formatting of the lsluns (8) man page is flawed. lsluns is used in unexpected or even unsupported ways. Problem: Scanning can be resource consumptive. So if a user already wants to filter, possibly to reduce resource consumption, he does not want to happen to scan everything and thus consume the worst case of resources. The message "No valid combination found for {adapter|port} '...'. Removing from resource list." is potentially confusing. It is unclear which combination is being referred to, especially if only one single adapter or port filter was specified. There is also no differentiation whether the denoted adapter or port exists for its own or not. It just does not exist in the final filtered results. The formatting of the lsluns (8) man page is flawed. The lsluns usage text and lsluns (8) man page lack the information on the intended use cases, requirements, and restrictions. Solution: Print a message and exit when all filters match nothing. Do not print confusing messages when a filter matches nothing. Fix man page formatting. Enhance usage text and man page. Clarify discovery use case, relation to NPIV and to zfcp auto LUN scan. Point out IBM Storwize configuration requirements. Document restriction to zfcp-only systems. Reproduction: Use lsluns and specify adapter bus-ID and/or target port WWPN filter(s) that do not match anything. Either specify inexistent bus-IDs and/or WWPNs or invalid filter arguments. Upstream-ID: 55f0b001d15b3984967e7f87d6118232078e3fe5 Problem-ID: 161888 Upstream-Description: lsluns: document restriction to zfcp-only systems Signed-off-by: Steffen Maier <[email protected]> Reviewed-by: Jens Remus <[email protected]> Signed-off-by: Michael Holzheu <[email protected]> Signed-off-by: Jens Remus <[email protected]> --- zconf/lsluns | 4 ++++ zconf/lsluns.8 | 8 ++++++-- 2 files changed, 10 insertions(+), 2 deletions(-) --- a/zconf/lsluns +++ b/zconf/lsluns @@ -170,6 +170,10 @@ sub get_lun_hash sub lsluns_usage { print <<EOD; Usage: +This tool is designed for environments where all SCSI devices are attached +through the zfcp device driver. Expect error messages in mixed environments +such as with iSCSI. + $PROGRAM_NAME [-c <busid>] ... [-p <wwpn>] ... [-h] [-v] List LUNs discovered in the Fibre Channel (FC) Storage Area Network (SAN). --- a/zconf/lsluns.8 +++ b/zconf/lsluns.8 @@ -4,8 +4,8 @@ .\" .TH LSLUNS 8 "2017-02-17" "s390-tools" .SH NAME -lsluns \- list LUNs discovered in the FC SAN, or show encryption state of -attached LUNs +lsluns \- list LUNs discovered in the FC SAN through zfcp, or show encryption state of +zfcp-attached LUNs .SH SYNOPSIS .B lsluns @@ -28,6 +28,10 @@ attached LUNs .SH DESCRIPTION .PP +This tool is designed for environments where all SCSI devices are attached +through the zfcp device driver. Expect error messages in mixed environments +such as with iSCSI. + .B lsluns lists all logical unit numbers (LUNs) discovered in the Fibre Channel (FC) Storage Area Network (SAN). ++++++ s390-tools-sles15-lsluns-enhance-usage-statement-and-man-page.patch ++++++ Subject: [PATCH] [BZ 161888] lsluns: enhance usage statement and man page From: Jens Remus <[email protected]> Description: lsluns: Fix filter handling and documentation enhancements. Symptom: lsluns lists all LUNs discovered in the FC SAN despite user given filter(s) that do not match anything: # lsluns -c 0.0.5080 No valid combination found for adapter '0.0.5080'. Removing from resource list. No valid parameters left, using all available resources in system. Scanning for LUNs on adapter 0.0.5090 ... lsluns prints the message "No valid combination found for {adapter|port} '...'. Removing from resource list." for every adapter and port filter that does not contribute to the final filtered results. The formatting of the lsluns (8) man page is flawed. lsluns is used in unexpected or even unsupported ways. Problem: Scanning can be resource consumptive. So if a user already wants to filter, possibly to reduce resource consumption, he does not want to happen to scan everything and thus consume the worst case of resources. The message "No valid combination found for {adapter|port} '...'. Removing from resource list." is potentially confusing. It is unclear which combination is being referred to, especially if only one single adapter or port filter was specified. There is also no differentiation whether the denoted adapter or port exists for its own or not. It just does not exist in the final filtered results. The formatting of the lsluns (8) man page is flawed. The lsluns usage text and lsluns (8) man page lack the information on the intended use cases, requirements, and restrictions. Solution: Print a message and exit when all filters match nothing. Do not print confusing messages when a filter matches nothing. Fix man page formatting. Enhance usage text and man page. Clarify discovery use case, relation to NPIV and to zfcp auto LUN scan. Point out IBM Storwize configuration requirements. Document restriction to zfcp-only systems. Reproduction: Use lsluns and specify adapter bus-ID and/or target port WWPN filter(s) that do not match anything. Either specify inexistent bus-IDs and/or WWPNs or invalid filter arguments. Upstream-ID: e748fff3479f8f4ae7e8262b4913f6d08ff78f66 Problem-ID: 161888 Upstream-Description: lsluns: enhance usage statement and man page The wording in the lsluns usage statement and man page was misleading in several aspects: * lsluns does not list all LUNs, just those discovered in the FC SAN * lsluns -a should only be used to display the LUN encryption status Fix filter option arguments. Clarify filter option usage. Refer to lszfcp and lsscsi. Reported-by: Steffen Maier <[email protected]> Signed-off-by: Jens Remus <[email protected]> Reviewed-by: Steffen Maier <[email protected]> Signed-off-by: Michael Holzheu <[email protected]> Signed-off-by: Jens Remus <[email protected]> --- zconf/lsluns | 45 +++++++++++++++------------ zconf/lsluns.8 | 93 +++++++++++++++++++++++++++++++++++++++------------------ 2 files changed, 91 insertions(+), 47 deletions(-) --- a/zconf/lsluns +++ b/zconf/lsluns @@ -1,6 +1,6 @@ #!/usr/bin/perl # -# lsluns - Tool to list all available LUNs +# lsluns - list LUNs discovered in the FC SAN, or show encryption state of attached LUNs # # Copyright IBM Corp. 2008, 2017 # @@ -169,32 +169,39 @@ sub get_lun_hash sub lsluns_usage { print <<EOD; -Usage: $PROGRAM_NAME [<options>] +Usage: +$PROGRAM_NAME [-c <busid>] ... [-p <wwpn>] ... [-h] [-v] - lsluns provides information for LUNs. + List LUNs discovered in the Fibre Channel (FC) Storage Area Network (SAN). + This causes extra SAN traffic for each target port WWPN. - The default is to list all LUNs that are available via the attached ports. - The display can be limited by specifying an adapter or a port. +$PROGRAM_NAME -a [-c <busid>] ... [-p <wwpn>] ... [-h] [-v] + + Show encryption state of the attached LUNs. + This causes extra SAN traffic for each attached LUN. + +For all other uses, such as listing attached LUNs or properties other than +encryption, use other tools such as "lszfcp -D" or "lsscsi -tv". + +Limit the listing by specifying one or more adapters (FCP device +bus-IDs) or target port WWPNs or both. Options: - -a, --active - Shows all activated LUNs. - In addition LUN encryption information is provided. - e.g. "lsluns -a" - - -c, --ccw - Shows LUNs for a specific ccw device. - e.g. "lsluns -c 0.0.3922" - - -p, --port - Shows LUNs for a specific port. - e.g. "lsluns -p 0x5005123456789000" + -c <busid>, --ccw <busid> + Filter LUNs by adapter with the specified FCP device bus-ID. Can be + specified multiple times. + For example: "$PROGRAM_NAME -c 0.0.3922" + + -p <wwpn>, --port <wwpn> + Filter LUNs by target port with the specified WWPN. Can be specified + multiple times. + For example: "$PROGRAM_NAME -p 0x5005123456789000" -h, --help - Print help message and exit. + Print help message and exit. -v, --version - Display version info and exit. + Display version information and exit. EOD exit 0; } --- a/zconf/lsluns.8 +++ b/zconf/lsluns.8 @@ -2,61 +2,93 @@ .\" s390-tools is free software; you can redistribute it and/or modify .\" it under the terms of the MIT license. See LICENSE for details. .\" -.TH LSLUNS 8 "June 2008" "s390-tools" +.TH LSLUNS 8 "2017-02-17" "s390-tools" .SH NAME -lsluns \- list available LUNs +lsluns \- list LUNs discovered in the FC SAN, or show encryption state of +attached LUNs .SH SYNOPSIS .B lsluns +.RB [\| \-c +.IR busid \|]\ .\|.\|. +.RB [\| \-p +.IR wwpn \|]\ .\|.\|. +.\" --active +.br +.B lsluns \-a +.RB [\| \-c +.IR busid \|]\ .\|.\|. +.RB [\| \-p +.IR wwpn \|]\ .\|.\|. +.\" --help and --version +.br +.B lsluns .RB [\| \-h \|] .RB [\| \-v \|] -.RB [\| \-c -.IR adapter\ id:0.0.XXXX \|]\ .\|.\|. -.RB [ \-p -.IR port\ number:0xXXXXXXXXXXXXXXXX \|]\ .\|.\|. .SH DESCRIPTION .PP .B lsluns -does a listing of all available LUNs. - -The default is to list all LUNs that are found. The listing can be -limited by specifying an adapter or a port. +lists all logical unit numbers (LUNs) discovered in the +Fibre Channel (FC) Storage Area Network (SAN). +This causes extra SAN traffic for each target port WWPN. + +.B lsluns -a +shows the encryption state of the attached LUNs. +This causes extra SAN traffic for each attached LUN. + +Limit the listing by specifying one or more adapters (FCP device +bus-IDs) or target port WWPNs or both. + +For all other uses, such as listing attached LUNs or properties other than +encryption, use other tools such as +.B lszfcp \-D +or +.BR "lsscsi \-tv" . .SH OPTIONS .TP +.BR \-a ", " \-\-active +Show the encryption state of the attached LUNs. Encrypted devices are indicated +with a bracketed X immediately following the LUN number. +.TP +.BI \-c\ busid \fR,\ \fB\-\-ccw= busid +Filter LUNs by adapter with the specified FCP device bus-ID. This option can be +specified multiple times. When used in conjunction with \fB\-p\fR, only those +LUNs are listed that also satisfy at least one of the \fB\-p\fR constraints. +.TP +.BI \-p\ wwpn \fR,\ \fB\-\-port= wwpn +Filter LUNs by target port with the specified WWPN. This option can be +specified multiple times. When used in conjunction with \fB\-c\fR, only those +LUNs are listed that also satisfy at least one of the \fB\-c\fR constraints. +.TP .BR \-h ", " \-\-help Print help message and exit. .TP .BR \-v ", " \-\-version -Display version info and exit. -.TP -.BI \-c\ adapter \fR,\ \fB\-\-ccw= adapter -Shows LUNs for a specific adapter. -.TP -.BI \-p\ port \fR,\ \fB\-\-port= port -Shows LUNs for a specific port. -.TP -.BR \-a ", " \-\-active -Shows all activated LUNs. In addition information is provided -whether the LUN is encrypted or not. This is indicated with a bracketed X -right after the LUN number. +Display version information and exit. .SH EXAMPLES .TP .B "lsluns" .RS -Shows all available LUNs. +Lists all LUNs discovered in the FC SAN. .RE .TP .BI "lsluns \-c " 0.0.3922 -Shows all LUNs found on adapter \fI0.0.3922\fR. +Lists all LUNs discovered in the FC SAN on adapter \fI0.0.3922\fR. .TP .BI "lsluns \-p " 0x5005123456789000 -Shows all LUNs for port \fI0x5005123456789000\fR. +Lists all LUNs discovered in the FC SAN on target port +\fI0x5005123456789000\fR. .TP -.BI "lsluns \-c " 0.0.3922 " \-p " 0x5005123456789000 -Shows all LUNs for adapter \fI0.0.3922\fR and port \fI0x5005123456789000\fR. +.BI "lsluns \-c " 0.0.3922 " \-c " 0.0.fc00 \ +" \-p " 0x5005123456789000 " \-p " 0x5005abcdefabc000 +Lists all LUNs discovered in the FC SAN on: +adpater \fI0.0.3922\fR and port \fI0x5005123456789000\fR, +adapter \fI0.0.3922\fR and port \fI0x5005abcdefabc000\fR, +adapter \fI0.0.fc00\fR and port \fI0x5005123456789000\fR, or +adapter \fI0.0.fc00\fR and port \fI0x5005abcdefabc000\fR. .TP .B "lsluns -a" adapter = 0.0.3c02 @@ -64,4 +96,9 @@ adapter = 0.0.3c02 lun = 0x401040a200000000(X) /dev/sg0 Disk IBM:2107900 lun = 0x401040a300000000 /dev/sg1 Disk IBM:2107900 -Shows all active LUNs including the information whether the device is encrypted or not. +Shows the encryption status of attached LUNs. A bracketed X suffixed to a LUN +indicates that the device is encrypted. + +.SH "SEE ALSO" +.BR lszfcp (8), +.BR lsscsi (8) ++++++ s390-tools-sles15-lsluns-fix-flawed-formatting-of-man-page.patch ++++++ Subject: [PATCH] [BZ 161888] lsluns: fix flawed formatting of man page From: Jens Remus <[email protected]> Description: lsluns: Fix filter handling and documentation enhancements. Symptom: lsluns lists all LUNs discovered in the FC SAN despite user given filter(s) that do not match anything: # lsluns -c 0.0.5080 No valid combination found for adapter '0.0.5080'. Removing from resource list. No valid parameters left, using all available resources in system. Scanning for LUNs on adapter 0.0.5090 ... lsluns prints the message "No valid combination found for {adapter|port} '...'. Removing from resource list." for every adapter and port filter that does not contribute to the final filtered results. The formatting of the lsluns (8) man page is flawed. lsluns is used in unexpected or even unsupported ways. Problem: Scanning can be resource consumptive. So if a user already wants to filter, possibly to reduce resource consumption, he does not want to happen to scan everything and thus consume the worst case of resources. The message "No valid combination found for {adapter|port} '...'. Removing from resource list." is potentially confusing. It is unclear which combination is being referred to, especially if only one single adapter or port filter was specified. There is also no differentiation whether the denoted adapter or port exists for its own or not. It just does not exist in the final filtered results. The formatting of the lsluns (8) man page is flawed. The lsluns usage text and lsluns (8) man page lack the information on the intended use cases, requirements, and restrictions. Solution: Print a message and exit when all filters match nothing. Do not print confusing messages when a filter matches nothing. Fix man page formatting. Enhance usage text and man page. Clarify discovery use case, relation to NPIV and to zfcp auto LUN scan. Point out IBM Storwize configuration requirements. Document restriction to zfcp-only systems. Reproduction: Use lsluns and specify adapter bus-ID and/or target port WWPN filter(s) that do not match anything. Either specify inexistent bus-IDs and/or WWPNs or invalid filter arguments. Upstream-ID: d81c4234295f481559a74fb5ad5f498692ff5738 Problem-ID: 161888 Upstream-Description: lsluns: fix flawed formatting of man page The formatting in the SYNOPSIS, OPTIONS, and EXAMPLES sections was flawed in the lsluns(8) man page: * The comma between short and long options were erroneously formatted in bold, which would indicate to be typed exactly as shown. [see man(1)] * The option parameters (e.g. adapter and port) were erroneously formatted in bold instead of italic text (usually displayed as underlined on the console), which would again indicate to be typed exactly as shown instead of to be replaced with the appropriate argument. [see man(1)] * Ellipses were missing after the the options that may be specified multiple times (e.g. adapter and port). [see man(1)] * Dashes in options in the SYNOPSIS and OPTIONS section needed to be escaped. [see man-pages(7)] * User input in example shell sessions should have been formatted in bold. [see man-pages(7)] Correct formatting based on man(7) and man-pages(7) man pages as reference. Add proper spacing between options and their surrounding square brackets and between the three periods of ellipses. Signed-off-by: Jens Remus <[email protected]> Reviewed-by: Steffen Maier <[email protected]> Reviewed-by: Benjamin Block <[email protected]> Signed-off-by: Michael Holzheu <[email protected]> Signed-off-by: Jens Remus <[email protected]> --- zconf/lsluns.8 | 42 +++++++++++++++++++++++------------------- 1 file changed, 23 insertions(+), 19 deletions(-) --- a/zconf/lsluns.8 +++ b/zconf/lsluns.8 @@ -8,12 +8,12 @@ lsluns \- list available LUNs .SH SYNOPSIS .B lsluns -.RB [ \-h] -.RB [ \-v] -.RB [ \-c -.IR adapter id:0.0.XXXX ] +.RB [\| \-h \|] +.RB [\| \-v \|] +.RB [\| \-c +.IR adapter\ id:0.0.XXXX \|]\ .\|.\|. .RB [ \-p -.IR port number:0xXXXXXXXXXXXXXXXX ] +.IR port\ number:0xXXXXXXXXXXXXXXXX \|]\ .\|.\|. .SH DESCRIPTION .PP @@ -25,36 +25,40 @@ limited by specifying an adapter or a po .SH OPTIONS .TP -.B -h, --help +.BR \-h ", " \-\-help Print help message and exit. .TP -.B -v, --version +.BR \-v ", " \-\-version Display version info and exit. .TP -.B -c, --ccw +.BI \-c\ adapter \fR,\ \fB\-\-ccw= adapter Shows LUNs for a specific adapter. .TP -.B -p, --port +.BI \-p\ port \fR,\ \fB\-\-port= port Shows LUNs for a specific port. .TP -.B -a, --active +.BR \-a ", " \-\-active Shows all activated LUNs. In addition information is provided whether the LUN is encrypted or not. This is indicated with a bracketed X right after the LUN number. .SH EXAMPLES -.PP -.IP "lsluns" +.TP +.B "lsluns" .RS Shows all available LUNs. .RE -.IP "lsluns -c 0.0.3922" -Shows all LUNs found on adapter 0.0.3922. -.IP "lsluns -p 0x5005123456789000" -Shows all LUNs for port 0x5005123456789000. -.IP "lsluns -c 0.0.3922 -p 0x5005123456789000" -Shows all LUNs for adapter 0.0.3922 and port 0x5005123456789000. -.IP "lsluns -a " +.TP +.BI "lsluns \-c " 0.0.3922 +Shows all LUNs found on adapter \fI0.0.3922\fR. +.TP +.BI "lsluns \-p " 0x5005123456789000 +Shows all LUNs for port \fI0x5005123456789000\fR. +.TP +.BI "lsluns \-c " 0.0.3922 " \-p " 0x5005123456789000 +Shows all LUNs for adapter \fI0.0.3922\fR and port \fI0x5005123456789000\fR. +.TP +.B "lsluns -a" adapter = 0.0.3c02 port = 0x500507630300c562 lun = 0x401040a200000000(X) /dev/sg0 Disk IBM:2107900 ++++++ s390-tools-sles15-lsluns-point-out-IBM-Storwize-configuration-requirem.patch ++++++ Subject: [PATCH] [BZ 161888] lsluns: point out IBM Storwize configuration requirements From: Jens Remus <[email protected]> Description: lsluns: Fix filter handling and documentation enhancements. Symptom: lsluns lists all LUNs discovered in the FC SAN despite user given filter(s) that do not match anything: # lsluns -c 0.0.5080 No valid combination found for adapter '0.0.5080'. Removing from resource list. No valid parameters left, using all available resources in system. Scanning for LUNs on adapter 0.0.5090 ... lsluns prints the message "No valid combination found for {adapter|port} '...'. Removing from resource list." for every adapter and port filter that does not contribute to the final filtered results. The formatting of the lsluns (8) man page is flawed. lsluns is used in unexpected or even unsupported ways. Problem: Scanning can be resource consumptive. So if a user already wants to filter, possibly to reduce resource consumption, he does not want to happen to scan everything and thus consume the worst case of resources. The message "No valid combination found for {adapter|port} '...'. Removing from resource list." is potentially confusing. It is unclear which combination is being referred to, especially if only one single adapter or port filter was specified. There is also no differentiation whether the denoted adapter or port exists for its own or not. It just does not exist in the final filtered results. The formatting of the lsluns (8) man page is flawed. The lsluns usage text and lsluns (8) man page lack the information on the intended use cases, requirements, and restrictions. Solution: Print a message and exit when all filters match nothing. Do not print confusing messages when a filter matches nothing. Fix man page formatting. Enhance usage text and man page. Clarify discovery use case, relation to NPIV and to zfcp auto LUN scan. Point out IBM Storwize configuration requirements. Document restriction to zfcp-only systems. Reproduction: Use lsluns and specify adapter bus-ID and/or target port WWPN filter(s) that do not match anything. Either specify inexistent bus-IDs and/or WWPNs or invalid filter arguments. Upstream-ID: 5f768dd52d87efddbd7efa23d57c6da62281728b Problem-ID: 161888 Upstream-Description: lsluns: point out IBM Storwize configuration requirements Signed-off-by: Steffen Maier <[email protected]> Reviewed-by: Jens Remus <[email protected]> Signed-off-by: Michael Holzheu <[email protected]> Signed-off-by: Jens Remus <[email protected]> --- zconf/lsluns | 4 ++++ zconf/lsluns.8 | 12 ++++++++++++ 2 files changed, 16 insertions(+) --- a/zconf/lsluns +++ b/zconf/lsluns @@ -177,6 +177,10 @@ $PROGRAM_NAME [-c <busid>] ... [-p <wwpn Discovering LUNs only makes sense for NPIV-enabled FCP devices without zfcp automatic LUN scan. zfcp automatic LUN scan is available as of kernel version 2.6.37, if not disabled with zfcp.allow_lun_scan=0. + For storage products that do not support a REPORT LUNS + well-known logical unit (such as IBM Storwize products), + ensure that LUN 0 represents a valid peripheral device type. + See the man page for more information. $PROGRAM_NAME -a [-c <busid>] ... [-p <wwpn>] ... [-h] [-v] --- a/zconf/lsluns.8 +++ b/zconf/lsluns.8 @@ -64,6 +64,18 @@ If not attached already, lsluns temporar Do not terminate lsluns with a signal. Signals interfere with the removal of temporarily attached LUNs. +.TP +Storage Products +Some storage products return a peripheral device type of 31==0x1f +with peripheral qualifier 0 in a SCSI standard INQUIRY command +for an unmapped FCP LUN 0. Examples are: IBM Storwize products, +including IBM V7000, IBM V840, IBM V9000, and IBM SAN Volume Controller. +For lsluns to work with such storage products, +you must have a host mapping on the storage, which maps some volume +to exported FCP LUN 0x0000000000000000 (Storwize host map property "SCSI ID" 0) +for each used FCP-device initiator WWPN. The volume can be +a minimum-sized thin-provisioned shared stand-in volume. + .SH OPTIONS .TP .BR \-a ", " \-\-active ++++++ s390-tools-sles15-mon_tools-Improve-systemctl-start-error-handling.patch ++++++ Subject: [PATCH] [BZ 161563] mon_tools: Improve systemctl start error handling From: Gerald Schaefer <[email protected]> Description: cpuplugd, mon_tools: Improve systemctl start error handling Symptom: "systemctl start cpuplugd/mon_procd/mon_fsstatd" does not report any errors in case the startup fails. Problem: For type=simple, systemd forks/execs the process and if that is successful, it immediately returns. There is no way to find out if the initial startup fails. Solution: Use type=fork and run the process in the background. In this case systemd waits until the initial process returns. In addition, use PIDFile and ensure that the pid file is already available when the initial process returns. To achieve this, use startup synchronization via pipe. Reproduction: Add invalid values to the config files and start the daemons with "systemctl start cpuplugd/mon_procd/mon_fsstatd". Upstream-ID: 780133f825687bc931489aaf13959c793d2a4501 Problem-ID: 161563 Upstream-Description: mon_tools: Improve systemctl start error handling This fixes the same issue as in commit 82c8148983fc ("cpuplugd: Improve systemctl start error handling") for mon_tools (mon_procd and mon_fsstatd). Currently "systemctl start mon_procd/fsstatd" does not report any errors in case the startup fails. Example (with mon_procd): (change interval in /etc/sysconfig/mon_procd to an invalid value "abc") # systemctl start mon_procd The reason is that for type=simple systemd forks/execs mon_procd and if that is successful immediately returns. There is no way to find out if the initial startup fails. Fix this by using type=fork and running the process in the background. In this case systemd waits until the initial process returns. In addition use PIDFile and ensure that the pid file is already available when the initial process returns. To achieve this, use startup synchronization via pipe. Without that systemd would print the following warning: systemd[1]: mon_procd.service: PID file /var/run/mon_procd.pid not readable (yet?) after start: No such file or directory With this patch, an early startup error like in the example above, is now reported correctly in "systemctl start": # systemctl start mon_procd Job for mon_procd.service failed because the control process exited... See "systemctl status mon_procd.service" and "journalctl -xe" for ... # journalctl -xe | grep mon_procd mon_procd[3184]: Error: Invalid interval (needs to be greater than 0) Signed-off-by: Gerald Schaefer <[email protected]> Signed-off-by: Michael Holzheu <[email protected]> Signed-off-by: Gerald Schaefer <[email protected]> --- mon_tools/mon_fsstatd.c | 40 ++++++++++++++++++++++++++++++++-------- mon_tools/mon_procd.c | 40 ++++++++++++++++++++++++++++++++-------- systemd/mon_fsstatd.service.in | 5 +++-- systemd/mon_procd.service.in | 5 +++-- 4 files changed, 70 insertions(+), 20 deletions(-) --- a/mon_tools/mon_fsstatd.c +++ b/mon_tools/mon_fsstatd.c @@ -90,17 +90,18 @@ static void fsstatd_open_monwriter(void) /* * Store daemon's pid so it can be stopped */ -static void store_pid(void) +static int store_pid(void) { FILE *f = fopen(pid_file, "w"); if (!f) { syslog(LOG_ERR, "cannot open pid file %s: %s", pid_file, strerror(errno)); - exit(1); + return -1; } fprintf(f, "%d\n", getpid()); fclose(f); + return 0; } /* @@ -244,41 +245,64 @@ static void fsstatd_write_ent(struct mnt */ static void fsstatd_daemonize(void) { + int pipe_fds[2], startup_rc = 1; pid_t pid; + if (pipe(pipe_fds) == -1) { + syslog(LOG_ERR, "pipe error: %s\n", strerror(errno)); + exit(1); + } + /* Fork off the parent process */ pid = fork(); if (pid < 0) { syslog(LOG_ERR, "fork error: %s\n", strerror(errno)); exit(1); } - if (pid > 0) - exit(0); + if (pid > 0) { + /* Wait for startup return code from daemon */ + if (read(pipe_fds[0], &startup_rc, sizeof(startup_rc)) == -1) + syslog(LOG_ERR, "pipe read error: %s\n", strerror(errno)); + /* With startup_rc == 0, pid file was written at this point */ + exit(startup_rc); + } /* Change the file mode mask */ umask(0); - /* Store daemon pid */ - store_pid(); /* Catch SIGINT and SIGTERM to clean up pid file on exit */ fsstatd_handle_signals(); /* Create a new SID for the child process */ if (setsid() < 0) { syslog(LOG_ERR, "setsid error: %s\n", strerror(errno)); - exit(1); + goto notify_parent; } /* Change the current working directory */ if (chdir("/") < 0) { syslog(LOG_ERR, "chdir error: %s\n", strerror(errno)); - exit(1); + goto notify_parent; } /* Close out the standard file descriptors */ close(STDIN_FILENO); close(STDOUT_FILENO); close(STDERR_FILENO); + + /* Store daemon pid */ + if (store_pid() < 0) + goto notify_parent; + startup_rc = 0; + +notify_parent: + /* Inform waiting parent about startup return code */ + if (write(pipe_fds[1], &startup_rc, sizeof(startup_rc)) == -1) { + syslog(LOG_ERR, "pipe write error: %s\n", strerror(errno)); + exit(1); + } + if (startup_rc != 0) + exit(startup_rc); } static int fsstatd_do_work(void) --- a/mon_tools/mon_procd.c +++ b/mon_tools/mon_procd.c @@ -109,17 +109,18 @@ static void procd_open_monwriter(void) /* * Store daemon's pid so it can be stopped */ -static void store_pid(void) +static int store_pid(void) { FILE *f = fopen(pid_file, "w"); if (!f) { syslog(LOG_ERR, "cannot open pid file %s: %s", pid_file, strerror(errno)); - exit(1); + return -1; } fprintf(f, "%d\n", getpid()); fclose(f); + return 0; } /* @@ -897,41 +898,64 @@ static void read_tasks(void) */ static void procd_daemonize(void) { + int pipe_fds[2], startup_rc = 1; pid_t pid; + if (pipe(pipe_fds) == -1) { + syslog(LOG_ERR, "pipe error: %s\n", strerror(errno)); + exit(1); + } + /* Fork off the parent process */ pid = fork(); if (pid < 0) { syslog(LOG_ERR, "fork error: %s\n", strerror(errno)); exit(1); } - if (pid > 0) - exit(0); + if (pid > 0) { + /* Wait for startup return code from daemon */ + if (read(pipe_fds[0], &startup_rc, sizeof(startup_rc)) == -1) + syslog(LOG_ERR, "pipe read error: %s\n", strerror(errno)); + /* With startup_rc == 0, pid file was written at this point */ + exit(startup_rc); + } /* Change the file mode mask */ umask(0); - /* Store daemon pid */ - store_pid(); /* Catch SIGINT and SIGTERM to clean up pid file on exit */ procd_handle_signals(); /* Create a new SID for the child process */ if (setsid() < 0) { syslog(LOG_ERR, "setsid error: %s\n", strerror(errno)); - exit(1); + goto notify_parent; } /* Change the current working directory */ if (chdir("/") < 0) { syslog(LOG_ERR, "chdir error: %s\n", strerror(errno)); - exit(1); + goto notify_parent; } /* Close out the standard file descriptors */ close(STDIN_FILENO); close(STDOUT_FILENO); close(STDERR_FILENO); + + /* Store daemon pid */ + if (store_pid() < 0) + goto notify_parent; + startup_rc = 0; + +notify_parent: + /* Inform waiting parent about startup return code */ + if (write(pipe_fds[1], &startup_rc, sizeof(startup_rc)) == -1) { + syslog(LOG_ERR, "pipe write error: %s\n", strerror(errno)); + exit(1); + } + if (startup_rc != 0) + exit(startup_rc); } static int procd_do_work(void) --- a/systemd/mon_fsstatd.service.in +++ b/systemd/mon_fsstatd.service.in @@ -30,10 +30,11 @@ EnvironmentFile=/etc/sysconfig/mon_fssta ExecStartPre=-/sbin/modprobe monwriter ExecStartPre=/sbin/udevadm settle --timeout=10 -ExecStart=@usrsbin_path@/mon_fsstatd -a -i $FSSTAT_INTERVAL +ExecStart=@usrsbin_path@/mon_fsstatd -i $FSSTAT_INTERVAL ExecReload=/bin/kill -HUP $MAINPID KillMode=process -Type=simple +Type=forking +PIDFile=/var/run/mon_fsstatd.pid [Install] WantedBy=multi-user.target --- a/systemd/mon_procd.service.in +++ b/systemd/mon_procd.service.in @@ -30,10 +30,11 @@ EnvironmentFile=/etc/sysconfig/mon_procd ExecStartPre=-/sbin/modprobe monwriter ExecStartPre=/sbin/udevadm settle --timeout=10 -ExecStart=@usrsbin_path@/mon_procd -a -i $PROC_INTERVAL +ExecStart=@usrsbin_path@/mon_procd -i $PROC_INTERVAL ExecReload=/bin/kill -HUP $MAINPID KillMode=process -Type=simple +Type=forking +PIDFile=/var/run/mon_procd.pid [Install] WantedBy=multi-user.target ++++++ s390-tools-sles15-zdev-Enable-running-chzdev-from-unknown-root-devices.patch ++++++ >From 2a6a28023bdfe127be68ac605f9a026a82884c80 Mon Sep 17 00:00:00 2001 From: Peter Oberparleiter <[email protected]> Date: Tue, 5 Dec 2017 15:40:23 +0100 Subject: [PATCH 1/4] zdev: Enable running chzdev from unknown root devices When a persistent device configuration is changed, chzdev tries to find out if it needs to perform additional steps to make this change persistent. If this check fails, for example because the root device is located on a RAM-disk, or on a device type not managed by chzdev, the tool reports an error and exits with non-zero exit code: chzdev: Could not determine device that provides / or chzdev: Could not determine device that provides loop0 This behavior unnecessarily restricts chzdev from being used in scripted environments like an installation initial RAM-disk. Fix this by removing the non-zero exit code and moving the message to verbose output mode only. Signed-off-by: Peter Oberparleiter <[email protected]> Signed-off-by: Michael Holzheu <[email protected]> --- zdev/src/root.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/zdev/src/root.c b/zdev/src/root.c index 7f0d39f..668bdbd 100644 --- a/zdev/src/root.c +++ b/zdev/src/root.c @@ -35,9 +35,14 @@ exit_code_t root_check(void) /* Get list of devices that provide the root device. */ selected = selected_dev_list_new(); rc = select_by_path(NULL, selected, config_active, scope_mandatory, - NULL, NULL, PATH_ROOT, err_print); - if (rc) + NULL, NULL, PATH_ROOT, err_ignore); + if (rc) { + /* Running from an unknown root device is not an error. */ + verb("Note: Could not determine if root device configuration " + "needs to be updated\n"); + rc = 0; goto out; + } /* Determine if any of the devices or device types has been modified. */ mod = strlist_new(); -- 2.13.6 ++++++ s390-tools-sles15-zdev-Fix-zdev-dracut-module-aborting-on-unknown-root.patch ++++++ >From 0348a8443e5f15636f86ef2533a7d6e8fa5d936d Mon Sep 17 00:00:00 2001 From: Peter Oberparleiter <[email protected]> Date: Thu, 7 Dec 2017 17:21:11 +0100 Subject: [PATCH 4/4] zdev: Fix zdev dracut module aborting on unknown root device Running dracut when the root device is not known to zdev (for example because it is located on a virtio block device) will cause the zdev dracut module to incorrectly return an error in the installkernel() function. As a result dracut aborts with an error. Fix this by ensuring that the non-zero exit code resulting from lszdev not being able to determine the root device is not passed on to the calling function. Also remove unnecessary error output in this case by leaving the install() function early when the root device is not known to zdev. Signed-off-by: Peter Oberparleiter <[email protected]> Signed-off-by: Michael Holzheu <[email protected]> --- zdev/dracut/95zdev/module-setup.sh | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/zdev/dracut/95zdev/module-setup.sh b/zdev/dracut/95zdev/module-setup.sh index 7c67cd7..4c13a65 100644 --- a/zdev/dracut/95zdev/module-setup.sh +++ b/zdev/dracut/95zdev/module-setup.sh @@ -29,13 +29,21 @@ depends() { } installkernel() { - local _modules=$(lszdev --by-path / --columns MODULES --no-headings) + local _modules=$(lszdev --by-path / --columns MODULES --no-headings 2>/dev/null) + [ -z "$_modules" ] && return 0 [ ! -z "$_modules" ] && instmods $_modules } install() { - local _tempfile=$(mktemp --tmpdir dracut-zdev.XXXXXX) + local _tempfile + + # Exit early if root device type is unknown + if ! lszdev --by-path / >/dev/null 2>&1 ; then + return 0 + fi + + _tempfile=$(mktemp --tmpdir dracut-zdev.XXXXXX) if chzdev --export - --persistent --by-path / >/dev/null 2>&1 ; then # Use persistent configuration -- 2.13.6 ++++++ s390-tools-sles15-zdev-Use-correct-path-to-vmcp-binary.patch ++++++ --- /var/tmp/diff_new_pack.HMbqkN/_old 2017-12-12 21:19:13.813258441 +0100 +++ /var/tmp/diff_new_pack.HMbqkN/_new 2017-12-12 21:19:13.817258248 +0100 @@ -22,7 +22,7 @@ index b9a9f54..bb6cdf0 100644 --- a/common.mak +++ b/common.mak -@@ -194,12 +194,14 @@ ALL_CFLAGS = -DS390_TOOLS_RELEASE=$(S390_TOOLS_RELEASE) \ +@@ -193,12 +193,14 @@ ALL_CFLAGS = -DS390_TOOLS_RELEASE=$(S390_TOOLS_RELEASE) \ -DS390_TOOLS_LIBDIR=$(TOOLS_LIBDIR) \ -DS390_TOOLS_DATADIR=$(TOOLS_DATADIR) \ -DS390_TOOLS_SYSCONFDIR=$(SYSCONFDIR) \ ++++++ s390-tools-sles15-ziomon-re-add-missing-line.patch ++++++ Subject: [PATCH] [BZ 161467] ziomon: Re-add missing line in ziomon_fcpconf From: Michael Holzheu <[email protected]> Description: ziomon: Re-add missing line in ziomon_fcpconf Symptom: ziomon_fcpconf fails on startup with: Global symbol "$map_dev" requires explicit package name ... Problem: During the GPL to MIT conversion process from v1.39.0 to v2.0.0 one line has been lost by accident. Solution: Re-add that line again. Reproduction: Call the ziomon_fcpconf tool. Upstream-ID: 523d833eb31633673847b6da0edbd35903f14dc4 Problem-ID: 161467 Signed-off-by: Michael Holzheu <[email protected]> --- ziomon/ziomon_fcpconf | 1 + 1 file changed, 1 insertion(+) --- a/ziomon/ziomon_fcpconf +++ b/ziomon/ziomon_fcpconf @@ -58,6 +58,7 @@ sub store_mapper_devices my $src_dir = shift(); my @entries = grep { ! /^\./ } dir_content($src_dir); + foreach my $map_dev (@entries) { my $tf = catfile($src_dir, "$map_dev"); my $mm = `stat -L -c%t:%T $tf`; chomp($mm); ++++++ s390-tools-sles15-zipl-remove-invalid-dasdview-command-line-option.patch ++++++ Subject: [PATCH] [BZ 161183] zipl: remove invalid dasdview command line option From: Stefan Haberland <[email protected]> Description: zipl: remove invalid dasdview command line option Symptom: zipl does not work when used with a lvm or device mapper target. Problem: The zipl_helper.device-mapper script uses dasdview with an option "-f" that has been removed recently. Solution: Remove "-f" from the dasdview call. Reproduction: Run zipl on a lvm target. Upstream-ID: - Problem-ID: 161183 Signed-off-by: Stefan Haberland <[email protected]> --- zipl/src/zipl_helper.device-mapper | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/zipl/src/zipl_helper.device-mapper +++ b/zipl/src/zipl_helper.device-mapper @@ -623,7 +623,7 @@ sub get_dasd_info($) my $type; local *HANDLE; - open(HANDLE, "$dasdview -x -f $dev 2>/dev/null|") or + open(HANDLE, "$dasdview -x $dev 2>/dev/null|") or # dasdview returned with an error return undef; while (<HANDLE>) { ++++++ zfcp_disk_configure ++++++ --- /var/tmp/diff_new_pack.HMbqkN/_old 2017-12-12 21:19:13.961251296 +0100 +++ /var/tmp/diff_new_pack.HMbqkN/_new 2017-12-12 21:19:13.961251296 +0100 @@ -62,11 +62,11 @@ FCP_LUN=$(echo ${FCP_LUN} | tr "A-Z" "a-z") if [ "${ON_OFF}" == 0 ]; then - debug_mesg "chzdev -d zfcp-lun ${CCW_CHAN_ID}:${FCP_WWPN}:${FCP_LUN}" - chzdev -d zfcp-lun ${CCW_CHAN_ID}:${FCP_WWPN}:${FCP_LUN} + debug_mesg "chzdev -d zfcp-lun --no-root-update ${CCW_CHAN_ID}:${FCP_WWPN}:${FCP_LUN}" + chzdev -d zfcp-lun --no-root-update ${CCW_CHAN_ID}:${FCP_WWPN}:${FCP_LUN} elif [ "${ON_OFF}" == 1 ]; then - debug_mesg "chzdev -e zfcp-lun ${CCW_CHAN_ID}:${FCP_WWPN}:${FCP_LUN}" - chzdev -e zfcp-lun ${CCW_CHAN_ID}:${FCP_WWPN}:${FCP_LUN} + debug_mesg "chzdev -e zfcp-lun --no-root-update ${CCW_CHAN_ID}:${FCP_WWPN}:${FCP_LUN}" + chzdev -e zfcp-lun --no-root-update ${CCW_CHAN_ID}:${FCP_WWPN}:${FCP_LUN} else mesg "You must specify a 0 or a 1 for the online/offline attribute." usage exit 1 ++++++ zfcp_host_configure ++++++ --- /var/tmp/diff_new_pack.HMbqkN/_old 2017-12-12 21:19:13.997249559 +0100 +++ /var/tmp/diff_new_pack.HMbqkN/_new 2017-12-12 21:19:13.997249559 +0100 @@ -74,11 +74,11 @@ fi if [ "${ON_OFF}" == 0 ]; then - debug_mesg "chzdev -d zfcp-host ${CCW_CHAN_ID}" - chzdev -d zfcp-host ${CCW_CHAN_ID} + debug_mesg "chzdev -d zfcp-host --no-root-update ${CCW_CHAN_ID}" + chzdev -d zfcp-host --no-root-update ${CCW_CHAN_ID} elif [ "${ON_OFF}" == 1 ]; then - debug_mesg "chzdev -e zfcp-host ${CCW_CHAN_ID}" - chzdev -e zfcp-host ${CCW_CHAN_ID} + debug_mesg "chzdev -e zfcp-host --no-root-update ${CCW_CHAN_ID}" + chzdev -e zfcp-host --no-root-update ${CCW_CHAN_ID} else mesg "You must specify a 0 or a 1 for the online/offline attribute." usage exit 1
