Fix possible c&p mistake when checking the presence of `queue_full` attribute
in old kernels. There should be no impact on how the tool works other than
exiting gracefully in case the attribute does not exist.
Fixes: #21
Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com>
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
On Fedora 27 "net-snmp-config --agent-libs" returns
"--specs=/usr/lib/rpm/redhat/redhat-hardened-ld" which introduces "-pie":
# cat /usr/lib/rpm/redhat/redhat-hardened-ld
*self_spec:
+ %{!static:%{!shared:%{!r:-pie}}}
*link:
+ -z now
This leads to the following link error:
/usr/bin/ld: osasnmpd.o: `getopt_long@@GLIBC_2.2' non-PLT reloc for symbol
defined in shared library and accessed from executable
(rebuild file with -fPIC ?)
/usr/bin/ld: final link failed: Bad value
Add -fPIC to CLFAGS as a workaround to enbable linking again.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
For systems that do not have glibc-static installed, print the
following error message when building zfcpdump:
s390-tools/zfcpdump # make
REQCHK zfcpdump (stdio.h)
****************************************************************
* Missing build requirement for: zfcpdump *
* Install package..............: glibc-static or libc-dev *
* You can skip build with......: make HAVE_LIBC_STATIC=0 *
****************************************************************
To allow the check add a new compiler/linker option to the "check_dep"
macro and do full compile/link instead of a simple compile.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
This fixes the same issue as in commit 82c8148983 ("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 <gerald.schaefer@de.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
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 <holzheu@linux.vnet.ibm.com>
Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
During the GPL to MIT conversion process from v1.39.0 to v2.0.0 one line has
been lost by accident. Fix this and re-add that line again.
Fixes: #17
Reported-by: Mikhail Obirvalger
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
So far it infinitely retried the bootscript, that doesn#t seem
reasonable. Per IRC discussion this is now changed to a 600 sec timeout
waiting for a config to appear to then run once on that config.
In case the pxe boot fails the it is now no more a retry loop, but
instead considered a crash as init exits.
Closes: #16
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Acked-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Currently multiple entries in a single append is broken by how the
shell in busybox escapes them. No usual grouping with " or ' will
work but calling them directly but without the --append in the
variable will let busybox do the right thing.
GitHub-ID: #16
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Acked-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Currently for a user the pxe boot seems unclear and it
is hard to follow what is going on.
- Report on when (re-)starting the bootscript.
- Report configs fetched (Without e.g. on a virsh console
one only sees a loop of timeouts.)
- Report which config is missing on the PXE_CONF check
- Report kexec calls made
GitHub-ID: #16
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Acked-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
lsmem/chmem moved to util-linux >= 2.30, remove them from s390-tools.
For kernels >= 4.13, the default memory zone for hotplug memory was
changed from zone MOVABLE to zone NORMAL. In order to keep using zone
MOVABLE for memory hotplug, either use the lsmem/chmem tools from
s390-tools version 2.1.0, or an updated version of the util-linux
version of lsmem/chmem that contains the following util-linux git
commits (included in util-linux 2.32):
60a7e9e94e49 "lsmem/chmem: add memory zone awareness"
0a4320f5e785 "tests/lsmem: update lsmem test with ZONES column"
afee3f204247 "lsmem/chmem: add memory zone awareness to bash-completion"
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
The zdev tools use a hard-coded path to locate the vmcp binary. Since
this path may differ between distributions, the vmcp binary may not be
successfully located in all cases. Fix this by using the BINDIR macro
to determine the correct path. This macro is also used during
installation of the vmcp binary itself.
Reviewed-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
If SYSTEMDSYSTEMUNITDIR is defined, the systemd units are automatically
installed. Therefore consequently also install the required config files
in that case.
Example:
$ make install SYSTEMDSYSTEMUNITDIR=/usr/lib/systemd/system/
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
dasdview command does not accept the '-f' option so because of that the
command will always fail.
Fixes: #10
Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com>
Acked-by: Stefan Haberland <sth@linux.vnet.ibm.com>
Signed-off-by: Stefan Haberland <sth@linux.vnet.ibm.com>
When doing parallel builds, we currently get the following error for
iucvterm:
~/s390-tools/iucvterm (bb/holzheu/install-configs)# make install -j
INSTALL iucvterm
CC iucvterm/src/iucvconn.o
INSTALL iucvterm/src
CC iucvterm/src/getopt.o
install: cannot stat 'iucvconn': No such file or directory
install: cannot stat 'iucvtty': No such file or directory
Makefile:19: recipe for target 'install' failed
Fix this and "all" as explicit dependency to the install target.
Reviewed-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Stefan Haberland <sth@linux.vnet.ibm.com>
The cpi service unit requires an Install section to tell systemd
when to start the cpi service. Add an install section and start
cpi for the multi-user target.
Reported-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: Stefan Haberland <sth@linux.vnet.ibm.com>
The man page date was AUG 2008. Changed to OCT 2017.
A previous commit had a wrong indentation on following
options text for lszcrypt. Fixed.
Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
Signed-off-by: Stefan Haberland <sth@linux.vnet.ibm.com>
Commit 3c80f7e025 ("dasdinfo: fix buffer overflow warning") changed a
sprintf call to snprintf to avoid a buffer overflow warning. However,
GCC 7 now warns about a potential truncation with snprintf:
dasdinfo.c: In function 'main':
dasdinfo.c:577:18: warning: '%s' directive output may be truncated
writing up to 255 bytes into a region of size 69 [-Wformat-truncation=]
"/sys/block/%s/device/uid", dir_entry->d_name);
^~
dasdinfo.c:576:4: note: 'snprintf' output between 23 and 278 bytes into
a destination of size 80
snprintf(*uidfile, RD_BUFFER_SIZE,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"/sys/block/%s/device/uid", dir_entry->d_name);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We could get around this by increasing the buffer. Though, the current
buffer size is already plenty and we know better anyway.
Avoid the warning by simply checking the return value of snprintf and
display an error in case data was truncated nonetheless.
Fixes: 3c80f7e025 ("dasdinfo: fix buffer overflow warning")
Signed-off-by: Jan Höppner <hoeppner@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
With z14 there comes a new crypto card 'CEX6S'.
This patch introduces the s390-tools changes needed
to list the new card and show the capabilities correctly.
Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
get_device_name() contains a chunk of unreachable code, as the
'name' argument is never filled with any value.
So turn things around to have get_device_name() always fill the
'name' argument with the real device name, and remove the
devname entry from the dasdfmt_info_t structure.
GitHub-ID: #8
Signed-off-by: Hannes Reinecke <hare@suse.com>
Acked-by: Jan Höppner <hoeppner@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
dasdfmt_get_volser() opens its own private filedescriptor
despite the global filedes already being opened.
And we should be passing in only the bits of the info structure
that we actually need.
GitHub-ID: #8
Signed-off-by: Hannes Reinecke <hare@suse.com>
Acked-by: Jan Höppner <hoeppner@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
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 <maier@linux.vnet.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.vnet.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
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 <jremus@linux.vnet.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.vnet.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
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 <maier@linux.vnet.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.vnet.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.vnet.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
