Resolves: https://issues.redhat.com/browse/RHEL-518
Upstream: Fedora
Conflict: None
commit e42a823dae
Author: Coiby Xu <coxu@redhat.com>
Date: Thu Jun 1 16:05:05 2023 +0800
mkdumprd: Use the correct syntax to redirect the stderr to null
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>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2169720
Upstream: src.fedoraproject.org/rpms/kexec-tools.git
Conflicts: Small context difference in kexec-tools.spec
commit ea7be0608e
Author: Philipp Rudo <prudo@redhat.com>
Date: Fri May 5 17:14:42 2023 +0200
kdumpctl: Add basic UKI support
A Unified Kernel Image (UKI) is a single EFI PE executable combining an
EFI stub, a kernel image, an initrd image, and the kernel command line.
They are defined in the Boot Loader Specification [1] as type #2
entries. UKIs have the advantage that all code as well as meta data that
is required to boot the system, not only the kernel image, is combined
in a single PE file and can be signed for EFI SecureBoot. This extends
the coverage of SecureBoot extensively.
For RHEL support for UKI were included into kernel-ark with 16c7e3ee836e
("redhat: Add sub-RPM with a EFI unified kernel image for virtual
machines").
There are two problems with UKIs from the kdump point of view at the
moment. First, they cannot be directly loaded via kexec_file_load and
second, the initrd included isn't suitable for kdump. In order to enable
kdump on systems with UKIs build the kdump initrd as usual and extract
the kernel image before loading the crash kernel.
[1] https://uapi-group.org/specifications/specs/boot_loader_specification/
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Resolves: bz2169720
Upstream: src.fedoraproject.org/rpms/kexec-tools.git
Conflicts: None
commit ea00b7db43
Author: Philipp Rudo <prudo@redhat.com>
Date: Fri May 5 17:14:41 2023 +0200
kdumpctl: Move temp file in get_kernel_size to global temp dir
Others will need to use a temporary files, too. In order to avoid
potential clashes of multiple trap handlers move the local temp file
into a global temp dir.
While at it make sure that the trap handler returns the correct exit
code.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Resolves: bz2169720
Upstream: src.fedoraproject.org/rpms/kexec-tools.git
Conflicts: None
commit 81d89c885f
Author: Philipp Rudo <prudo@redhat.com>
Date: Fri May 5 17:14:40 2023 +0200
kdumpctl: Move get_kernel_size to kdumpctl
The function is only used in do_estimate. Move it to kdumpctl to
prevent confusion.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Resolves: bz2169720
Upstream: src.fedoraproject.org/rpms/kexec-tools.git
Conflicts: drop removal of irqpoll in prepare_cmdline due to missing
d55a056 ("kdumpctl: move aws workaround to kdump-lib") and
d593bfa ("KDUMP_COMMANDLINE: remove irqpoll parameter on aws aarch64 platform")
commit 0f6ad91be8
Author: Philipp Rudo <prudo@redhat.com>
Date: Thu Jan 12 16:31:07 2023 +0100
kdump-lib: fix prepare_cmdline
A recently added unit test found that prepare_cmdline has several
problems. For example an empty remove list will remove all spaces or
when the cmdline contains a parameter with quoted values containing
spaces will only remove the beginning up to the first space. Furthermore
the old design requires lots of subshells and pipes.
This patch rewrites prepare_cmdline in a way that makes the unit test
happy and tries to use as many bash built-ins as possible.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-512
Upstream: Fedora
Conflict: None
commit 443a43e075
Author: Coiby Xu <coxu@redhat.com>
Date: Wed May 24 12:01:45 2023 +0800
mkdumprd: call dracut with --add-device to install the drivers needed by /boot partition automatically for FIPS
Currently, kdump doesn't work on many FIPS-enabled systems including
Azure, ESXI, Hyper, POWER and etc. When FIPS is enabled, it needs to
access /boot//.vmlinuz-xxx.hmac to verify the integrity of the kernel.
However, on those systems, /boot fails to be mounted due to a lack of
fs and block device drivers and the system just halted after failing to
verify the integrity of the kernel. For example, on Hyper-V, sd_mod, sg,
scsi_transport_fc, hv_storvsc and hv_vmbus need to be installed in order
for /boot to be mounted.
mkdumprd calls dracut with the --no-hostonly-default-device. Following
the documentation (man dracut),
--no-hostonly-default-device
Do not generate implicit host devices like root, swap, fstab, etc.
Use "--mount" or "--add-device" to explicitly add devices as needed
this patch uses "--add-device" to explicitly add the device of /boot.
Note there is already an attempt to fix it in dracut's 01fips module
i.e. via the commit 83651776 ("fips: ensure fs module for /boot is
installed"). Unfortunately it only installs the file system driver e.g.
xfs.
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2078176
Upstream: Fedora
Conflict: None
commit d619b6dabe
Author: Lichen Liu <lichliu@redhat.com>
Date: Tue Apr 4 14:13:14 2023 +0800
kdumpctl: lower the log level in reset_crashkernel_for_installed_kernel
Although upgrading the kernel with `rpm -Uvh` is not recommended, the
kexec-tools plugin prints confusing error logs when a customer upgrades the
kernel through it.
```
kdump: kernel 5.14.0-80.el9.x86_64 doesn't exist
kdump: Couldn't find current running kernel
```
Not finding the currently running kernel will only make kdump unable to copy the
grub entry parameters to the newly installed kernel, so lower the log level.
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Related: bz2151504
Upstream: Fedora
Conflict: None
commit 12d9eff9dc
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Mar 28 16:33:34 2023 +0800
Show how much time kdump has waited for the network to be ready
Relates: https://bugzilla.redhat.com/show_bug.cgi?id=2151504
Currently, when the network isn't ready, kdump would repeatedly print
the same info,
[ 29.537230] kdump[671]: Bad kdump network destination: 192.123.1.21
[ 30.559418] kdump[679]: Bad kdump network destination: 192.123.1.21
[ 31.580189] kdump[687]: Bad kdump network destination: 192.123.1.21
This is not user-friendly and users may think kdump has got stuck. So
also show much time has waited for the network to be ready,
[ 29.546258] kdump[673]: Waiting for network to be ready (50s / 10min)
...
[ 32.608967] kdump[697]: Waiting for network to be ready (56s / 10min)
Note kdump_get_ip_route no longer prints an error message and it's up to
the caller to determine the log level and print relevant messages. And
kdump_collect_netif_usage aborts when kdump_get_ip_route fails.
Reported-by: Martin Pitt <mpitt@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2151504
Upstream: Fedora
Conflict: None
commit df6f25ff20
Author: Coiby Xu <coxu@redhat.com>
Date: Mon Mar 27 13:17:32 2023 +0800
Tell nmcli to not escape colon when getting the path of connection profile
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2151504
When a NetworManager connection profile contains a colon in the name,
"nmcli --get-values UUID,FILENAME" by default would escape the colon
because a colon is also used for separating the values. In this case,
99kdumpbase fails to get the correct connection profile path,
kdumpctl[5439]: cp: cannot stat '/run/NetworkManager/system-connections/static-52\\\:54\\\:01.nmconnection': No such file or directory
kdumpctl[5440]: sed: can't read /tmp/1977-DRACUT_KDUMP_NM/ifcfg-static-52-54-01: No such file or directory
kdumpctl[5449]: dracut-install: ERROR: installing '/tmp/1977-DRACUT_KDUMP_NM/ifcfg-static-52-54-01' to '/etc/NetworkManager/system-connections/ifcfg-static-52-54-01'
As a result, dumping vmcore to a remote nfs would fail.
In our case of getting connection profile path, there is no need to escape the
colon so pass "-escape no" to nmcli,
[root@localhost ~]# nmcli --get-values UUID,FILENAME c show
659e09c1-a6bd-3549-9be4-a07a1a9a8ffd:/etc/NetworkManager/system-connections/aa\:bb.nmconnection
[root@localhost ~]# nmcli -escape no --get-values UUID,FILENAME c show
659e09c1-a6bd-3549-9be4-a07a1a9a8ffd:/etc/NetworkManager/system-connections/aa:bb.nmconnection
Suggested-by: Beniamino Galvani <bgalvani@redhat.com>
Reported-by: Martin Pitt <mpitt@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2140721
Upstream: Fedora
Conflict: None
commit 70c7598ef0
Author: Coiby Xu <coxu@redhat.com>
Date: Fri Dec 23 16:03:38 2022 +0800
Install nfsv4-related drivers when users specify nfs dumping via dracut_args
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2140721
Currently, if users specify dumping to nfsv4 target via
dracut_args --mount "<NFS-server-ip>:/var/crash /mnt nfs defaults"
it fails with the following errors,
[ 5.159760] mount[446]: mount.nfs: Protocol not supported
[ 5.164502] systemd[1]: mnt.mount: Mount process exited, code=exited, status=32/n/a
[ 5.167616] systemd[1]: mnt.mount: Failed with result 'exit-code'.
[FAILED] Failed to mount /mnt.
This is because nfsv4-releted drivers are not installed to kdump initrd.
mkdumprd calls dracut with "--hostonly-mode strict". If nfsv4-related
drivers aren't loaded before calling dracut, they won't be installed.
When users specify nfs dumping via dracut_args, kexec-tools won't mount
the nfs fs beforehand hence nfsv4-related drivers won't be installed.
Note dracut only installs the nfs driver i.e. nfsv3 driver for "--mount
... nfs". So also install nfsv4-related drivers when users specify nfs
dumping via dracut_args. Since nfs_layout_nfsv41_files depends on nfsv4,
the nfsv4 driver will be installed automatically.
As for the reason why we support nfs dumping via dracut_args instead of
asking user to use the nfs directive, please refer to commit 74c6f464
("Support special mount information via 'dracut_args'").
Fixes: 4eedcae5 ("dracut-module-setup.sh: don't include multipath-hostonly")
Reported-by: rcheerla@redhat.com
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2177574
Upstream: RHEL-only
This reverts commit 870ec2ec93.
Now the real fix has gone into the RHEL-9 kernel [1], the temporary
workaround can be removed.
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2129726
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: bz2177674
Upstream: Fedora
Conflict: Move to kdump.sysconfig.s390 due to missing
677da8a ("sysconfig: use a simple generator script to maintain")
Author: Philipp Rudo <prudo@redhat.com>
Date: Tue Mar 7 14:45:35 2023 +0100
sysconfig: add zfcp.allow_lun_scan to KDUMP_COMMANDLINE_REMOVE on s390
Probing unnecessary I/O devices wastes memory and in extreme cases can
cause the crashkernel to run OOM. That's why the s390-tools maintain
their own module, 95zdev-kdump [1], that disables auto LUN scanning and
only configures zfcp devices that can be used as dump target. So remove
zfcp.allow_lun_scan from the kernel command line to prevent that we
accidentally overwrite the default set by the module.
[1] https://github.com/ibm-s390-linux/s390-tools/blob/master/zdev/dracut/95zdev-kdump/module-setup.sh
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Resolves: bz2174836
Upstream: Fedora
Conflict: None
commit f9c32372d2
Author: Lichen Liu <lichliu@redhat.com>
Date: Tue Jun 21 16:55:09 2022 +0800
kdump-lib: Add the CoreOS kernel dir to the boot_dirlist
The kernel of CoreOS is not in the standard locations, add
/boot/ostree/* to the boot_dirlist to find the vmlinuz.
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Acked-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2174836
Upstream: Fedora
Conflict: None
commit f9c32372d2
Author: Dusty Mabe <dusty@dustymabe.com>
Date: Wed Jun 22 12:34:12 2022 -0400
kdump-lib: attempt to fix BOOT_IMAGE detection
Currently $boot_img can get bad data if running on a platform
that doesn't set BOOT_IMAGE in the kernel command line. For
example, currently:
- s390x Fedora CoreOS machine:
```
[root@cosa-devsh ~]# sed "s/^BOOT_IMAGE=\((\S*)\)\?\(\S*\) .*/\2/" /proc/cmdline
mitigations=auto,nosmt ignition.platform.id=qemu ostree=/ostree/boot.0/fedora-coreos/2a72567ac8f7ed678c3ac89408f795e6ccd4e97b41e14af5f471b6a807e858b9/0 root=UUID=2a88436a-3b6b-4706-b33a-b8270bd87cde rw rootflags=prjquota boot=UUID=f4b2eaa5-9317-4798-85cf-308c477fee4c crashkernel=600M
```
where on a platform that uses GRUB we get:
- x86_64 Fedora CoreOS machine:
```
[root@cosa-devsh ~]# sed "s/^BOOT_IMAGE=\((\S*)\)\?\(\S*\) .*/\2/" /proc/cmdline
/ostree/fedora-coreos-af4f6cc7b9ff486cfa647680b180e989c72c8eed03a34a42e7328e49332bd20e/vmlinuz-5.18.5-200.fc36.x86_64
```
We should change the setting of the boot_img variable such that it will
be empty if BOOT_IMAGE doesn't exist.
With this change on the s390x machine:
```
[root@cosa-devsh ~]# grep -P -o '^BOOT_IMAGE=(\S+)' /proc/cmdline | sed "s/^BOOT_IMAGE=\((\S*)\)\?\(\S*\)/\2/"
[root@cosa-devsh ~]#
```
This change mattered much more before the change in c5bdd2d which changed
the following line from [[ -n $boot_img ]] to [[ "$boot_img" == *"$kdump_kernelver" ]].
Still I think this change has merit.
Signed-off-by: Dusty Mabe <dusty@dustymabe.com>
Acked-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2174836
Upstream: Fedora
Conflict: None
commit a1ebf0b565
Author: Dusty Mabe <dusty@dustymabe.com>
Date: Fri Jun 24 09:57:03 2022 -0400
kdump-lib: change how ostree based systems are detected
The current recommendation is to check for /run/ostree-booted.
See https://bugzilla.redhat.com/show_bug.cgi?id=2092012#c0
Signed-off-by: Dusty Mabe <dusty@dustymabe.com>
Acked-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2174836
Upstream: Fedora
Conflict: None
commit 980f10aa40
Author: Dusty Mabe <dusty@dustymabe.com>
Date: Wed Jun 22 11:58:31 2022 -0400
kdump-lib: clear up references to Atomic/CoreOS
There are many variants on OSTree based systems these days so
we should probably refer to the class of systems as "OSTree
based systems". Also, Atomic Host is dead.
Signed-off-by: Dusty Mabe <dusty@dustymabe.com>
Acked-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2168504
Upstream: RHEL-only
After leapp upgrade from 8.8 to 9.2 on Azure, RHEL9 kernel has
crashkernel=auto. This happens because kexec-tools's posttrans scriptlet
is executed before kernel's posttrans scriptlet (which in turn runs the
kernel-install hooks). One of the kernel-install hook is responsible for
adding a new boot entry for the new kernel. So when kexec-tools's posttrans
scriptlet is running, RHEL9 kernel is yet to have a boot entry so
kexec-tools couldn't set up the crashkernel parameter. Later one
kernel-install hook makes RHEL9 kernel inherit crashkernel=auto.
Fix this issue by letting 92-crashkernel.install reset crashkernel=auto.
Reported-by: Yuxin Sun <yuxisun@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Related: bz2060319
Upstream: Fedora
Conflict: None
commit 12e6cd2b76
Author: Coiby Xu <coxu@redhat.com>
Date: Mon Feb 20 17:33:08 2023 +0800
Use the correct command to get architecture
`uname -r` was used by mistake. As a result, kexec-tools failed to
update crashkernel=auto during in-place upgrade from RHEL8 to RHEL9.
`uname -m` should be used to get architecture instead.
Fixes: 5951b5e2 ("Don't try to update crashkernel when bootloader is not installed")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Lichen Liu <lichliu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2151500
Upstream: Fedora
Conflict: None
commit 3b22cce1cb
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Dec 14 10:12:17 2022 +0800
dracut-module-setup.sh: skip installing driver for the loopback
interface
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2151500
Currently, kdump initrd fails to be built when dumping vmcore to
localhost via ssh or nfs,
kdumpctl[3331]: Cannot get driver information: Operation not supported
kdumpctl[1991]: dracut: Failed to get the driver of lo
dracut[2020]: Failed to get the driver of lo
kdumpctl[1775]: kdump: mkdumprd: failed to make kdump initrd
kdumpctl[1775]: kdump: Starting kdump: [FAILED]
systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: kdump.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Crash recovery kernel arming.
systemd[1]: kdump.service: Consumed 1.710s CPU time.
This is because the loopback interface is used for transferring vmcore and
ethtool can't get the driver of the loopback interface. In fact, once
COFNIG_NET is enabled, the loopback device is enabled and there is no driver
for the loopback device. So skip installing driver for the loopback device.
The loopback interface is implemented in linux/drivers/net/loopback.c
and always has the name "lo". So we can safely tell if a network
interface is the loopback interface by its name.
Fixes: a65dde2d ("Reduce kdump memory consumption by only installing needed NIC drivers")
Reported-by: Martin Pitt <mpitt@redhat.com>
Reported-by: Rich Megginson <rmeggins@redhat.com>
Reviewed-by: Lichen Liu <lichliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2060319
Upstream: Fedora
Conflict: commit a3da46d6 ("Skip reset_crashkernel_after_update
during package install") hasn't been backported. Note it's now
no longer needed.
commit 5951b5e268
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Dec 20 13:59:18 2022 +0800
Don't try to update crashkernel when bootloader is not installed
Currently when using anaconda to install the OS, the following errors
occur,
INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-70.el9.x86_64 ...
INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory
grep: /boot/grub2/grubenv: No such file or directory
grep: /boot/grub2/grubenv: No such file or directory
grep: /boot/grub2/grubenv: No such file or directory
...
INF packaging: Configuring (running scriptlet for): kexec-tools-2.0.23-9.el9.x86_64 ...
INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory
grep: /boot/grub2/grubenv: No such file or directory
grep: /boot/grub2/grubenv: No such file or directory
Or for s390, the following errors occur,
INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-71.el9.s390x ...
03:37:51,232 INF dnf.rpm: grep: /etc/zipl.conf: No such file or directory
grep: /etc/zipl.conf: No such file or directory
grep: /etc/zipl.conf: No such file or directory
INF packaging: Configuring (running scriptlet for): kexec-tools-2.0.23-9_1.el9_0.s390x ...
INF dnf.rpm: grep: /etc/zipl.conf: No such file or directory
This is because when anaconda installs the packages, bootloader hasn't
been installed and /boot/grub2/grubenv or /etc/zipl.conf doesn't exist.
So don't try to update crashkernel when bootloader isn't ready to avoid
the above errors.
Note this is the second attempt to fix this issue. Previously a file
/tmp/kexec_tools_package_install was created to avoid running the
related code thus to avoid the above errors but unfortunately that
approach has two issues a) somehow osbuild doesn't delete it for RHEL b)
this file could still exist if users manually remove kexec-tools.
Fixes: e218128 ("Only try to reset crashkernel for osbuild during package install")
Reported-by: Jan Stodola <jstodola@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2151842
Upstream: Fedora
Conflict: None
commit bc101086e2
Author: Coiby Xu <coxu@redhat.com>
Date: Mon Dec 12 18:37:25 2022 +0800
dracut-module-setup.sh: also install the driver of physical NIC for
Hyper-V VM with accelerated networking
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2151842
Currently, vmcore dumping to remote fs fails on Azure Hyper-V VM with
accelerated networking because it uses a physical NIC for accrelarated
networking [1]. In this case, the driver for this physical NIC should be
installed as well.
[1] https://learn.microsoft.com/en-us/azure/virtual-network/accelerated-networking-overview
Fixes: a65dde2d ("Reduce kdump memory consumption by only installing needed NIC drivers")
Reported-by: Xiaoqiang Xiong <xxiong@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2139000
Upstream: Fedora
Conflict: None
commit f98bd5895e
Author: Hari Bathini <hbathini@linux.ibm.com>
Date: Fri Dec 2 18:46:49 2022 +0530
fadump: use 'zstd' as the default compression method
If available, use 'zstd' compression method to optimize the size of
the initrd built with fadump support. Also, 'squash+zstd' is not
preferred because more disk space is consumed with 'squash+zstd' due
to the additional binaries needed for fadump with squash case.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Acked-by: Tao Liu <ltao@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2139000
Upstream: Fedora
Conflict: None
commit 25411da966
Author: Hari Bathini <hbathini@linux.ibm.com>
Date: Fri Dec 2 18:46:50 2022 +0530
fadump: fix default initrd backup and restore logic
In case of fadump, default initrd is rebuilt with dump capturing
capability, as the same initrd is used for booting production kernel
as well as capture kernel.
The original initrd file is backed up with a checksum, to restore
it as the default initrd when fadump is disabled. As the checksum
file is not kernel version specific, switching between different
kernel versions and kdump/fadump dump mode breaks the default initrd
backup/restore logic. Fix this by having a kernel version specific
checksum file.
Also, if backing up initrd fails, retaining the checksum file isn't
useful. Remove it.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2139000
Upstream: Fedora
Conflict: Upstream doesn't have Source37: supported-kdump-targets.txt,
so the number of SourceXX need to be changed.
commit 4a2dcab26a
Author: Hari Bathini <hbathini@linux.ibm.com>
Date: Fri Dec 2 18:46:51 2022 +0530
fadump: add a kernel install hook to clean up fadump initramfs
Kdump service will create fadump initramfs when needed, but it won't
clean up the fadump initramfs on kernel uninstall. So create a kernel
install hook to do the clean up job.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2139000
Upstream: Fedora
Conflict: None
commit a833624fe5
Author: Hari Bathini <hbathini@linux.ibm.com>
Date: Mon Nov 21 18:56:08 2022 +0530
fadump: avoid status check while starting in fadump mode
With kernel commit 607451ce0aa9b ("powerpc/fadump: register for fadump
as early as possible"), 'kdumpctl start' prematurely returns with the
below message:
"Kdump already running: [WARNING]"
instead of setting default initrd with dump capture capability as
required for fadump. Skip status check in fadump mode to avoid this
problem.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2139000
Upstream: Fedora
Conflict: None
commit 748eb3a2a6
Author: Kairui Song <kasong@tencent.com>
Date: Sun Jan 9 18:03:35 2022 +0800
spec: only install mkfadumprd for ppc
fadump is a ppc only feature, mkfadumprd is only needed for fadump, drop
it for other arch.
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Kairui Song <kasong@tencent.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2139000
Upstream: Fedora
Conflict: None
commit f33c99e347
Author: Hari Bathini <hbathini@linux.ibm.com>
Date: Mon Oct 31 15:42:21 2022 +0530
fadump: preserve file modification time to help with hardlinking
With commit fa9201b2 ("fadump: isolate fadump initramfs image within
the default one"), initramfs image gets to hold two images, one for
production kernel boot purpose and the other for capture kernel boot.
Most files are common among the two images. Retain file modification
time to replace duplicate files with hardlinks and save space. Also,
avoid unnecessarily compressing fadump image that is decompressed
immediately anyway.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2139000
Upstream: Fedora
Conflict: None
commit 55b0dd03b3
Author: Hari Bathini <hbathini@linux.ibm.com>
Date: Mon Oct 31 15:42:20 2022 +0530
fadump: do not use squash to reduce image size
With commit fa9201b2 ("fadump: isolate fadump initramfs image within
the default one"), initramfs image gets to hold two squash images, one
for production kernel boot purpose and the other for capture kernel
boot. Having separate images improved reliability for both production
kernel and capture kernel boot scenarios, but the size of initramfs
image became considerably larger.
Instead of having squash images, compressing $initdir without using
squash images reduced the size of initramfs image for fadump case by
around 30%. So, avoid using squash for fadump case.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2151832
Upstream: Fedora
Conflict: None
commit b45896c620
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Dec 6 18:18:32 2022 +0800
dracut-module-setup.sh: stop overwriting dracut's trap handler
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2149246
Latest Workstation live x86_64 image has an excess increase of ~300 MB
in size. This is because kdumpbase module's trap handler overwrites
dracut's handler and DRACUT_TMPDIR which has three unpacked initramfs
files fails to be cleaned up. This patch moves kdumpbase module's
temporary folder under DRACUT_TMPDIR and lets dracut's trap handler do
the cleanup instead.
Fixes: d25b1ee3 ("Add functions to copy NetworkManage connection profiles to the initramfs")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2145087
Conflict: None
commit 6b6187f546f0ddad8ea84d22c3f7ad72133dcfe3
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date: Thu Sep 15 14:12:40 2022 +0530
ppc64: remove rma_top limit
Restricting kexec tool to allocate hole for kexec segments below 768MB
may not be relavent now since first memory block size can be 1024MB and
more.
Removing rma_top restriction will give more space to find holes for
kexec segments and existing in-place checks make sure that kexec segment
allocation doesn't cross the first memory block because every kexec segment
has to be within first memory block for kdump kernel to boot properly.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Simon Horman <horms@kernel.org>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2141536
Upstream: Fedora
Conflict: None
commit 5eb77ee3fa
Author: Lichen Liu <lichliu@redhat.com>
Date: Thu Nov 24 09:15:25 2022 +0800
kdumpctl: Optimize _find_kernel_path_by_release regex string
Currently _find_kernel_path_by_release uses grubby and grep to
find the kernel path, if both the normal kernel and it's debug
varient exist, the grep will give more than one kernel strings.
```
kernel="/boot/vmlinuz-5.14.0-139.kpq0.el9.s390x+debug"
kernel="/boot/vmlinuz-5.14.0-139.kpq0.el9.s390x"
```
This will cause an error when installing debug kernel.
```
The param "/boot/vmlinuz-5.14.0-139.kpq0.el9.s390x+debug
/boot/vmlinuz-5.14.0-139.kpq0.el9.s390x" is incorrect
```
Fixes: 945cbbd ("add helper functions to get kernel path by kernel release and the path of current running kernel")
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2078460
Upstream: Fedora
commit 787b041aab
Author: Pingfan Liu <piliu@redhat.com>
Date: Tue Nov 15 12:00:09 2022 +0800
kdump.conf: use a simple generator script to maintain
This commit has the same motivation as the commit 677da8a "sysconfig:
use a simple generator script to maintain".
At present, only the kdump.conf generated for s390x has a slight
difference from the other arches, where the core_collector asks the
makedumpfile to use "-c" option to compress dump data by each page using
zlib, which is more efficient than lzo on s390x.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: bz2076416
Upstream: Fedora
Conflict: None
commit 523cda8f34
Author: Coiby Xu <coxu@redhat.com>
Date: Fri Nov 25 12:07:25 2022 +0800
Don't run kdump_check_setup_iscsi in a subshell in order to collect needed
network interfaces
Currently, dumping to iSCSI target fails because the global array
(unique_netifs) that stores the network interfaces needed by kdump is
empty. The root cause is change of the array made in a subshell (a child
process) is inaccessible to the parent process. So don't run
kdump_check_setup_iscsi in a subshell.
Fixes: 63c3805c ("Set up kdump network by directly copying NM connection profile to initrd")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
