When detecting disk type, the function disk_get_info() is called.
It can fail for various reasons (e.g. when the logial target is not
eligible for boot record installation).
Once disk_get_info() fails, don't proceed with type detection.
Return error instead. When applicable, mark the dump job with
"is_ngdump" flag to avoid extra type detection calls.
Acked-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This fixes d6b702d57 which introduces a problem: SCSI dump
installation fails:
zipl -V -d /dev/mapper/mpathd1
Error: Invalid dump device: Could not read partition table
The reasons:
1) Wrong (logical) device is passed as a target base;
2) In case of 'source_script' the check to make sure that specified
target is over a partition isn't applicable any more after zipl
support of complex logical targets (e.g. mirrors).
The fixup passes the physical device as a target base (instead of
the logical one). Also the fixup removes invalid check from
check_dump_device_late() and instead adds a more generic check to
the helper script that data starts beyong the boot area.
Reported-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Tested-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This option is experimental, but can still be useful.
While at it, sort the options alphabetically.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This fixes 670bf3e8 which actually isn't an equivalent refactoring.
The generic dm-device resolution procedure was modified to not resolve
the topmost dm-device in the path. So that any calles who don't expect
it, should complete the resolutioin process by themselves. In case of
chreipl_helper such completion was missed. chreipl(8) utility doesn't
expect dm-devices at the output of chreipl_helper.device-mapper
Example:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 20G 0 disk
|-sda1 8:1 0 20G 0 part
`-mpathb 253:0 0 20G 0 mpath
`-mpathb1 253:2 0 20G 0 part /
sdb 8:16 0 20G 0 disk
|-sdb1 8:17 0 20G 0 part
`-mpathb 253:0 0 20G 0 mpath
`-mpathb1 253:2 0 20G 0 part /
Expected result:
8:16
Actual result:
253:0
As a result, the chreipl(8) "node" option stopped working.
The fixup adds the completion.
Reported-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Tested-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The .note.package [1] section is not used by the zipl/genprotimg bootloaders,
therefore discard them via linker script.
This fix solves the error:
/usr/bin/ld: Heap section doesn't conform to the described memory layout
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:77: stage3a.elf] Error 1
make[4]: Leaving directory '/<>/genprotimg/boot'
make[3]: *** [Makefile:20: all-recursive] Error 1
make[3]: Leaving directory '/<>/genprotimg'
make[2]: *** [Makefile:56: genprotimg] Error 2
[1] https://systemd.io/ELF_PACKAGE_METADATA/
Fixes: https://github.com/ibm-s390-linux/s390-tools/issues/174
Closes: https://github.com/ibm-s390-linux/s390-tools/pull/176
[seiden@linux.ibm.com: Add/edit fixes tags]
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Frank Heimes <frank.heimes@canonical.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Introduce target operations (struct target_ops);
For each supported device-mapper target implement
. check_target_status()
. get_target_data()
Add support for new 'raid' device-mapper target, which is now default
in LVM.
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Add a script to process mirrored zipl targets managed by Linux "md"
driver (AKA "software mirrors")
. In the file zipl_helper.device-mapper.c implement two handlers
identified by pairs (ZIPL_UTIL_ID, MD_DRIVER_ID) and
(CHREIPL_UTIL_ID, MD_DRIVER_ID) for the helpers zipl_helper.md
and chreipl_helper.md respectively
. zipl_helper.md: prints sets of target parameters (one such set
per mirror) for a specified logical zipl target managed by linux
"md" driver.
. chreipl_helper.md: for a specified logical zipl target managed
by linux "md" driver prints a random disk from the set of disks
participating in the mirrored setup.
. Add zipl_helper.md and chreipl_helper.md as symbolic links to
zipl_helper.device-mapper
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
For "mirror" device-mapper targets:
. Check status of all the mirrors;
. Return error if some mirror contain failures;
. Align the sample output properly
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
For "mirror" device-mapper targets:
. Don't assign a logical mirrored device as a zipl target base.
Instead, add one more branch in complete_physical_device() and
proceed (in that new branch) to the physical disk participating
in the mirrored target. This approach allowes to handle
heterogeneous mirrors properly;
. Provide a set of target parameters for each found physical disk
by calling dm_dev_to_zipl_params() recursively;
. Don't allow "nested mirrors" by checking/updating the
fail_on_mirror global;
. Remove the requirements on including block #0 to the mirrored
device-mapper setup (no more actual);
. Update comments.
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
This is used by the next patches in the series to support mirror
setups not including boot sectors (e.g. mirrors over partitions).
. Rework the core procedure of device resolution (by walking along
the device-mapper tree during logical device resolution) to be an
explicit sequence of pairs (level-lookup, goto-parent-level);
. Add an "extended" device to keep a track of file system offset
while ascending the device tree;
. Identify all possible results of a single level lookup;
. Rename target_entry to dmpath_entry;
. Make the main() function to look like a call of a handler
identified by a pair (driver-id, util-id) and found by the name
of the executable.
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Fix mistake in @fs_offset calculation.
Since any logical dm-device can be built of partitions, @fs_offset
must not decrease while ascending the "device tree" during the
procedure of dm-device resolution (which always starts at the
formatted logical device, for which @fs_offset is 0).
This bug was not reproducible earlier because of restricted
functionality in a combination with side-effects. The fixup is
required however by the next patches in the series implementing
support of mirrored targets by zipl tool
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
. Modify disk_get_info() to process multiple sets of target parameters
provided by the helper script and store it in the array of "targets"
of the structure job_target_data;
. Besides the logical device, maintain an array of physical base disks
in the disk_info structure;
. Use the logical target device only to create bootmap (it is
automatically mirrored by the respective linux driver (dm, or md)
managing the mirrored target). In contrast, install bootstrap blocks
to each physical base disk individually, bypassing that driver;
. Report in verbose mode on which base disks the bootstrap
installation was performed;
. Use the following logic of setting @info->device (which is printed
as "Device...:" in verbose mode):
. source_auto - the target base disk is set;
. source_script - the target (logical) device is set;
. source_user - the device specified by user (via --targetbase
option), or config file is set.
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Add new command-line option --ipldev. When specified and IPL was done
from a supported device type, the IPL device is selected for the
requested tool operation.
Example to list IPL device information:
$ lszdev --ipldev
Example to create a persistent configuration for the IPL device:
$ chzdev --enable --persistent --ipldev
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>
Reduce code complexity by adding a utility function for reading text
files based on a variable path.
Note: chzdev/lszdev tools apply special path-handling via command line
option --base to allow redirecting hard-coded paths therefore libutil's
util_file functions cannot easily be used.
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>
Steps to reproduce: Prepare some disk for IPL, specifying its
parameters via zipl "target options", and an image IMAGE_NAME
located on another disk. Don't specify "-a" option.
Actual result: Installation succeeded (resulting in unbootable setup)
Expected result: "Error: Could not add image file 'IMAGE_NAME': File
is not on target device"
The problem is in incorrect evaluation of device number (dev_t)
of the base disk where the image is located by the function
add_component_file_range() in case when target parameters are
specified by user.
Fixup: Retrieve info of the underlying disk without any user hints,
passing zeroed structure job_target_data
This is an improved version of fb0b6263d that was reverted by
63ff07ba3 afterwards. The shortcoming of the original ( fb0b6263d )
fix: it fails to prepare for IPL mounted qcow2 images.
The difference from the original fix: when making sure that boot
files are located on the target disk: in case of failed auto-detection
of disk parameters skip the check with warnings instead of aborting
the whole installation session.
Acked-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
MSA 10 and MSA 11 introduce new function codes containing Full XTS
functions for KM instruction and HMAC functions for KMAC instruction.
Additional Full XTS and HMAC for PCKMO instruction is introduced.
Signed-off-by: Finn Callies <fcallies@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Perl logs warning message if a variable is not initialized.
get_device_data() set mp_dev with multipath device for a scsi disk device.
mp_dev remain uninitialized if there is no multipath device.
This can happen if a scsi device is not managed by dm multipath driver.
Warning message:
"Use of uninitialized value in subroutine entry at /usr/sbin/ziorep_config line 136"
Fix it by skipping the code dealing with mp_dev and continue with next
scsi device in the loop.
To reproduce, remove a scsi device from dm multipath.
$multipathd -k'del path sdh'
Then run `ziorep_config -D`.
Signed-off-by: Nihar Panda <niharp@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>
We changed lscss for more detailed output.
Adding use of dasdview for a detailed view on DASD storage.
This data will be collected in a separate file, as many DASDs might flood
the runtime.out
Also updated man pages as a new step is added
Reviewed-by: Stefan Hberland <sth@linux.ibm.com>
Signed-off-by: Joern Siglen <siglen@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The ap.rs code is already prepared for possible support
for CCA mode APQNs for the Secure Execution environment.
However, this patch marks these fields and structs with
pragma allow(dead_code) to prevent warnings during cargo
build of pvapconfig.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add a new action type 'capabilities' for the 'get' event. This
will return a JSON list of events and actions that the callout
script recognizes and actually does something with. It omits
events like 'notify' and actions like 'list' that ap-check
currently ignores.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
mdevctl introduces a new event type 'live' with action 'modify',
indicating that the specified configuration changes should be
made dynamically if possible. Use this as a trigger to perform
dynamic configuration changes to the specified vfio-ap device
if it is active.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Anthony Krowiak <akrowiak@linux.ibm.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
While unlikely, it is possible for a vfio-ap configuration JSON
to include the 'ap_config' attribute. In this case, process it
by overwriting the current list of adapters, domains and control
domains for the associated vfio-ap device struct.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Anthony Krowiak <akrowiak@linux.ibm.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
For a given vfio-ap mdev, determine whether or not the device will
need dynamic config operations. This boils down to whether or not
the device is currently active + whether or not the kernel is
detected to support dynamic config operations (via the
'ap_config' sysfs attribute).
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Anthony Krowiak <akrowiak@linux.ibm.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The qeth-udev-rule execution logs a warning as below in the journalfs.
Failed to write ATTR{/sys/bus/ccwgroup/drivers/qeth/group}, \
ignoring: Invalid argument
This occurs because the udev rule for qeth devices is triggered by
multiple ccw devices and can be invoked in parallel. This can lead to a
situation where each of the three parallel-running udev rules tries to
group the devices simultaneously. As a result, only the first rule
succeeds, while the others fail with an -EINVAL error because the CCW
devices have already been grouped.
To prevent this, schedule a new change uevent for the base device, which
will verify the sysfs before attempting the grouping. The change event is
triggered by all three devices, ensuring that the actual write to the
attribute occurs only once and only when the sysfs attribute is ready.
Hence the add events on different devices are serialized to change event
on the base device, which then prevent duplicate concurrent grouping
attempts.
Suggested-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>
The function copy_table_entry_write() maps/unmaps /proc/vmcore for each
64kB of the file in order to write its content to a dump partition.
This requires a page allocation of order 2 in kernel (crst_table_alloc)
each time a mmap() syscall is performed and which cannot always be
fulfilled due to external memory fragmentation. And this in turn
results in a OOM kernel panic while writing /proc/vmcore content to
a dump partition. To make zfcpdump more robust in the face of such
problems with page allocations of order > 0, we use a simple file
read/write loop to transfer the content of /proc/vmcore to a dump
partition. This solution is less efficient (by not much) than the old
one with mmap() because it requires additional user space copy but
we trade off here efficiency for robustness which is more important
for zfcpdump.
We use a statically allocated buffer to read data into from /proc/vmcore
and write to a dump partition to avoid repeated use of the memory
mapping kernel path which would be required for a buffer allocated
dynamically at each entry of copy_table_entry_write().
Another possible and very convenient solution would be to use sendfile()
which would avoid any user space copies but, unfortunately, sendfile()
doesn't work with large /proc files.
Example of failed mmap() call for /proc/vmcore
==============================================
[ 26.568654] init invoked oom-killer: gfp_mask=0x40cc0(GFP_KERNEL|__GFP_COMP), order=2, oom_score_adj=0
[ 26.568665] CPU: 0 PID: 1 Comm: init Not tainted 6.9.0-20240504.rc6.git0.9986ea583f39.300.fc39.s390x+zfcpdump #1
[ 26.568668] Hardware name: IBM 3931 A01 704 (LPAR)
[ 26.568669] Call Trace:
[ 26.568671] [<000003ffe03277c6>] dump_stack_lvl+0x76/0x98
[ 26.568676] [<000003ffe00f15c8>] dump_header+0x58/0x2d0
[ 26.568680] [<000003ffe00f219a>] out_of_memory+0x252/0x348
[ 26.568683] [<000003ffe0132f3e>] __alloc_pages_slowpath.constprop.0+0x65e/0x7c0
[ 26.568686] [<000003ffe01331a4>] __alloc_pages+0x104/0x128
[ 26.568688] [<000003ffe001ab46>] crst_table_alloc+0x2e/0xa0
[ 26.568693] [<000003ffe01164c4>] __pmd_alloc+0x24/0x160
[ 26.568696] [<000003ffe0116650>] pmd_alloc+0x50/0x68
[ 26.568698] [<000003ffe0117be4>] remap_pfn_range_notrack+0x194/0x310
[ 26.568701] [<000003ffe0117d7c>] remap_pfn_range+0x1c/0x28
[ 26.568703] [<000003ffe0015442>] remap_oldmem_pfn_range+0xb2/0x108
[ 26.568705] [<000003ffe01a0544>] mmap_vmcore+0x414/0x448
[ 26.568707] [<000003ffe01937c4>] proc_reg_mmap+0x84/0xa0
[ 26.568709] [<000003ffe011f264>] mmap_region+0x22c/0x6f8
[ 26.568711] [<000003ffe011fae8>] do_mmap+0x3b8/0x410
[ 26.568713] [<000003ffe01015cc>] vm_mmap_pgoff+0x9c/0xe8
[ 26.568715] [<000003ffe011d006>] ksys_mmap_pgoff+0x8e/0xb8
[ 26.568716] [<000003ffe011d0f4>] __s390x_sys_old_mmap+0x74/0x90
[ 26.568718] [<000003ffe0341a2a>] __do_syscall+0x1aa/0x220
[ 26.568720] [<000003ffe03478b0>] system_call+0x70/0x98
[ 26.568724] Mem-Info:
[ 26.568725] active_anon:1 inactive_anon:12 isolated_anon:0
active_file:83590 inactive_file:93939 isolated_file:0
unevictable:201 dirty:17845 writeback:4
slab_reclaimable:4259 slab_unreclaimable:1482
mapped:174 shmem:0 pagetables:810
sec_pagetables:0 bounce:0
kernel_misc_reclaimable:0
free:2694 free_pcp:105 free_cma:0
[ 26.568729] Node 0 active_anon:4kB inactive_anon:48kB active_file:334360kB inactive_file:375756kB unevictable:804kB isolated(anon):0kB isolated(file):0kB mapped:696kB dirty:71380kB writeback:16kB shmem:0kB writeback_tmp:0kB kernel_stack:544kB pagetables:3240kB sec_pagetables:0kB all_unreclaimable? no
[ 26.568732] DMA free:10776kB boost:0kB min:3496kB low:4368kB high:5240kB reserved_highatomic:0KB active_anon:4kB inactive_anon:48kB active_file:334360kB inactive_file:375756kB unevictable:804kB writepending:71360kB present:786428kB managed:764664kB mlocked:0kB bounce:0kB free_pcp:420kB local_pcp:420kB free_cma:0kB
[ 26.568735] lowmem_reserve[]: 0 0 0
[ 26.568738] DMA: 1069*4kB (UH) 757*8kB (UH) 11*16kB (H) 6*32kB (H) 1*64kB (H) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 10764kB
[ 26.568747] 177773 total pagecache pages
[ 26.568748] 196607 pages RAM
[ 26.568748] 0 pages HighMem/MovableOnly
[ 26.568749] 5441 pages reserved
[ 26.568749] Tasks state (memory values in pages):
[ 26.568750] [ pid ] uid tgid total_vm rss rss_anon rss_file rss_shmem pgtables_bytes swapents oom_score_adj name
[ 26.568751] Out of memory and no killable processes...
[ 26.568752] Kernel panic - not syncing: System is deadlocked on memory
[ 26.568755] CPU: 0 PID: 1 Comm: init Not tainted 6.9.0-20240504.rc6.git0.9986ea583f39.300.fc39.s390x+zfcpdump #1
[ 26.568758] Hardware name: IBM 3931 A01 704 (LPAR)
[ 26.568759] Call Trace:
[ 26.568760] [<000003ffe03277c6>] dump_stack_lvl+0x76/0x98
[ 26.568763] [<000003ffe001f14e>] panic+0x10e/0x2e8
[ 26.568765] [<000003ffe00f21c8>] out_of_memory+0x280/0x348
[ 26.568768] [<000003ffe0132f3e>] __alloc_pages_slowpath.constprop.0+0x65e/0x7c0
[ 26.568771] [<000003ffe01331a4>] __alloc_pages+0x104/0x128
[ 26.568773] [<000003ffe001ab46>] crst_table_alloc+0x2e/0xa0
[ 26.568776] [<000003ffe01164c4>] __pmd_alloc+0x24/0x160
[ 26.568779] [<000003ffe0116650>] pmd_alloc+0x50/0x68
[ 26.568781] [<000003ffe0117be4>] remap_pfn_range_notrack+0x194/0x310
[ 26.568784] [<000003ffe0117d7c>] remap_pfn_range+0x1c/0x28
[ 26.568787] [<000003ffe0015442>] remap_oldmem_pfn_range+0xb2/0x108
[ 26.568789] [<000003ffe01a0544>] mmap_vmcore+0x414/0x448
[ 26.568791] [<000003ffe01937c4>] proc_reg_mmap+0x84/0xa0
[ 26.568793] [<000003ffe011f264>] mmap_region+0x22c/0x6f8
[ 26.568795] [<000003ffe011fae8>] do_mmap+0x3b8/0x410
[ 26.568797] [<000003ffe01015cc>] vm_mmap_pgoff+0x9c/0xe8
[ 26.568799] [<000003ffe011d006>] ksys_mmap_pgoff+0x8e/0xb8
[ 26.568801] [<000003ffe011d0f4>] __s390x_sys_old_mmap+0x74/0x90
[ 26.568803] [<000003ffe0341a2a>] __do_syscall+0x1aa/0x220
[ 26.568805] [<000003ffe03478b0>] system_call+0x70/0x98
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
For vr-kernel dumps use the offsets stored in os_info entries for
virt to phys address conversion when dump virtual address is to be
read, (e.g. vmcoreinfo symbols) using similar method as implemented
in crash-utility.
It is mainly required for reading "init_uts_ns" symbol and, in case
of crashed kdump, "lowcore_ptr" symbol along with a pointers to the
lowcore of every CPU.
Acked-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Support vmcore based dumps (ngdump, zfcpdump) with uncoupled physical and
virtual addresses. For that we just remove p_paddr != p_vaddr sanity check
for elf load headers.
Acked-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Output generated using libutil's util_fmt_*() functions contains
meta-data such as hostname and time of invocation. When writing test
cases that compare expected and actual tool output, this run-time
variable information needs to be filtered out, resulting in increased
complexity.
To address this, add a global option to suppress meta-data output via
environment variable FMT_NOMETA. If set to '1', no meta-data will be
generated.
Example:
$ FMT_NOMETA=1 chpstat --format json
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The previous implementation did stop after the first download was
successful, even if it did not contain a CRL. This behavior renders a
second, third, ... link as backup location useless as the code ignores
them if the URI e.g. contains a error message. That results in not
having a CRL and probably a failed certificate verification.
Fix this by trying again if the download was successful but did not
contain a CRL
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
In order to allow loop devices usage for DASD dump emulation in fvt-tests,
do not bail out on ZG_TYPE_DASD device type returned by zg_type() for
s390_ext dump.
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
There are still a few scripts using the 'which' command to determine
either the full path or the mere existence of an executable.
Some of these scripts might run in minimal environments where 'which' is
not available due to dependency restriction. 'which' is also considered
unreliable for historical implementation details.
Use the POSIX defined [1] built-in 'command -v' instead to reduce
package dependencies and improve reliability.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The new parameter 'SCP_DATA' can be used to pass additional kernel cmdline
parameters to a stand-alone SCSI/NVMe/ECKD dumper for debugging purposes.
Configuration example
=====================
ON_PANIC=dump_reipl
DUMP_TYPE=fcp
DEVICE=0.0.4711
WWPN=0x5005076303004711
LUN=0x4711000000000000
BOOTPROG=0
BR_LBA=0
SCP_DATA="dump_debug=6 ignore_loglevel earlyprintk=sclp panic_print=3"
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
When dump is copied to the filesystem in s390 format, follow on
'zgetdump -i' can fail with ioctl error:
# zgetdump /dev/dasdb1 -f s390 dump.s390
Format Info:
Source: s390_ext
Target: s390
Copying dump:
00000001 / 00008192 MB
00003688 / 00008192 MB
00006646 / 00008192 MB
00008192 / 00008192 MB
Success: Dump has been copied
# zgetdump -iVVVV dump.s390
zgetdump: Operation "BLKSSZGET" failed on "dump.s390" (Inappropriate ioctl for device)
Call ioctl(BLKSSZGET) only for s390_ext dump format (dump can be
stored on DASD partition only, not on the filesystem). For s390 format
a blocksize is not required for dump processing since s390 dump data is
not compressed.
Fixes: 271b809495 ("zdump/dfi_s390: Support reading compressed s390_ext dumps")
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
pvattest-C had a -a option for --arpk which the Rust implementation
missed.
Add this short option.
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
