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>
chzdev fails to generate correct cio_ignore udev-rules for a CCW device
with device number 0xffff. Also chzdev aborts due to a segmentation
fault when a CCW device with CSSID 0xff is configured. Both issues are
caused by off-by-one errors while interpreting CCW device ID limits
CSSID_MAX, SSID_MAX and DEVNO_MAX.
Fix these errors by correctly interpreting CCW device ID limits.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Currently, a device type setting being --removed from both the active and
persistent configuration via 'chzdev -t' can result in a scenario where
the setting is not removed from the active configuration (and an error
message is presented) but chzdev still proceeds to remove the setting from
the persistent configuration.
Update this logic so that devtype_remove_settings behaves the same way as
device_remove_settings and only perform the removal when no errors are
encountered.
Reported-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
zdev provides path resolution logic to determine which z-specific
devices contribute to the file system mounted at a specific mount point.
This logic is used by command-line option --by-path, but also to
determine the list of devices needed to enable the root file system.
Path resolution fails when a device provides multiple mount points such
as, for example, when using btrfs subvolumes, or when mounting the same
file system at multiple mount points. The failure is caused by zdev
relying on the MOUNTPOINT attribute of lsblk's output which only
contains a single mount point.
Fix this by making use of lsblk's MOUNTPOINTS attribute that contains
the full list of mount points. Note that MOUNTPOINTS was only introduced
with util-linux v2.37, therefore a fall-back to the old format is
needed.
Fixes: https://github.com/ibm-s390-linux/s390-tools/issues/129
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Eduard Shishkin <edward6@linux.ibm.com>
Reported-by: Dan Horák <dan@danny.cz>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Since version 2.37.x, with the commit 58b510e58 ("libsmartcols: sanitize
variable names on export output"), util-linux changes the output
characters of lsblk, where the ":" is replaced with an "_". Align the
lsblk output parser function in lszdev as per this change.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Suggested-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reported-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Tested-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
PCI and crypto devices defined using the IBM Z Dynamic Partition Manager
(DPM) will start in an offline/unconfigured state that requires manual
intervention before the associated Linux function can be used. This
results for example in PCI networking interfaces being unavailable in a
distribution installer system.
Fix this by providing a udev rule and initial RAM-disk logic that
automatically enables PCI and crypto devices either during boot, or when
they are defined at run-time. This processing can be suppressed by
specifying the "rd.zdev=no-auto" parameter on the kernel command line.
Auto-configuration is limited to Linux running in DPM LPARs because
PCI-functions and crypto devices defined by DPM are always intended for
use by a single LPAR only.
For Linux running in classic-mode LPARs or virtual machines, leaving PCI
and crypto devices in an offline state may be useful to allow defining a
device as available to multiple systems, where only the system that
intends to make use of the device should enable it.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add an internal tool intended to be used by udev rules to determine
zdev and hypervisor related system information in key=value format.
Supported keys are:
ZDEV_NEST_LEVEL=n
Virtualization nesting level of running system
ZDEV_HYPERVISOR_<n>=LPAR|z/VM|KVM/Linux
Type of hypervisor that provides virtualization at nesting level <n>
ZDEV_IS_DPM=0|1
Indicator if top-level LPAR is managed by Dynamic Partition Manager
ZDEV_NO_AUTO=0|1
Indicator if auto-configuration is requested
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Some Linux distributions always include a copy of all persistent device
configuration data when updating the initial RAM-disk. This makes
chzdev's persistent device configuration changes ineffective because
device configuration directives applied in the RAM-disk take precedence
over those stored in the root filesystem.
This patch introduces a new build-time switch which allows distributions
to specify that whenever there is a persistent device configuration
change, the RAM-disk is updated automatically.
This feature can be enabled by adding 'ZDEV_ALWAYS_UPDATE_INITRD=1' as
a zdev build option. Where, by default ZDEV_ALWAYS_UPDATE_INITRD is 0.
Co-developed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@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>
Provide information for the DASD device attribute 'fc_security'.
The help output for this attribute can be queried like this:
chzdev dasd --help-attribute
The lszdev tool can be used to display the current state of the FC
Endpoint Security information:
lszdev dasd -a -c TYPE,ID,ATTR:fc_security,ATTRPATH:fc_security
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This attribute is a no-op and never provided the described functionality.
It will be removed in the 5.7 kernel release with
commit 5f4019a80839 ("s390/qeth: remove fake_broadcast attribute").
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add support to report Fibre Channel (FC) Endpoint Security
related information for zfcp-host and zfcp-lun devices.
Allow to query (lszdev) and provide help for (chzdev) the FC Endpoint
Security capability of a FCP device (zfcp-host). Provide this
information by defining the FCP device attribute fc_security in zdev
zfcp-host.
Allow to query (lszdev) and provide help for (chzdev) the FC Endpoint
Security in use on a connection between a FCP device and a FC remote
port. Provide this information by introducing a virtual zdev zfcp-lun
attribute fc_security. It returns the fc_security attribute value of
the zfcp port object representing the FC remote port used to access the
LUN.
This approach allows users of lszdev to easily query the FC Endpoint
Security in use on the connections to one or more FCP LUNs. It also
does not require the effort to introduce a zfcp-port device type in
zdev.
The fc_security attribute help for both zfcp-host and zfcp-lun can be
queried for example as follows:
chzdev zfcp --help-attribute
The fc_security attribute values and path of all active zfcp devices
can be queried for example as follows:
lszdev zfcp -a -c TYPE,ID,ATTR:fc_security,ATTRPATH:fc_security
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
As preparation for a following commit reorder the path logic in function
zfcp_lun_st_get_active_attrib_path(). This then allows to handle
subsequent special cases more easily. Additionally it also enhances the
readability of the expression.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add support for defining read-only attributes in the chzdev/lszdev
tools. These attributes can be used to provide online documentation
for specific attributes via the --help-attribute and --list-attributes
tool functions.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Consolidate `ALIGN, __ALIGN_MASK, ARRAY_SIZE` macros and add them to
lib/zt_common.h. While at it, adapt coding style.
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
zdev incorrectly reports an invalid udev rule for zfcp-lun type rules.
This is caused by a faulty check for an empty udev rule file. This
commit fixes the check to only report invalid rules when there was no
valid configuration directive found in a zfcp-lun type udev rule.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reported-by: Steffen Maier <maier@linux.ibm.com>
Reported-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add basic checking when reading udev rules and print a warning when an
invalid udev rule file is found. This addresses the current inconsistent
behavior:
- CCW devices: invalid udev rules are considered valid
- CCW group devices: invalid udev rules are silently ignored
- zFCP LUNs: invalid rules cause chzdev/lszdev to silently terminate
with non-zero exit code
Checks include a test for empty or truncated rule files that might be
the result of an interrupted chzdev operation, or a file system or I/O
error.
Note: The recommended way to correct invalid udev rules is to either
remove the offending rules file, or to repeat the associated persistent
configuration step.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reported-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The zfcp kernel module was changed to introduce separate parameters for
selecting DIF and DIF&DIX. This commit implements the corresponding
changes in chzdev and lszdev.
Signed-off-by: Fedor Loshakov <loshakov@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The header exit_code.h is required for the exit_code_t type and
the header misc.h for the err_t type.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The function util_path_exists() consumes its first parameter as format
string. Passing the user input specified to the chzdev option --export
as-is to the function opens up the possibility for a format string
injection.
Fixes: d542138868 ("zdev: use libutil provided path functions")
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Since commit d542138868 ("zdev: use libutil provided path functions")
lszdev fails to correctly report most read-only sysfs attributes as such
in its detailed information output (options -i or -ii). This is because
the libutil function util_path_is_writable() is not equivalent to the
former function file_writable().
util_path_is_writable() always returns true (the underlying function
access() indicates the file is writable), if the path exists and the user
is root, regardless of the path's effective access permissions. This is
correct for most use cases, as root can effectively read/write any path
regardless of its effective access permissions). util_path_is_writable()
behaves exactly like Bash -w in this regard.
The former function file_writable() examined the file's access permissions
to check if one or more of user, group, and other have write permission.
For lszdev it is irrelevant whether a file is effectively writable by
the current user. Instead it needs to determine whether sysfs attributes
access permissions contain write access in any form. If not it lists
those sysfs attributes in a separate read-only section.
Use the new function util_path_is_readonly_file(), which does explicitly
check the file's effective read and write access permissions. It behaves
similar to the former function file_writable(), except that it does test
whether any of user, group, and other have read permission.
Fixes: d542138868 ("zdev: use libutil provided path functions")
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
For some device driver SysFS attributes, values read may not be
acceptable input values for that attribute.
An example would be the group of qeth VNICC attributes that return "n/a"
when VNICC setup is not supported, but only accept "0" and "1" as valid
values that can be written to it.
This leads to errors such as the following when data for such attributes
is imported:
# chzdev f500 --import test.conf
Importing configuration data from test.conf
QETH device 0.0.f500:0.0.f501:0.0.f502 configure failed
Error: Invalid value for qeth attribute: vnicc/flooding=n/a (*)
Acceptable values:
- Integers in the range 0 - 1
Use 'chzdev qeth --help-attribute vnicc/flooding' for more information
Note: You can use --force to override safety checks (*)
To fix this, change chzdev's --export function to skip any attribute
value that is not acceptable for that attribute.
Fixes: e831269e74 ("zdev: Add support for VNIC Characteristics")
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Make sure strings are copied correctly by using util_strlcpy().
Also, rename the NIC_{OWNER,NAME}_LEN definitions to *_SIZE to make it
more clear that the terminating null byte ('\0') is included in this
buffer size. Using *_LEN would mean only the number of characters in the
string fit in.
Furthermore, use these definitions rather than sizeof().
This fixes the following GCC8 compile warning:
nic.c: In function ‘nic_data_get’:
nic.c:58:2: warning: ‘strncpy’ specified bound 9 equals destination size
[-Wstringop-truncation]
strncpy(data.owner, argv[11], sizeof(data.owner));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
nic.c:59:2: warning: ‘strncpy’ specified bound 9 equals destination size
[-Wstringop-truncation]
strncpy(data.name, argv[12], sizeof(data.name));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When realloc() fails to allocate memory it returns NULL and the original
block is left untouched. In that case return the potentially larger
original block.
Found using Cppcheck:
[zdev/src/misc.c:1106]: (error) Memory leak: name
Cc: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The modified flag was actually never copied during merge of setting lists.
Copy the modified flag if requested.
Found using Cppcheck:
[zdev/src/setting.c:553]: (warning) Redundant assignment of 'n->modified' to itself.
Cc: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Unfortunately zdev hook already exists in Ubuntu, from an unrelated
project. ZFS uses zdev/zpool names, and ships a zdev hook to do ZFS
specific initialisation. It is available on s390x and thus results in
file-conflict upon installing both. Thus renaming this zdev hook to
s390-tools-zdev.
Closes: https://github.com/ibm-s390-tools/s390-tools/pull/41
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This patch fixes false positives when attributes are checked for
conflicts between BridgePort and VNICC.
Signed-off-by: Hans Wippel <hwippel@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
mk-pxelinux-ramfs, mod_fsstatd|procd.service, zfcpdump all use
/sbin/modprobe path. Adjust zdev to use that path as well. This works
universally on both usr-merge systems (e.g. Debian/Ubuntu with
usrmerge package installed), and split-usr systems alike
(Debian/Ubuntu current stable releases default).
Closes: #31
Link: https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/1777600
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Changing the cmb_enable attribute of a CCW device can cause a blocked
chzdev process or udev rule. This problem occurs when the device is
offline, cmb_enable is 0, and chzdev is used to set cmb_enable=1 and
online=1 at the same time.
The following call will block:
chzdev 190d -a cmb_enable=1 online=1
The following call will generate a udev rule that will block subsequent
calls to 'udevadm settle':
chzdev 190d -p online=1 cmb_enable=1
Fix this by ensuring that cmb_enable is only set when the CCW device
is not online.
Reported-by: André Wild <wild@linux.vnet.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Enable user to specify that a device should be configured early, that is
during the initial RAM-disk boot phase. This may be necessary, e.g. to
override auto-configuration for a device which is also applied during
that boot phase. It may also be used to manually specify devices that
are required to access the root file system, such as networking devices.
Users can mark devices as requiring early configuration by specifying
a value of 1 for the newly added internal attribute zdev:early:
# chzdev dasd-eckd 0.0.1234 -p zdev:early=1
This can be changed back by removing the attribute setting, or by
setting the attribute value to 0:
# chzdev dasd-eckd 0.0.1234 -p -r zdev:early
or
# chzdev dasd-eckd 0.0.1234 -p zdev:early=0
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This change adds base infrastructure for implementing internal device
attributes. In the context of the zdev tools, an internal device
attribute is a new type of device attribute with the following
characteristics:
- Can be set and removed like normal device attributes
- Affects zdev-internal handling only
- Does not correspond to an actual device attribute, that is
it has no representation in SysFS
- Can not be set in the active configuration
- Name starts with "zdev:" to prevent conflicts with actual
device attributes
Values for internal device attributes are stored in udev rules alongside
the normal persistent configuration of a device. They are encoded as
udev environment variables. Note that they have no further effect on
udev processing.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add initramfs-tools scripts that apply firmware-provided I/O
configuration data as auto-configuration during boot. This way, all I/O
devices configured by DPM are automatically brought online without
further user interaction.
This mechanism is active by default. It can be deactivated by specifying
the following parameter on the kernel command line:
rd.zdev=no-auto
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add a dracut hook that applies firmware-provided I/O configuration data
as auto-configuration during boot. This way, all I/O devices configured
by DPM are automatically brought online without further user
interaction.
This mechanism is active by default. It can be deactivated by specifying
the following parameter on the kernel command line:
rd.zdev=no-auto
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Auto-configuration is the name of a new configuration target that is
supported by chzdev and lszdev besides the existing active and
persistent configuration targets. Directives created in this new
configuration are stored as udev rules in the /run/udev/rules.d
directory.
Auto-configuration directives are only in effect if there are no
directives for the same device in the user-provided persistent
configuration. This allows users to override auto-configuration
directives if necessary.
Due to the volatile nature of the /run directory, auto-configuration
directives are cleared on reboot. Therefore mechanisms that generate
auto-configuration directives must recreate them on every boot.
The lszdev tool displays auto-configuration data both in list view
as well as in detail view. Users can specify the new option --auto-conf
to only show data from this configuration target.
Mechanisms that generate automated configuration directives can use
chzdev together with the --auto-conf option to create the corresponding
udev rules.
Note: This change does not include a mechanism that generates
auto-configuration directives.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Change chzdev's udev rule generation from the previous approach of
combining all zfcp-lun udev rules associated with an FCP device into a
single file to storing zfcp-lun udev rules in one file per zfcp-lun.
This is done to enable per-device udev rule masking.
With udev rule masking, if a udev rule file by the same name exists in
both /etc and /run, the udev daemon will only consider the rules found
in /etc.
The auto-configuration feature will make use of per-device udev rule
masking to introduce a new class of configuration data (stored in /run)
that is only active if no user-provided configuration data (in /etc)
exists.
In addition, change chzdev to allow the regeneration of udev rules by
using the --force command line like in the following example:
# chzdev zfcp-lun --configured --enable --persistent --force
This can be used to convert all existing zfcp-lun udev rules from the
old format to the new one.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
There are some situations where running "udevadm settle" can result in
a deadlock, such as in the early stages of initial RAM-disk processing.
Introduce a new command-line option --no-settle that can be used to
suppress calling "udevadm settle" to allow chzdev to be run in such
situations.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add support for reading firmware-provided I/O configuration data files.
Such configuration files are generated by the Dynamic Partition Manager
and made available via a kernel interface for consumption by Linux.
To read a firmware configuration file, use the existing --import option:
# chzdev --import /sys/firmware/sclp_sd/config/data
This will apply all I/O configuration data found in the specified file
to the persistent configuration.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Apply some changes to existing functions and data structures to simplify
the firmware configuration file support implementation.
- Make qeth and dasd subtype objects non-static
- Change the existing helper functions for reading file contents into
memory to also support binary functions
- Move some configuration file import functions to make them available
for use in other source files
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
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 <oberpar@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
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 <oberpar@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
