Add option --no-apqn-check to the generate, import, change, and
validate commands to disable checking of the specified APQNs.
With this option a currently non-existing APQN can be associated
with a key. This is useful to associate APQNs that exist only on
other systems, such as disaster recovery systems, but not on the
current system. When generating keys, at least one of the specified
APQNs must be available to generate the key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Function get_payload_records() reading from disk, blindly adds payload
record (junks) to a list in a 2-stage hierarchical hash keyed with
request ID and PAY area.
On adapter offline/online, zfcp resets the request ID to re-start with 1.
Hence it's not a unique foreign key in the lifetime of the PAY area.
The last payload record (junks) read for the same request ID and PAY area
is the one printed as named PAY field in the tool output.
This is not necessarily the chronologically last record due to PAY area
wrapping.
With this workaround, we:
* warn on reading PAY records if ambiguous entries occurred,
* print additional PAY timestamps which the user can compare
with the actual trace record timestamps to determine if they are close
enough to indicate a match.
We only found this by accident because we kept "short" "payload" being a
built-in part of some actual trace record types in areas HBA, SAN, SCSI.
For above cases, the full PAYload did not match the
built-in "short" "payload".
While at it, also add a comment that PAY output can also be wrong
in another case when junks of multi-part PAY records are missing due
to PAY area wrapping.
Below is an abbreviated example output with this workaround:
Loading trace records ...(this might take a while)
Warning: Ambiguous PAYload records. reqid:0000000000000037 area:san_res
...
Timestamp : 2017-07-07-18:01:34:574827
Area : SAN
...
Tag : fssct_1
Request ID : 0x0000000000000037
Destination ID : 0x00fffffc
SAN req short : 01000000 fc020000 01720ffc 00000000
00000008
SAN req length : 20
Timestamp : 2017-07-07-18:01:34:619310 ------------------+
Area : SAN |
... |
Tag : fsscth2 |
Request ID : 0x0000000000000037 |
Destination ID : 0x00fffffc |
SAN resp short : 01000000 fc020000 80020000 00000000 |
00671a07 00000000 c05076ff d6801850 |
00671a7e 00000000 c05076ff d6801968 |
SAN resp length: 16384 |
Payload time : 2017-07-07-18:16:17:165708 <== does not match
San resp info : 01000000 fc020000 80020000 00000000 <== wrong
4a49424d 20202020 20323936 34202020 <== wrong
20202020 20202020 20303230 30303030 <== wrong
30303745 43383720 20504348 49443a20 <== wrong
30313938 204e5049 5620556c 7049643a <== wrong
20303536 30303330 30202020 00000000 <== wrong
00000000 00000000 00000000 00000000 <== wrong
... <== wrong
...
Timestamp : 2017-07-07-18:16:17:165713
Area : SAN
...
Tag : fsscth2
Request ID : 0x0000000000000037 <== same reqid & pay "area"
Destination ID : 0x00fffffc
SAN resp short : 01000000 fc020000 80020000 00000000
4a49424d 20202020 20323936 34202020
20202020 20202020 20303230 30303030
SAN resp length: 273
Payload time : 2017-07-07-18:16:17:165708 <== 2nd & last, match
close to Timestamp
San resp info : 01000000 fc020000 80020000 00000000
4a49424d 20202020 20323936 34202020
20202020 20202020 20303230 30303030
30303745 43383720 20504348 49443a20
30313938 204e5049 5620556c 7049643a
20303536 30303330 30202020 00000000
00000000 00000000 00000000 00000000
...
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Reading DASD specific sysfs attributes should be collected in one
library. Move get_host_access_count() to libdasd/dasd_sys.
Remove the old implementation and update any user accordingly.
Also, fix the build order for zdsfs.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Use the newer and more robust libutil provided function
util_sys_get_dev_addr() to identify a device address for any former user
of u2s_getbusid().
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Many tools need to identify the device address of a given device. So
far, either the tool had its own implementation, or u2s_getbusid() was
used. Though, u2s_getbusid() was mainly designed for and used by the
DASD tools.
Introduce util_sys with a first function util_sys_get_dev_addr() which
provides a more universal way to identify the device address which is
not limited to one particular device type. The device address represents
either a busid (e.g. DASD), slot address (NVMe), H:C:T:L tuple (SCSI),
or other id types associated with a device.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
dasdview and libdasd deal with DASD bus ids and should use a definition
for the size. libu2s already provides a definition, which is used by
dasdview. However, the size of 32 is a bit much and the definition
should be part of libdasd.
Including the terminating null byte ('\0') and considering a DASD bus id
length of 8 characters (e.g. 0.0.4711), this leads to a size of 9.
Provide such a definition via libdasd and update any user.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Don't rely on rather arbitrary values for the string buffer size of
different sysfs paths. Instead use util_path_sysfs(), which allocates
the exact amount of memory necessary for a certain path string.
As these path strings are dynamically constructed, potential buffer
overflows can hereby be avoided and make the library functions more
robust.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add zipl and zipl.conf man page updates.
The zipl man page will look like:
-S <SWITCH> or --secure <SWITCH>
Control the zIPL secure boot support. <SWITCH> can take one of three values:
auto (default)
Write signatures if available and supported by the system.
1
Signatures are written independent of support indicated by the local
system. Also missing signatures for stage 3 and kernel IPL files
will result in an error.
0
No signatures will be written.
The zipl.conf man page will look like:
secure = auto/1/0 (configuration only)
Configuration section:
Control the zIPL secure boot support. Set this option to one of the following:
- auto: Write signatures if available and supported by the system.
- 1: Signatures are written independent of support indicated by the local system.
Also missing signatures for stage 3 and kernel IPL files will result in an error.
- 0: No signatures will be written.
The default value for 'secure' is auto.
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
To ensure that only verified code is executed the stage 3 loader has
to check if the load psw points to an address that has previously been
verified by the machine loader.
If secure boot is enabled the IPL process will only continue if the
verification was successful.
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The firmware needs to know which memory locations are used by
the stage 3 loader so that it can allocate its own memory.
To indicate the usage of the heap and stack area of the stage 3 loader
add a dummy component to block this memory area for the firmware.
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The stage 3 loader size has to be a multiple of the filesystem
blocksize so that the signature maps with the later in memory
stage 3 loader. The lowest common blocksize is 4k so the image
is padded to a 4k boundary.
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add a command line option and configuration section keyword to control
the zIPL secure boot support. This option is named "secure" and can take
one of three values:
auto (default)
Write signatures if available and supported by the system.
1
Signatures are written independent of support indicated by the local
system. Also missing signatures for stage 3 and kernel IPL files
will result in an error.
0
No signatures will be written.
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>
Add support for parsing IPL file signatures as produced by the Linux
kernel's sign-file tool. When preparing a disk for IPL, the signatures
will be added as separate data components that can be used by the Secure
Boot firmware feature to validate the integrity of the IPL files.
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>
Change the fixed component entry text array to a more dynamic approach
to allow easier extension and make the order changeable.
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>
The first component that gets control after IPL is the zIPL-provided
stage 3 boot loader. This boot loader is based on a binary image linked
into the zIPL executable. When preparing a disk for IPL, zIPL updates
runtime parameters in the boot loader image and writes the resulting
data to disk.
To support the Secure Boot firmware feature, the stage 3 code must be
signed, and can therefore no longer contain variable parameter portions.
Also the boot loader image should be accessible as a separate file to
enable the use of external programs for creating the signature.
This patch moves the stage 3 boot loader code to an external file
location and splits out the parameter portion into a separate, unsigned
on-disk component.
The new memory layout of the stage 3 loader during its execution looks
as follows:
* 0x0000-0x1fff Lowcore
* 0x2000-0x5fff Memory allocation (heap)
* 0x7000-0x8fff free
* 0x9000-0x9fff Stage3 parameter
* 0xa000-0xcfff Stage3 code
* 0xd000-0xefff Section: bss, rodata, data
* 0xf000-0xffff Stack
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>
The binary Linux kernel image is built to be loaded to memory address
0x0 but the first 64 kbyte contain an IPL header that is not used for
disk IPL. zIPL strips away this IPL header when writing IPL records to
disk, loads the remaining data to memory address 0x10000 and uses the
memory area below that for its own boot loader code.
The Secure Boot firmware feature checks the integrity of an installed
image during IPL using a checksum that was generated for the full image.
Since the checksum becomes invalid if the IPL header is removed, zIPL
must be changed to write the full image to disk.
This patch modifies the zIPL logic to no longer strip away the IPL
header. Instead the full image is loaded to a higher memory address and
relocated by the stage 3 boot loader code to its final location.
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>
When a 'zkey change' command is used to change (i.e. set) the volume
association of a key, and the new volume association contains a volume
that is already assigned to the key to be changed, the command fails
with an error that the volume is already associated to the key.
This commit fixes the problems and allows to set such a volume
association. When setting a new association the current association of
the key to be changed is of no relevance, since the set operation
replaces the current association with the new association.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
s390-tools-1.9.0 introduced a new way of recognizing of multipath
device paths with using of sed command invocation in ziomon script.
With this new way of recognizing, if there are paths, related to
multipath device, with SCSI host ID longer, than one digit,
ziomon incorrectly parses the multipath -l command output. It
erroneously cuts off all but the least significant digit of the
SCSI host ID (H) of paths in H:B:T:L format (Host:Bus:Target:Lun).
This leads to passing of hosts (-a) and paths (-l) with
non-existing SCSI host ID to ziomon_util. In turn ziomon_util
cannot recognize hosts with non-existing SCSI host ID and issues
an error.
Also, wrong sed command invocation could lead to receiving of
duplicate LUNs by ziomon after parsing of multipath -l command
output. Then ziomon excludes duplicates from WRP_LUNS, which
leads to mismatch between number of LUNs and number of detected
block devices and issues ziomon script error, without starting
ziomon_util and without writing to specified log file.
The regular expression to match a path in H:B:T:L format started
with a greedy ".*", which erroneously consumed parts of the SCSI
host ID (H). This patch replaces the greedy ".*" by "[^0-9]*",
so that sed command does not consume parts of the SCSI host ID
any more.
Test example with unique SCSI host IDs:
$ multipath -l
...
mpathc (36005076307ffc5e300000000000083f5) dm-2 IBM ,2107900
size=20G features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=0 status=active
|- 10:0:0:1089814659 sdb 8:16 active undef running
`- 11:0:0:1089814659 sdf 8:80 active undef running
...
Behavior without fix applied:
$ ziomon -d 5 -o log /dev/mapper/mpathc
Check devices...done
NOTE: No size limit specified, run without a limit.
Estimated maximum disk space required for log data: approx. <1 MBytes
Collecting configuration data...done
Start data collection processes...ziomon_util: Path does not exist: /sys/class/scsi_host/host0/utilization - correct kernel version?
ziomon_util: Path does not exist: /sys/class/scsi_host/host0/utilization - correct kernel version?
ziomon_util: Path does not exist: /sys/class/scsi_host/host0/queue_full - correct kernel version?
ziomon_util: Path does not exist: /sys/class/scsi_host/host1/utilization - correct kernel version?
ziomon_util: Path does not exist: /sys/class/scsi_host/host1/queue_full - correct kernel version?
failed
ziomon: Failed to determine ziomon_util pid
Shutting down
Shutting down blktrace process
Shutting down blkiomon process
Shutting down ziomon_zfcpdd process
blkiomon: terminated by signal
Shutting down data manager
User can see more information, when using ziomon with -V option:
...
=== WRP_LUNS : 0:0:0:1089814659 1:0:0:1089814659
=== WRP_HOST_ADAPTERS: host0 host1
...
=== starting ziomon_util: ziomon_util -V -a 0 -a 1 -l 0:0:0:1089814659 -l 1:0:0:1089814659 ...
...
User can also see this type of errors, while using
ziorep_traffic or ziorep_utilization tools:
$ ziorep_traffic -t1 log.log
Extracting config data...done
ziorep_traffic: Could not retrieve initial data - data files corrupted or broken, or the .agg file is missing.
Behavior with fix applied:
$ ziomon -d 5 -o log /dev/mapper/mpathc
Check devices...done
NOTE: No size limit specified, run without a limit.
Estimated maximum disk space required for log data: approx. <1 MBytes
Collecting configuration data...done
Start data collection processes...done
Collecting data...done
Shutting down
Shutting down data manager
User can see more information, when using ziomon with -V option:
...
=== WRP_LUNS : 10:0:0:1089814659 11:0:0:1089814659
=== WRP_HOST_ADAPTERS: host10 host11
...
=== starting ziomon_util: ziomon_util -V -a 10 -a 11 -l 10:0:0:1089814659 -l 11:0:0:1089814659 ...
...
Test example with duplicate SCSI host IDs:
$ multipath -l
...
mpathc (36005076307ffc5e300000000000083f5) dm-1 IBM ,2107900
size=20G features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=0 status=active
|- 0:0:0:1089814659 sdb 8:16 active undef running
`- 10:0:0:1089814659 sdf 8:80 active undef running
...
Behavior without fix applied:
$ ziomon -d 5 -o log /dev/mapper/mpathc
Check devices...done
ziomon: Number of LUNs does not match number of devices: 2 devices and 1 LUNs
User can see more information, when using ziomon with -V option:
...
=== #Devices total : 2
=== WRP_DEVICES : /dev/sdb /dev/sdf
=== WRP_LUNS : 0:0:0:1089814659
=== WRP_HOST_ADAPTERS: host0
...
Behavior with fix applied:
$ ziomon -d 5 -o log /dev/mapper/mpathc
Check devices...done
NOTE: No size limit specified, run without a limit.
Estimated maximum disk space required for log data: approx. <1 MBytes
Collecting configuration data...done
Start data collection processes...done
Collecting data...done
Shutting down
Shutting down data manager
User can see more information, when using ziomon with -V option:
...
=== #Devices total : 2
=== WRP_DEVICES : /dev/sdb /dev/sdf
=== WRP_LUNS : 0:0:0:1089814659 10:0:0:1089814659
=== WRP_HOST_ADAPTERS: host0 host10
...
=== starting ziomon_util: ziomon_util -V -a 0 -a 10 -l 0:0:0:1089814659 -l 10:0:0:1089814659 ...
...
Signed-off-by: Fedor Loshakov <loshakov@linux.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
In case a regular directory was specified, rather than a device node,
the check if the device exists will pass. The following code paths then
assume a slot id was specified. This in turn may lead to a buffer
overflow when the device data is copied to to the zpci_device struct.
Check if the specified path is a regular directory and prevent a
possible later buffer overflow and copying wrong data respectively.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Also mark FCP devices with CHPID that is logically varied off,
e.g. after running "chchp -v 0 60".
Such FCP devices can be online, not failed, and are not defunct,
so the other existing markers do not appear.
Shows potential issues with FCP devices at one glance.
Examples:
$ lszfcp -He
0.0.1900 host0 NotAvailable
$ lszfcp -HeV
/sys/devices/css0/0.0.010d/0.0.1900 NotAvailable
/sys/class/fc_host/host0
/sys/class/scsi_host/host0
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Complements: 4036e80b26 ("lszfcp: add new output marker for non-good FCP devices (hosts)")
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The zcryptstats tool displays usage statistics of IBM Crypto Express
adapters. It obtains cryptographic performance measurement data
periodically and displays the data for each cryptographic device for
each interval. A cryptographic device can be either a card device or
a queue device (APQN).
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
I often use "systool -v -m zfcp" but that's a bit longish to type
and contains more output than just the parameters I'm interested in.
"tail /sys/module/zfcp/parameters/*" is also not so nice.
"lszfcp -Z" makes it very easy and can be combined with the other
existing output options of lszfcp.
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Since zfcp lazily allocates Scsi_Host et al. on setting an FCP device
online for the first time since the last driver core bind to zfcp
(such as zfcp kernel module load),
lszfcp has only been showing FCP devices (vHBAs) that have been online
at least once including those that have been set offline again.
This is somewhat confusing.
Also it would be nice if lszfcp could be an easier to type replacement for
"lscss -t 17032/03" to simply show all devices bound to the zfcp device
driver.
Of course those FCP devices that have never been online, won't have any
zfcp-specific attribute details, only CIO attributes from the CCW bus.
They also do not have a Scsi_Host nor fc_host.
In order not to break any scripting or expectations around lszfcp,
make the new feature depend on the extended output command line option.
Example:
$ lszfcp -He
0.0.1880 - offline
$ lszfcp -HeV
/sys/devices/css0/0.0.010b/0.0.1880 offline
-
-
$ lszfcp -Hea
0.0.1880 - offline
Bus = "ccw"
availability = "good"
cmb_enable = "0"
cutype = "1731/03"
devtype = "1732/03"
modalias = "ccw:t1731m03dt1732dm03"
online = "0"
uevent = "DRIVER=zfcp"
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
s390-tools-1.8.1 introduced a new error message.
It gave the same and thus misleading error message as if no FCP device
(vHBA) found.
In order not to break any scripting built around lszfcp output,
only print the fixed error message depending on the extended output
command line option.
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
s390-tools-1.8.0 introduced a regression skipping all FCP devices
that are currently "defunct".
Changing
$SYSFS/devices/css0/*/*/host*
to
$SYSFS/devices/css0/[0-9]*/[0-9]*/host*
was too strict as it won't match
$SYSFS/devices/css0/defunct/[0-9]*/host*
anymore.
Fix:
$SYSFS/devices/css0/[0-9d]*/[0-9]*/host*
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
s390-tools-1.8.1 introduced a regression skipping all fc_rports
with port_state != Online. While we need to skip some output parts
for a zfcp_port which does not exist anymore due to port_remove,
there are other cases with port_state != Online for which we should
not skip an fc_rport.
Such as port_state "Blocked" after a cable pull beyond host-adjacent switch
or port_state "Not Present" after dev_loss_tmo ran out.
This way the user can see the previously discovered ports,
even if they might currently not be usable for traffic.
Non-good ports are marked in the short output with suffix "NotOnline".
In order not to break scripting or expectations around lszfcp, make the new
feature depend on the extended output command line option.
Sysfs path globbing does not work for a removed zfcp_port
to obtain the FCP device bus-ID. Instead, properly walk the sysfs.
Examples with a removed zfcp_port:
$ lszfcp -Pe
0.0.50c0/0x500507680b2481fa rport-6:0-2
$ lszfcp -PeV
- (NoMoreZfcpPort:0.0.50c0/0x500507680b2481fa)
/sys/class/fc_remote_ports/rport-6:0-2
Examples with an existing zfcp_port but pulled fibre:
$ lszfcp -Pe
0.0.3c40/0x500507680b2181fb rport-7:0-4
$ lszfcp -PeV
/sys/devices/css0/defunct/0.0.3c40/0x500507680b2181fb
/sys/class/fc_remote_ports/rport-7:0-4
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Used in subsequent patches to guard their changes in order not to break
any scripting or expectations around the lszfcp output format.
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When re-enciphering or setting LUKS2 volume keys using zkey-cryptsetup,
allow to specify the --batch-mode|-q option to suppress confirmation
questions.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
For LUKS2 volumes the cryptsetup command currently generates
'cryptsetup luksFormat' commands, but for plain mode volumes it
generates 'cryptsetup plainOpen' commands.
With the --open option it can now also generate 'cryptsetup luksOpen'
commands for opening LUKS2 volumes. With the --format option you can
limit the generated commands to only generate 'cryptsetup luksFormat'
commands for LUKS2 volumes, and skip plain mode volumes.
The default behavior (i.e. if none of the two options specified),
remains the same as before.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When generating crypttab entries for LUKS2 volumes, allow to
specify common passphrase options like --key-file, --keyfile-offset,
--keyfile-size and --tries and pass those to the generated crypttab
entries.
Note that not all distributions support the keyfile-offset and
keyfile-size options in crypttab entries.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
