It's reported that kdump kernel failed to boot and can't dump vmcore
when crashkernel=192M and SME/SEV is active.
This is because swiotlb will be enabled and reserves 64M memory by
default on system with SME/SEV enabled. Then kdump kernel will be out of
memory after taking 64M away for swiotlb init.
So here add extra 64M memory to default crashkernel value so that kdump
kernel can function well as before. When doing that, search journalctl
for the "Memory Encryption Features active: AMD" to check if SME or SEV
is active. This line of log is printed out in kernel function as below
and the type SME is mutual exclusive with type SEV.
***:
arch/x86/mm/mem_encrypt.c:print_mem_encrypt_feature_info()
Note:
1) The conditional check is relying on journalctl log because I didn't
find available system interface to check if SEV is active. Even
though we can check if SME is active via /proc/cpuinfo. For
consistency, I take the same check for both SME and SEV by searching
journalctl.
2) The conditional check is relying on journalctl log, means it won't
work for crashkernel setting in anoconda because the installation
kernel doesn't have the SME/SEV setting. So customer need manually
run 'kdumpctl reset-crashkernel' to reset crashkernel to add the
extra 64M after OS installation.
3) We need watch the line of log printing in
print_mem_encrypt_feature_info() in kernel just in case people may
change it in the future.
Signed-off-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Currently _crashkernel_add can't deal with larger memory ranges like
terabyte. For example, '_crashkernel_add "128G-1T:4G" "0"' actually
returns empty result. This patch allows _crashkernel_add to address
terabyte, petabyte and exabyte memory ranges.
Fixes: 64f2827a ("kdump-lib: Harden _crashkernel_add")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2243068
Currently, when kexec-tools is installed, the kernel will automatically
have the crashkernel parameter set up. In the case where users only want
the kexec reboot feature, this is not what users want as a 1G-RAM system
will lose 192M memory. Considering Fedora's systemd preset policy has
kdump.service disabled and RHEL' has kdump.service enabled, this patch
makes kexec-tools only reset crashkernel when kdump.service is enabled.
Reported-by: Chris Murphy <bugzilla@colorremedies.com>
Cc: Philipp Rudo <prudo@redhat.com>
Cc: Adam Williamson <awilliam@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
On secure boot enabled systems with static keys, kexec with kexec_file_load(-s)
fails as "Permission Denied" when fadump is enabled.
Similar to kdump, load kernel signing key for fadump as well.
Reported-by: Sachin P Bappalige <sachinpb@linux.vnet.ibm.com>
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
Kernel signing key is deleted once kdump is loaded. This causes confusion in
debugging since key is no longer visible. Unless someone knows how
kdumpctl script works, it is difficult to find out how kdump could be
loaded when there is no key on .ima keyring.
Remove deletion of kernel signing key once loaded. And then to prevent
multiple loading of same key when kdump service is disabled/enabled, update
key description field as well.
Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Currently, some tests failed with "The param /boot/boot/vmlinuz-xxx is
incorrect", for example,
[root@fedora kexec-tools]# shellspec spec/kdumpctl_manage_reset_spec.sh
Examples:
1) kdumpctl reset-crashkernel [--kernel] [--fadump] Test the kdump dump mode --kernel=ALL kdumpctl should warn the user that crashkernel has been udpated
When call reset_crashkernel --kernel=ALL
1.1) The error should include Updated crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M for kernel=/boot/vmlinuz-5.15.6-100.fc34.x86_64
expected "The param /boot/boot/vmlinuz-5.15.6-100.fc34.x86_64 is incorrect
The param /boot/boot/vmlinuz-5.15.6-100.fc34.x86_64 is incorrect
kdump: Updated crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M for kernel=/boot/boot/vmlinuz-5.15.6-100.fc34.x86_64. Please reboot the system for the change to take effect.
The param /boot/boot/vmlinuz-5.14.14-200.fc34.x86_64 is incorrect
The param /boot/boot/vmlinuz-5.14.14-200.fc34.x86_64 is incorrect
kdump: Updated crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M for kernel=/boot/boot/vmlinuz-5.14.14-200.fc34.x86_64. Please reboot the system for the change to take effect.
The param /boot/boot/vmlinuz-0-rescue-e986846f63134c7295458cf36300ba5b is incorrect
The param /boot/boot/vmlinuz-0-rescue-e986846f63134c7295458cf36300ba5b is incorrect
kdump: Updated crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M for kernel=/boot/boot/vmlinuz-0-rescue-e986846f63134c7295458cf36300ba5b. Please reboot the system for the change to take effect." to include "Updated crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M for kernel=/boot/vmlinuz-5.15.6-100.fc34.x86_64"
# spec/kdumpctl_reset_crashkernel_spec.sh:69
This happens because when a system has a boot partition, grubby
automatically prefixes a path with "/boot". The current boot loader
entries used for tests already has the prefix "/boot" in the path and
prefixing a path again will cause the above problem.
grubby uses "mountpoint -q /boot" to tell if there is a boot partition.
This patch mocks mountpoint so grubby knows the boot loader entries
are for a system without a boot partition.
Note this patch also avoids another error seen in the setup phase of the
test "The param /boot/vmlinuz-xxx is incorrect". I believe this error is
a bug of "grubby --update-kernel" in testing mode because running the
grubby in normal mode actually works and "grubby --info=/boot/vmlinuz-*"
also works in testing mode,
[root@fedora support]# grubby --no-etc-grub-update --grub2 --bad-image-okay --env=grub_env -b boot_load_entries --args crashkernel=333M --update-kernel=/boot/vmlinuz-5.15.6-100.fc34.x86_64
The param /boot/vmlinuz-5.15.6-100.fc34.x86_64 is incorrect
[root@fedora support]# grubby --no-etc-grub-update --grub2 --bad-image-okay --env=grub_env -b boot_load_entries --info=/boot/vmlinuz-5.15.6-100.fc34.x86_64
index=0
kernel="/boot/boot/vmlinuz-5.15.6-100.fc34.x86_64"
[root@fedora support]]# grubby --args crashkernel=333M --update-kernel=/boot/vmlinuz-6.0.7-301.fc37.x86_64 && echo "succeed"
succeed
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
The test case for parse_config creates a default kdump.conf in the pwd.
This fails when the pwd is read only. Thus move the default kdump.conf
to /tmp just like it is done for the "bad" kdump.conf. This also allows
to reuse the temporary file used for the "bad" case.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
The two systems are IA64 based which is no longer supported by Fedora
and was only supported in RHEL up to RHEL5. So it is safe to simply drop
the special handling. In case it is still wanted nevertheless the
special handling should be added to kdump-lib.sh:prepare_cmdline rather
than editing the sysconfig in the spec file.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
_crashkernel_add currently always assumes the good case, i.e. that the
value of the crashkernel parameter has the correct syntax and that the
delta added is a number. Both doesn't have to be true when the values
are provided by users. Thus add some additional checks.
Furthermore require the delta to have a explicit unit, i.e. no longer
assume that is in megabytes, i.e. 100 -> 100M.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
rpmbuild throws a warning with
line 80: It's not recommended to have unversioned Obsoletes: Obsoletes: diskdumputils netdump kexec-tools-eppic
In that diskdump and netdump were last used in RHEL4 and
kexec-tools-eppic was removed with Fedora 22. There is no supported
update path in which a current package could replace one of these three.
Thus simply drop the Obsoletes.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Currently the dracut modules are first prepared in a temporary directory
before they are moved to modules.d. All the preparation work can be done
by a single call to 'install' per file. Thus get rid off the indirection
and install the dracut modules directly to modules.d.
While at it merge the three macros to remove the prefix into one.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
When override_resettable was introduced in 2013 with 4b850d2 ("Check if
block device as dump target is resettable") it was forgotten to add the
new option to check_config (today the function is called parse_config).
So if a user would have set override_resettable check_config would have
returned an error ("Invalid kdump config option override_resettable")
and starting the kdump service would have failed. As there has been no
bug report in the last ~10 years it is safe to assume that the option
was never used. Thus simply remove the option.
Fixes: 4b850d2 ("Check if block device as dump target is resettable")
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
With multiple kernel variants on the same architecture, e.g. the 4k and
64k kernel on aarch64, we can no longer assume that the crashkernel
value for the currently running kernel will work for all installed
kernels. This also means that we can no longer update the grub config as
we don't know which value to set it to. Thus get the crashkernel value
for each kernel and stop updating the grub config.
While at it merge the _new_fadump and _fadump_val variables and remove
_read_kernel_arg_in_grub_etc_default which has no user.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Prevent the --fadump option to be used on non-PPC systems. This not only
prevents user errors but also guarantees that _dump_mode and _fadump_val are
empty on these systems.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
_update_kernel_cmdline handles two cmdline parameters at once. This does not
only make the function itself but also its callers more complicated than
necessary. For example in _update_crashkernel the fadump gets "updated" to
the value that has been read from grubby. Thus simplify
_update_kernel_cmdline to only update one parameter at once.
While at it shorten some variable named in the callers.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
condrestart is a left over from the time of SysVinit that is no longer
needed since the kexec-tools switched to systemd (10c91a1 ("Removing
sysvinit files") plus the one before). What's especially intriguing is
that from the beginning (0112f36 ("- Add a kdump sysconfig file and init
script - Spec file additions for pre/post install/uninstall")) the
sub-command never did any actual work (other than not returning an
error). Thus simply remove the condrestart sub-command.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
_get_current_running_kernel_path is identical to
_find_kernel_path_by_release $(uname -r) so simply use this instead of
defining a new function.
While at it simplify reset_crashkernel slightly. This changes the
behavior of the function for the case when KDUMP_KERNELVER is defined
but no kernel with this version is installed. Before, the missing
kernel is silently ignored and the currently running kernel is used
instead. Now, kdumpctl will exit with an error.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Only check whether modules for a given kernel version are installed
instead of searching for a kernel image. It's safer to assume that every
kernel uses kernel modules compared to that it follows certain naming
conventions. Furthermore it is much more lightweight and thus allows to
determine the KDUMP_KERNELVER much earlier for every command in
kdumpctl.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
There is value to use the function in other places as well. For example
it can be used to check whether optional dependencies, like grubby, are
installed. Thus make it more generic so it can be reused in later
commits.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
This includes fixes for
SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns.
SC2005 (style): Useless echo? Instead of 'echo $(cmd)', just use 'cmd'.
SC2162 (info): read without -r will mangle backslashes.
SC2086 (info): Double quote to prevent globbing and word splitting.
SC2317 (info): Command appears to be unreachable. Check usage (or ignore if invoked indirectly).
In addition add some source hints to prevent false positive findings.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
The fadump sysfs nodes /sys/kernel/fadump_[enabled|registered], have
been relocated to /sys/kernel/fadump/[enabled|registered] by kernel
commits d418b19f34ed ("powerpc/fadump: Reorganize /sys/kernel/fadump_*
sysfs files").
To ensure compatibility, symbolic links were added for each relocated
sysfs entry. Nonetheless, note that these symbolic links might be
removed later, as they have been deprecated by kernel commit
3f5f1f22ef10 ("Documentation/ABI: Mark /sys/kernel/fadump_* sysfs files
deprecated")
This patch updates the scripts to use the updated fadump sysfs files.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
The size of the reserved memory in the functions show_reserved_mem,
check_crash_mem_reserved, and do_estimate are fetched from the sysfs
node `/sys/kernel/kexec_crash_size`. However, in the case of fadump,
the reserved area size is instead present in
/sys/kernel/fadump/mem_reserved.
For example:
$ kdumpctl showmem
kdump: Dump mode is fadump
kdump: Reserved 0MB memory for crash kernel
The above command showed 0MB for Reserved memory which is incorrect, the
actual reservation was 2048MB.
To resolve this issue a new helper function is introduced to fetch
reserved memory size based on the dump mode. For "fadump" mode,
it looks in `/sys/kernel/fadump/mem_reserved`, otherwise, it uses
`/sys/kernel/kexec_crash_size`. And all functions that previously
fetching reserved memory directly from `/sys/kernel/kexec_crash_size`
sysfs node are now updated to use this new function to get the reserved
memory size.
With the fix in place, the `kdumpctl showmem` command will now display
correct reserved memory size.
$ kdumpctl showmem
kdump: Dump mode is fadump
kdump: Reserved 2048MB memory for crash kernel
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Reported-by: Sachin P Bappalige <sachinpb@linux.vnet.ibm.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
There is confusing message in /var/log/anaconda/packaging.log when installing
kexec-tools during the system installation on ppc64le:
Event Notification Registration successful (id: 1)
Make servicelog_notify slient when there are no erros.
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
For kernel 64k variant, it terminates with substring 64k-debug, e.g.
vmlinuz-5.14.0-327.el9.aarch64+64k-debug.
Providing an extra matching pattern to filter out it.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
The temporary directory is currently created under the current working
directory. That alone isn't ideal but works most of the time. However,
it will fail when the current working directory is not writable. So make
sure the directory is created within TMPDIR.
Fixes: ea00b7d ("kdumpctl: Move temp file in get_kernel_size to global temp dir")
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
And with commit t5b31b099 ("Simplify the management of the kernel
parameter crashkernel"), the default crashkernel value will be
used for the kernel. But the test VM has a RAM of 768M thus this is no
actual reserved memory for kdump. Even With the old crashkernel=224M,
network dumping tests like nfs-kdump will fail out of memory when
running against current Fedora Cloud images (>=F37).
This patch address the above two issues by
1. increasing the RAM of test VM to 1G
2. installing the kernel-modules which contains the squashfs module in
order to use the dracut squash module for kdump initrd.
Thanks to the dracut squash module, now even crashkernel=192M (the
default crashkernel value for RAM between 1G and 4G) works for
network dumping. Another benefit brought by this change is the default
crashkernel value can be tested as well.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
All the tests failed to run on the Fedora 37 host because the boot
partition failed to be mounted and in turn the key kernel cmdline
parameters like selinux=0 couldn't be added.
The root problem is somehow running lsblk on the second partition
returns an empty label unless we wait for enough time. Before figuring
out the root cause, simply skip check that the second partition
needs to have the boot label.
Note the root problem can be produced by building a test image,
cd tests
./scripts/build-image.sh Fedora-Cloud-Base-37-1.7.x86_64.qcow2 output_image scripts/build-scripts/base-image_test.sh
Source image is qcow2, using snapshot...
Formatting 'build/base-image1.building', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=5368709120 backing_file=Fedora-Cloud-Base-37-1.7.x86_64.qcow2 backing_fmt=qcow2 lazy_refcounts=off refcount_bits=16
It's a image with multiple partitions, using last partition as main partition
grep: /boot/grub2/grubenv: No such file or directory
grub2-editenv: error: cannot open `/boot/grub2/grubenv.new': No such file or directory.
/dev/nbd0 disconnected
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Tests failed to run against Fedora 37 or newer cloud images because of
the following error,
It's a image with multiple partitions, using last partition as main partition
'xxx/tests/build/x86_64/kexec-tools-2.0.26-5.fc37.src.rpm' not found
/dev/nbd0 disconnected
make: *** [Makefile:73: xxx/tests/output/test-base-image] Error 1
This is because starting with Fedora 37, rpm changes its API,
# Fedora >= 37
$ rpm -q --specfile kexec-tools.spec
kexec-tools-2.0.26-5.fc37.src
# Fedora 36
$ rpm -q --specfile kexec-tools.spec
kexec-tools-2.0.26-5.fc36
The tests depends on rpm to generate correct RPM name. Fix this issue by
removing the trailing .src from the output of "rpm -q --specfile".
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
After introducing 64k variant kernel on aarch64, an example kernel name
looks like "vmlinuz-5.14.0-316.el9.aarch64+64k". To match the plus
symbol, it demands an escape charater.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
On 4k and 64k kernels, the typical consumption values for SMMU are 36MB
and 384MB, respectively. Hence for 64k kernel, the consumption by smmu
should be taken into account carefully.
To do it by adding the extra 384MB value if installing a 64k kernel.
The upper limit value 384MB is calculated according to the formula in
the kernel smmu driver.
As for mlx5 network cards, it is measured by a pratical test, 200M for
64k variant, 150M for 4k variant
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
On aarch64, both 4K and 64K kernel can be installed, while they demand
different size reserved memory for kdump kernel.
'get_conf PAGE_SIZE' can not work if installing a 64K kernel when
running a 4K kernel. Hence resorting to the kernel release naming rules.
At present, the 64K kernel has the keyword '64k' in its suffix.
The base line for 64K is decided based on 4K. The diff 100M is picked up
since on a high end machine without smmu enabled, the diff of MemFree is
82M.
As for the smmu case, a huge difference in the memory consumption lies
between 64k and 4k driver. And it should be calculated separatedly.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
kdump_get_arch_recommend_crashkernel() expects the kernel version info,
while _update_kernel() provides the absolute path, which contains the
kernel version info.
This patch introduce a dedicated function parse_kver_from_path() to
extract the kernel info from the path
Credit to Philipp, who contributes the original code.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
This help function can manipulate the crashkernel cmdline by adding an
number for each item. Also a basic test case for _crashkernel_add() is
provided in this patch.
Credit to Philipp, who contributes the original code.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
The warning messages should not be included in the generated files.
Redirecting the warning for an unknown architecture to stderr.
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
A space was added by mistake and unfortunately fips-mode-setup refuses
an extra parameter,
# fips-mode-setup --is-enabled 2 > /dev/null
# echo $?
2
# fips-mode-setup --is-enabled 2
Check, enable, or disable the system FIPS mode.
usage: /usr/bin/fips-mode-setup --enable|--disable [--no-bootcfg]
usage: /usr/bin/fips-mode-setup --check
usage: /usr/bin/fips-mode-setup --is-enabled
So in this case mkdumprd can never detect if FIPS is enabled. Fix this
mistake.
Fixes: 443a43e0 ("mkdumprd: call dracut with --add-device to install the drivers needed by /boot partition automatically for FIPS")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Tao Liu <ltao@redhat.com>
Currently, kexec-tools only updates the crashkernel to a new default
value only when both two conditions are met,
- auto_reset_crashkernel=yes in kdump.conf
- existing kernels or current running kernel should use the old default
value.
To address seen corner cases, the logic to tell if the second condition
is met becomes quite complex. Instead of making the logic more complex
to support aarch64-64k, this patch drops the second condition to
simplify the management of the crashkernel kernel parameter.
Another change brought by this simplification is kexec-tools will also
set up the kernel crashkernel parameter for a fresh install (previously
it's limited to osbuild).
Note
1. This patch also stop trying to update /etc/default/grub because
a) it only affects the static file /boot/grub2/grub.cfg
b) grubby is recommended to change the kernel command-line parameters
for both Fedora [1] and RHEL9 [2][3]
c) For the cases of aarch64 and POWER, different kernels could have
different default crashkernel value.
2. Starting with Fedora 37, posttrans rpm scriplet distinguish between
package install and upgrade.
[1] https://fedoraproject.org/wiki/GRUB_2
[2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/configuring-kernel-command-line-parameters_managing-monitoring-and-updating-the-kernel#changing-kernel-command-line-parameters-for-all-boot-entries_configuring-kernel-command-line-parameters
[3] https://access.redhat.com/solutions/1136173
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Currently, for non-s390x systems, the return code is 1 even when
_update_kernel_cmdline is correctly executed. This makes callers like
reset_crashkernel_after_update fail to print a message if a kernel has
its crashkernel updated. Fix it by put the code inside if block for
s390x.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
