The existing code can already determine the required devices for the
actively running system, but this does not work for execution environments
in different (disaster recovery) sites.
Kdump likely does not notice when running in a different site and does not
re-generate the kdump initrd (because the kdump config itself does not
change).
The new code allows users to explicitly specify devices required for early
boot in initrd on different sites. Assuming this is a small number of
devices and could even overlap between the root-fs and the kdump case, do
not further distinguish those two sets of devices, but simply use the same
marker attribute "zdev:early=1" for both cases. With all this site
information available at the (initial) kdump initrd generation, the
resulting kdump initrd can work on any site without having to re-generate.
Complements commit 3c7adcc3c81d ("zdev: dracut: modifiy the
module-setup.sh").
Github-ID: https://github.com/ibm-s390-linux/s390-tools/pull/158
Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Acked-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The existing code can already determine the required devices for the
actively running system. In case users would have a need to configure
additional devices for early boot in kdump initrd, import those devices
marked with "zdev:early=1" for completeness. Assuming this is a small
number of devices and could even overlap between the root-fs and the kdump
case, do not further distinguish those two sets of devices.
Github-ID: https://github.com/ibm-s390-linux/s390-tools/pull/158
Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Acked-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Additional debugging output can be generated with e.g. dracut option
"--stdlog 5" (or short -L5). It shows the chzdev export result, the output
of chzdev imports, and an overview of the resulting persistent config
within the initrd.
On systems, which default to using dracut option "--quiet", you might need
an additional "--verbose" to counter "--quiet" so -L5 has effect.
Typically combined with "--debug" to get a shell trace from building an
initrd (Note: --debug does not increase the log levels).
Github-ID: https://github.com/ibm-s390-linux/s390-tools/pull/158
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Acked-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Otherwise, dracut skips modules that are "not hostonly", i.e. not used /
loaded on the system when running dracut to build an initrd.
Without the fix, zdev device auto configuration only works for device
types for which a device driver happened to be loaded when building an
initrd. Likewise for specifying rd.* boot options.
Hostonly mode is often the default in Linux distributions.
Make zdev device auto configuration work nonetheless without users
having to know about and tweak dracut modes for initrd generation.
On the typical sloppy hostonly mode, the code disables hostonly for
installing kernel modules. This covers building regular initrds, where zdev
device auto configuration should even work for device types, for which
device drivers were not loaded when an initrd was generated. This can
happen when new devices of new types are configured for a DPM logical
partition. Also, users could want to start using dracut cmdline options
rd.{dasd,zfcp,znet} for a device type that was not used when the initrd was
built.
The special strict hostonly mode is used by some kdump implementations. In
that case, hostonly remains in effect intentionally because only support
for the really required devices as determined by dracut module 95zdev-kdump
should be included in a kdump initrd due to the memory-constrained kdump
environment. Cf. commit 73c46a3056 ("zdev/dracut: fix kdump by only
activating required devices"), which also provides more references on
strict hostonly mode. Even for non-kdump cases, let strict hostonly mode be
effective here in 95zdev in case some future use case appears for this
special mode beyond kdump.
Github-ID: https://github.com/ibm-s390-linux/s390-tools/pull/158
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Acked-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Currently ZDEV_SITE_ID is derived with the help of an additional
udev-rule, 40-zdev-id.rules. The sole purpose of this rule is to
determine the ZDEV_SITE_ID environment value with the help of zdev_id
binary. This solution is minimal, but this has some unwanted side-
effects. The zdev_id logic get executed for all the events, even
those completely unrelated to zdev/or site, and imports the unneeded
envionment values to the udev-db.
Instead of having an additional rule file, add this logic as part of
the udev-rule of those devices which are configured with site-support.
The logic will then be available on all those rules with the
site-supported devices only.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Introduce dev_site_configured macro,which can be used to find the
availability of site configurations for the device during udev rule
creation.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Previously SITE_FALLBACK and other site-specific configuration support
macros were defined in device.h. Instead, move them to a relatively
smaller header file which is exclusive for site-related definitions.
This way, light-weight zdev_id also can use the same header file.
Reported-by: Steffen Maier<maier@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Behaviour of the qeth performance_stats sysfs attribute has changed
with kernel commit
b0abc4f5df76 ("s390/qeth: overhaul ethtool statistics")
that went into kernel v5.1.
Before the kernel commit
- collection of statistics was turned on and off by writing 1 or 0
- default after device activation was 0
- statistics were reset by writing 0
After the kernel commit:
- collection is always on
- attribute always reads 1
- statistics is reset by writing 1; writing 0 is a no-op
Problems of chzdev on new kernels:
chzdev cannot reset statistics ('performance_stats=1' does nothing).
'chzdev --export' always lists performance_stats.
'chzdev qeth --help-attribute performance_stats' reflects old behaviour.
This patch will do the following:
'chzdev qeth --help-attribute performance_stats' reflects new behaviour.
'chzdev --export' does not list performance_stats on new kernels.
'chzdev performance_stats=1' resets statistics on new kernels.
'chzdev performance_stats=0' still resets statistics on old kernels,
does nothing on new kernels.
Suggested-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This complements v2.27.0 commit 73c46a3056 ("zdev/dracut: fix kdump by
only activating required devices"). On older distributions, the absence of
zdev_id can cause the following harmless error messages for each udev
event:
(spawn)[387]: failed to execute '/lib/s390-tools/zdev_id' \
'/lib/s390-tools/zdev_id': No such file or directory
Kdump is still functional nonetheless.
As of v2.24.0 commit 2e89722ef0 ("zdev: make site specific udev-rule for
ccw"), the invocations of chzdev within
zdev/dracut/95zdev-kdump/module-setup.sh generate
/etc/udev/rules.d/40-zdev-id.rules. And so even though zdev-kdump
intentionally does not install zdev_id and its previous singular user
zdev/udev/81-dpm.rules into the kdump initrd, because DPM device auto
configuration is not desired in the kdump environment, zdev_id meanwhile
has an additional functionality for site-support and the generated
40-zdev-id.rules calls /lib/s390-tools/zdev_id. By installing zdev_id into
the kdump initrd, 40-zdev-id.rules can work without error.
Fixes: 73c46a3056 ("zdev/dracut: fix kdump by only activating required devices")
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The compiler doesn't fully understand the code block that precedes the
usage of `site` in the condition and thus it thinks it could be
uninitialized. Silence the warning with an explicit initialization.
In function 'get_site_from_pers',
inlined from 'dev_table_get_value' at lszdev.c:1079:10:
lszdev.c:258:20: warning: 'site' may be used uninitialized [-Wmaybe-uninitialized]
258 | if (site == SITE_FALLBACK)
| ^
lszdev.c: In function 'dev_table_get_value':
lszdev.c:234:13: note: 'site' was declared here
234 | int site, i, num = 0;
| ^~~~
Closes: https://github.com/ibm-s390-linux/s390-tools/pull/152
Signed-off-by: Dan Horák <dan@danny.cz>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Using option --by-interface with a non-existent network interface name
results in an unexpected duplicate warning message:
$ lszdev --by-interface xx
Could not open directory /sys/class/net/xx: No such file or directory
Could not open directory /sys/class/net/xx: No such file or directory
lszdev: Could not determine device that provides xx (xx)
Fix this by checking for the existence of the associated /sys/class/net
directory before initiating the associated directory traversal.
Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
zdev's --by-node option returns exit code 15 (EXIT_RUNTIME_ERROR) when
the specified device node cannot be found. This is inconsistent with
other selection options --by-path and --by-interface which both return
the more appropriate exit code 3 (EXIT_DEVICE_NOT_FOUND).
Fix this by changing --by-node to also return exit code 3 in case the
specified device node does not exist.
Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The udev-rules generated with the current version of chzdev command
is missing the configuration label, incase of auto configuration,
resulting in an ineffective configuration logic.
Add the missing configuration start label for autoconfig.
Fixes: 2e89722ef0 ("zdev: make site specific udev-rule for ccw")
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
During the boot, the ZDEV_SITE_ID is derived with the help
of loadparm and will be saved in ZDEV_SITE_ID_FILE, which
will be the used by the udev-rules.
ZDEV_SITE_ID_FILE creation can have a surface of symlink attack
as we are directly using the fopen and fprintf on it. To avoid
this, make sure that we are writing the ZDEV_SITE_ID to a temporary
file, which will then be renamed to ZDEV_SITE_ID_FILE, which will
remove all the existing symlinks associated with the target file.
Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
udev does not allow an empty value for keys when importing output
from an external program. Providing an empty value for any key
invokes a warning during the parsing. Currently, ZDEV_SITE_ID for
fallback sites are not assigned any value. Add an empty double
quotes as the value in case of failover sites.
This modification is tested on udevadm version 253 on fedora38.
Also verify that the ZDEV_SITE_ID is properly written, if not log
the error.
Fixes: c8ad5f57d0 ("zdev: modify zdev_id to read the site_id from loadparm")
Reported-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Autoquiesce is a mechanism that tells Linux to stop issuing I/Os to a
specific DASD after certain events.
Add support for configuring related DASD device attributes
that govern the following aspects of autoquiesce:
aq_mask - Configure which events lead to autoquiesce.
aq_requeue - Configure if autoquiesce will requeue all I/O to blocklayer.
aq_timeouts - Configure the number of timeouts before autoquiesce.
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
With the introduction of zdev for device configuration in v1.33.0,
it used a hardcoded "/" to refer to the root-fs.
Dracut has its own mechanism to find the root file system and to walk its
device dependencies.
Mkdumprd also has its own mechanism to interpret the kdump target
and invokes dracut so that dracut only considers arguments from mkdumprd
without any root-fs dracut would default to [--no-hostonly-default-device].
Use the dracut mechanism to walk device dependencies and individually
have chzdev treat each leaf-node in the dependency tree.
See also https://github.com/dracutdevs/dracut commit
83e0dc7a3dca ("Add for_each_host_dev_and_slaves for device only checking").
This enables the use of dracut options such as --add-device or
--mount used in turn by mkdumprd.
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This avoids exporting explicit settings if it's the default anyway.
I.e. avoid the last line in the example below:
$ chzdev --export - --active --type --all
[active zfcp-lun 0.0.1941:0x500507630904d...:0x4055408f00000000]
scsi_dev/queue_depth=32
Suggested-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Fix issue in the lszdev command where column names if using the --pairs
command line switch can contain characters that are not allowed to be
used as variable names in a shell environment.
Replace bad characters in column names by an underscore if the --shell
command line switch is specified along with the --pairs switch.
The additional --shell switch mimics what is already available in the
lsblk command and thus it shall be used along with the --pairs switch.
Signed-off-by: Daniel S. Haischt <modean@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The DASD device driver has a new attribute copy_pair to make storage
server copy pairs known to the driver.
Add this attribute to zdev.
Usage example:
Add two copy pairs 1000,2000 and 1000,3000 to a DASD device 1000
$ chzdev dasd 1000 copy_pairs=1000,2000 copy_pairs=1000,3000
or
$ chzdev dasd 1000 copy_pairs="1000,2000 1000,3000"
To add a third copy pair later on:
$ chzdev dasd 1000 copy_pairs=1000,4000
To remove all copy pairs from the device 1000:
$ chzdev dasd 1000 -r copy_pairs
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Export and import the configurations with zdev:early on the
site-specific configurations as well. Filter the site-specific
configurations by attribute "zdev:early" and import the output
to the corresponding sites.
Note that --site parameter does not work with the device type.
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add export and import support for site-specific settings. For each
site-specific configuration, a new site-block will be generated as
below. The same format can be interpreted by the import function and use
the values on the device's site-specific configuration.
Typical example of a site-block in the export file:
[site3 dasd-fba 0.0.f001]
online=1
cmb_enable=0
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Introduce --deconfigure-all feature, which will remove all available
settings from the mentioned device. A typical device can have 10
different site-specific settings, active settings, persistent
settings and sometimes auto-configured settings configured in it.
--deconfigure-all can be used to remove all of them with a single
command.
usage: chzdev -D <device-id>
chzdev --deconfigure-all <device-id>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
lszdev must be modified to share the site-specific configuration
information from the persistent settings. The persistent configuration
array will be read and tabularized based on the site-id input from the
user.
This patch also accommodates the site specific information in the
lszdev --info command. New information about the site-ids are integrated
with the command. For example,
DEVICE dasd-eckd 0.0.f001
Names : -
Modules : dasd_eckd_mod dasd_mod
Online : no
Exists : yes
Persistent : yes
Sites : 1,2
ATTRIBUTE ACTIVE PERSISTENT SITE1 SITE2
cmb_enable "0" "0" "1" -
eer_enabled "0" - - -
erplog "0" - - -
failfast "0" - - -
last_known_reservation_state "none" - - -
online "0" "1" "1" "1"
raw_track_access "0" - - -
readonly "0" - - -
reservation_policy "ignore" - - -
use_diag "0" - - -
Each available site specific configuration will be shown as column. The
"Sites" parameter in the above output indicates the available site
configurations and the SITE1 and SITE2 colums indicates the detailed
configuration for the respective sites.
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Modify the dev_get_setting_list function to get the site-specific
attributes of the device. The new site_id parameter for this function
must be less than SITE_FALLBACK to read the site-specific attributes.
As SITE_FALLBACK setting is same as persistent setting, we do not need
a separate read function for it.
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The udev-rules must be modified to make it site-specific. The site
specific part of the rule should be executed only on the sites where the
devices belong. Change the generic udev rule to support the site-specific
udev-rule.
During boot, the current site-id is read from the LOADPARM which is
located at /sys/firmware/ipl. The zdev_id command reads this LOADPARM
and prints the SITE_ID based on the value. This SITE_ID is the
current site where the udev-rule is executing. Based on this assumption,
the rule is divided in to multiple blocks where each site block is executed
only for the corresponding sites.
The rule executes based on the value read from the LOADPARM.
1. When the LOADPARM specifies a site-id and if the current device has
an associated configuration settings, it will be used.
2. When the LOADPARM specifies a site, and the current device does not
have any associated configuration set, the udev rule uses the
fallback configuration settings.
3. If the device does not have a fallback-configuration settings or any
site-specific settings, no configurations will be used.
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The currently active site can be found from the loadparm attribute which
is located at /sys/firmware/ipl/loadparm. Read the value of loadparm and
extract the site_id.
The loadparm is an 8 byte alphanumerical IPL parameter. The content of
loadparm can be of different forms to indicate different boot menu
options, which are used by Linux for selecting the respective boot menu
entries. To indicate the site-id, loadparm adds a 'S' character. Where,
the following character after 'S' indicates either the site-id or
indivcation to derive the site-id from SSID.
For example,
If the loadparm value is Sn,'n' is the integer which could be one of the
valid site_ids from 0 to 9; i.e when booted on site-1, loadparm value will
be S1.
If loadparm value is "SS", zdev_id extracts the site_id from the SSID of
the current ipl device. For ccw and zfcp devices, the current ipl device-id
can be found at /sys/firmware/ipl/device.
In any case, if the loadparm contains invalid value, or empty, the
site_id will be default to the common-site.
After the first invocation of the zdev_id from udev-rule, the site-id
information is stored in /run/zdev_id.env file. This will reduce the
number of further invocation of zdev_id from within udev-rules.
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Currently zdev supports the configuration and maintenance of one single
persistent device state. With the introduction of sites, zdev should be
able to store, configure and maintaine NUM_SITES number of states in
the persistent configuration. This patch modifies the struct device and
adds a new site_specific device_state array, which stores the
persistent configuration for all the available sites.
Total number of available sites are configured with NUM_SITES. Where,
10 site-specific configurations and 1 common configuration.
1. during read, all site data is always read and update the
site_specific[] array.
2. dev->persistent is a copy of dev->site_specific[global_site_id]
3. modifications are only done on dev->persistent, and during write
dev->persistent overlays dev->site_specific[global_site_id]
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
In some high-availability setups, root and boot disks of a Linux
installation are copied to remote sites that can take over execution
of a Linux workload in case of an outage of the original site.
A site in this context is an execution environment such as an LPAR
or z/VM guest.
Each site may provide a different set of devices, or require different
parameters to be applied per device. chzdev supports site-specific
device configuration for up to 10 sites. Each site is identified by
a number in the range 0 to 9. You can provide a separate set of persistent
device configuration for each site. The IPL Load parameter value specified
during boot determines the currently active site. Only the device
configuration of the active site is applied during boot and when new
devices become available. A common configuration can be provided that is
applied when no site-specific configuration is available for a device in
the active site.
User can use the --site parameter to configure devices for a specific
site only. Configuration actions without a site parameter apply to the
common configuration.
During the boot, the active site configuration is chosed based on the
IPL LOADPARM variable. If the LOADPARM contains no valid site-id (0 to 9),
the fallback-site id will be used. The fallback-site-id can also be
configured with the zdev tools by not specifying the --site parameter.
Some of the new chzdev/lszdev commands with site-parameter can be as
follows
1. chzdev -ep f001 --site 3
This command is used to configure the device f001 for the site 3. During
boot, if the LOADPARM value is S3, this device configuration will be
used.
2. lszdev --site 3
This command lists all the devices which are configured for site 3.
3. chzdev -ep f001
Above command does not have a --site parameter. This device settings
will be used for the following conditions
1. When the loadparm specifies a site, (e.g S3), and the device does not
have an associated config-set, zdev uses fallback config set.
2. When the loadparm does not specify any site information, then the
fallback config set will be used.
When the loadparm specifies a site, and the device does not have an
associated config set, nor a fallback site, nothing is configured for this
device.
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The dracut installation directory is referenced from `chreipl-fcp-mpath`,
`zdev`, and `zipl`; in each with its own individual definition and
variable name. This makes it unnecessarily hard to change it when
installing from the top level directory of s390-tools and passing
variable overwrites via the command line.
Fix this by defining a common `DRACUTDIR` variable in the shared
`common.mak` file, and referencing this in each tool as base directory.
With this a user can simply pass `DRACUTDIR=/foo/bar/baz` on the
commandline and change the installation for all three tools.
Further, also derive common `DRACUTCONFDIR` and `DRACUTMODDIR` variables
from `DRACUTDIR` in `common.mak`, so that `zdev` and `zipl` don't use
different variable names for the same directory anymore, and all these
are defined together in a common place.
Semantically nothing changes for a default build/installation.
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
UDEVDIR is used in both `chreipl-fcp-mpath` and `zdev`, but with a
different meaning. In the former it points to the base udev directory,
not the rules directory; in the later it points to the rules directory.
If someone was to call `make` from the top level directory, and set
UDEVDIR for the whole build/installation, it would either break `zdev`
or `chreipl-fcp-mpath` (depending on what it was set to).
Fix this by pulling the definition of it in the shared `common.mak`
file, and giving it a common meaning. Point UDEVDIR to the base udev
directory, and UDEVRULESDIR to the rules directory below it.
Semantically nothing changes for a default build/installation.
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The static analysis tool for Debian packages 'lintian', especially if called
like 'lintian -EvIL +pedantic', checks manual pages for correctness and typos.
This commit fixes typos that were identified by lintian and marked with
'typo-in-manual-page' while s390-tools version 2.20.0 was packaged.
Closes: https://github.com/ibm-s390-linux/s390-tools/pull/134
Signed-off-by: Frank Heimes <frank.heimes@canonical.com>
Acked-by: Steffen Maier maier@linux.ibm.com [ziomon]
Acked-by: Ingo Franzki ifranzki@linux.ibm.com [zkey]
[hoeppner@linux.ibm.com: fix commit message]
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
