Resolves: RHEL-63047
Upstream: fedora
Conflict: Yes, due to upstream commit d4e87721 ("kdumpctl:
make do_estimate more robust") is not backported.
commit f6e00948aba7c31f722af79ed72c4020868dcad7
Author: Tao Liu <ltao@redhat.com>
Date: Fri Oct 18 21:45:03 2024 +1300
Return the correct exit code of rebuild initrd
Resolves: https://issues.redhat.com/browse/RHEL-63047
The exit code of rebuild_initrd() should be either of
rebuild_kdump/fadump_initrd(), rather than set_vmcore_creation_status(),
otherwise it will cause a regression when rebuild initrd fails.
Fixes: 88525ebf ("Introduce vmcore creation notification to kdump")
Signed-off-by: Tao Liu <ltao@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Upstream: fedora
Resolves: RHEL-32060
Conflict: Yes, there are several conflicts. 1) Upstream have moved
dracut-kdump.sh into kdump-utils/dracut/99kdumpbase/kdump.sh,
so the targeting files are changed. 2) There are several
patchsets([1] [2]) which not backported to rhel9, so some
formating conflicts encountered. But there is no functional
change been made for the patch backporting.
[1]: https://github.com/rhkdump/kdump-utils/pull/18/commits
[2]: https://github.com/rhkdump/kdump-utils/pull/33/commits
commit 88525ebf5e43cc86aea66dc75ec83db58233883b
Author: Tao Liu <ltao@redhat.com>
Date: Thu Sep 5 15:49:07 2024 +1200
Introduce vmcore creation notification to kdump
Motivation
==========
People may forget to recheck to ensure kdump works, which as a result, a
possibility of no vmcores generated after a real system crash. It is
unexpected for kdump.
It is highly recommended people to recheck kdump after any system
modification, such as:
a. after kernel patching or whole yum update, as it might break something
on which kdump is dependent, maybe due to introduction of any new bug etc.
b. after any change at hardware level, maybe storage, networking,
firmware upgrading etc.
c. after implementing any new application, like which involves 3rd party modules
etc.
Though these exceed the range of kdump, however a simple vmcore creation
status notification is good to have for now.
Design
======
Kdump currently will check any relating files/fs/drivers modified before
determine if initrd should rebuild when (re)start. A rebuild is an
indicator of such modification, and kdump need to be rechecked. This will
clear the vmcore creation status specified in $VMCORE_CREATION_STATUS.
Vmcore creation check will happen at "kdumpctl (re)start/status", and will
report the creation success/fail status to users. A "success" status indicates
previously there has been a vmcore successfully generated based on the current
env, so it is more likely a vmcore will be generated later when real crash
happens; A "fail" status indicates previously there was no vmcore
generated, or has been a vmcore creation failed based on current env. User
should check the 2nd kernel log or the kexec-dmesg.log for the failing reason.
$VMCORE_CREATION_STATUS is used for recording the vmcore creation status of
the current env. The format will be like:
success 1718682002
Which means, there has been a vmcore generated successfully at this
timestamp for the current env.
Usage
=====
[root@localhost ~]# kdumpctl restart
kdump: kexec: unloaded kdump kernel
kdump: Stopping kdump: [OK]
kdump: kexec: loaded kdump kernel
kdump: Starting kdump: [OK]
kdump: Notice: No vmcore creation test performed!
[root@localhost ~]# kdumpctl test
[root@localhost ~]# kdumpctl status
kdump: Kdump is operational
kdump: Notice: Last successful vmcore creation on Tue Jun 18 16:39:10 CST 2024
[root@localhost ~]# kdumpctl restart
kdump: kexec: unloaded kdump kernel
kdump: Stopping kdump: [OK]
kdump: kexec: loaded kdump kernel
kdump: Starting kdump: [OK]
kdump: Notice: Last successful vmcore creation on Tue Jun 18 16:39:10 CST 2024
The notification for kdumpctl (re)start/status can be disabled by
setting VMCORE_CREATION_NOTIFICATION in /etc/sysconfig/kdump
Signed-off-by: Tao Liu <ltao@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-56832
Upstream Status: RHEL-only
This reverts commit 099aead590.
Currently get_mntpoint_from_target incorrectly return empty result for
targets that contain square bracket '[', e.g
- eng.redhat.com:/srv/[nfs]
- [2620:52:0:a1:217:38ff:fe01:131]:/srv/[nfs]
- /dev/mapper/rhel[disk]
get_mntpoint_from_target is also used in several places. To avoid
RHEL-56832 and other possible regressions, revert the bad commit.
Suggested-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-33465
Conflict: C9S misses the following two commits,
- 1397006 ("dracut-module-setup: Remove remove_cpu_online_rule() since PowerPC uses nr_cpus")
- 73c9eb7 ("dracut-module-setup: remove old s390 network device config (#1937048)")
Upstream Status: git@github.com:rhkdump/kdump-utils.git
commit 224d3102c54749eae98bfa1af8932aade8e4d2da
Author: Coiby Xu <coxu@redhat.com>
Date: Mon Apr 22 15:02:42 2024 +0800
Support setting up Open vSwitch (Ovs) Bridge network
Resolves: https://issues.redhat.com/browse/RHEL-33465
This patch supports setting up an Ovs bridge in kdump initrd. An Ovs
bridge is similar to a classic Linux bridge but we use ovs-vsctl to find
out the Ethernet device (having the MAC address as the bridge) added to
an Ovs bridge. Once we copy all the needed NetworkManager (NM) connection
profiles to kdump initrd and all the necessary files, NM will create an Ovs bridge
automatically in kdump initrd.
In the case of OpenShift Container Platform (OCP),
ovs-configuration.service [1] is responsible for setting up an Ovs bridge.
In theory, we can also try to bring up the original physical network
interface before ovs-configuration.service. But this approach is
cumbersome because it breaks our assumption that we should bring up the
same network in kdump intrd as in 1st kernel (establishing the same network
in kdump initrd only needs to copy the needed NM connection profiles
thus we don't need to learn how different network setup work under the
hood).
How to test this patch with the help of configure-ovs.sh?
=========================================================
1. Extract configure-ovs.sh from [2]
2. Install necessary packages for configure-ovs.sh
dnf install openvswitch -yq
dnf install NetworkManager-ovs nmap-ncat -yq
systemctl enable --now openvswitch
# restart NM so the ovs plugin can be activated
systemctl restart NetworkManager
3. Assume the network interface used for creating an Ovs bridge is
"ens2", use configure-ovs.sh to create an Ovs bridge,
interface=ens2
mkdir -p /etc/ovnk
echo $interface > /etc/ovnk/iface_default_hint
bash configure-ovs.sh OVNKubernetes
4. (Optional) If you want to make the created Ovs bridge survive a
reboot, simply make the created NM connections created by
configure-ovs.sh persist,
cp /run/NetworkManager/system-connections/ovs-* /etc/NetworkManager/system-connections/
If you need to create an Ovs bridge on top of a bonding network, use the
following commands for step 3,
nmcli con add type bond ifname bond0
nmcli con add type ethernet ifname eth0 master bond0
nmcli con add type ethernet ifname eth1 master bond0
echo bond0 > /etc/ovnk/iface_default_hint
bash configure-ovs.sh OVNKubernetes
Note
1. For RHEL, openvswitch3.3 may be installed so we need to get the
package name by "rpm -qf /usr/lib/systemd/system/openvswitch.service"
2. For RHEL9, openvswitch package needs to installed from another repo,
cat << 'EOF' > /etc/yum.repos.d/ovs.repo
[rhosp-rhel-9-fdp-cdn]
name=Red Hat Enterprise Linux Fast Datapath $releasever - $basearch cdn
baseurl=http://rhsm-pulp.corp.redhat.com/content/dist/layered/rhel9/$basearch/fast-datapath/os/
enabled=1
gpgcheck=0
EOF
dnf install openvswitch3.3 -yq
3. We instruct ovsdb-server to ignore NM connection files changes by
"--ovsdb-server-options='--disable-file-column-diff'". In the
future, this may not be needed if we simply copy all active NM
connection profiles to kdump initrd without changing them after
coming up with different solutions for the following cases,
1. Some environments like some Azure machine doesn't use persistent
NIC name. Current solution is to modify a NM connection
profile to match a device by MAC address, for details check
commit 568623e)
2. If a NIC has an IPv4 or IPv6 address, set the corresponding
may-fail property to no. Otherwise, dumping vmcore over IPv6
could fail because only IPv4 network is ready or vice versa. Current
solution is to disable IPv6 if only IPv4 is used and vice versa,
for details check commit 9dfcacf,
3. Some NICs need longer connection.wait-device-timeout otherwise
the connection will fail to be established (commit 6b586a9).
[1] https://github.com/openshift/machine-config-operator/blob/master/templates/common/_base/units/ovs-configuration.service.yaml
[2] https://github.com/openshift/machine-config-operator/blob/master/templates/common/_base/files/configure-ovs-network.yaml
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: RHEL-35885
Note: the fixes for RHEL-35885 is in a hurry without patch merge
in upstream, so the final upstream patch may be different than
this downstream one. Be careful here if conflicts happen for later
upstream patch backport.
Signed-off-by: Tao Liu <ltao@redhat.com>
Resolves: RHEL-35885
commit 9252d6b1b492016aa11a73340f286822e6d545f2
Author: Colin Walters <walters@verbum.org>
Date: Fri Jul 19 11:44:09 2024 -0400
lib: Ensure we don't find bind mounts for device target
There's comment here that `--source` somehow avoids bind
mounts, but that appears not to be the case in my
testing. I think we just happened to be lucky before
now with the `--first` picking the value we wanted.
Instead of using `--first` and hoping for the best,
parse the mounts and skip ones which are bind mounts
explicitly.
Signed-off-by: Colin Walters <walters@verbum.org>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-35885
commit 42cdc05a8c99a2c0834377faca04b583404cb86f
Author: Colin Walters <walters@verbum.org>
Date: Fri Jul 19 14:23:39 2024 -0400
dracut: Disable ostree-prepare-root
In some images such as the recent fedora/rhel bootc base image,
the ostree dracut module is statically enabled:
40df0eb382/tier-0/initramfs.yaml (L9)
And also recently, we changed the ostree systemd unit
to enter emergency.target if it fails in:
05b3b66275
These two things combine mean we'll fail before kdump gets
a chance to run.
For our use case we don't need ostree in the initrd.
I tried to override this with `--omit=ostree` in our dracut
invocation, but that causes an error (dracut doesn't let the
cmdline override static config).
For now, let's just mask the service in our initrd.
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-46777
commit 2f21fa2acfac9f6e19e071330f917e60aafc4600
Author: Philipp Rudo <prudo@redhat.com>
Date: Mon Jun 24 17:34:35 2024 +0200
kdump-lib: Drop 'file' dependency in is_uki
The 'file' utility is no longer installed per default. In addition there
was an update to it so it now reports the file type as
application/vnd.microsoft.portable-executable. Thus fall back to use
objdump to avoid adding yet an other dependency for kdump-utils and deal
with different versions of 'file'.
Note: This has the small drawback that objdump is arch specific. I.e.
examining a aarch64 UKI on a x86_64 machine will return an 'file format
not recognized' error.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Resolves: RHEL-42442
Resolves: RHEL-22171
commit 2c741555d9749e9a137378332e561382f9e25739
Author: Philipp Rudo <prudo@redhat.com>
Date: Mon Jul 1 12:52:39 2024 +0200
kdumpctl.8: Add description to reset-crashkernel --reboot
There is no description for parameter --reboot for reset-crashkernel.
Thus add one.
Suggested-by: Lichen Liu <lichliu@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Resolves: RHEL-42442
Resolves: RHEL-22171
Upstream: RHEL-only
This bug was fixed upstream in 574f8f5 ("kdumpctl: Simplify fadump
handling in reset_crashkernel"). Backporting this commit to RHEL9 would
require also to backport other commits that would change the behavior of
reset-crashkernel, e.g. no longer setting the default kernel command
line in the grub config. These changes are too invasive for RHEL9. Thus
go with a minimalistic RHEL-only fix.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Resolves: RHEL-39494
Conflicts: Small difference in context of 2nd hunk.
commit 3028529915d3026e62b59d8f3faadddd410baa75
Author: Philipp Rudo <prudo@redhat.com>
Date: Fri Jun 14 11:48:24 2024 +0200
kdumpctl: Drop default kexec '-d' option
Kernel commits cbc2fe9d9cb2 ("kexec_file: add kexec_file flag to control
debug printing") and a85ee18c7900 ("kexec_file: print out debugging
message if required") added debug messages to the kexec_file_load system
call when option -d is provided to the kexec user space tool. As
kexec_file_load is the default and option -d is set by default these
messages are always printed when a crash kernel is loaded. This not only
clutters the kernel log but also potentially leaks confidential kernel
information to users. As the messages are printed to the kernel log, not
stderr, the redirection to /var/log/kdump.log won't catch them. This
will become even more problematic as for RHEL10 the kernel will be built
without support for the kexec_load system call. So kexec_file_load will
be the only choice in the future.
The redirection also caused confusion in a recent bug report. There a
user moved a working /etc/sysconfig/kdump from ppc to s390 with
KEXEC_ARGS containing the --dt-no-old-root option. This option is arch
specific and does not exist on s390. Thus the kexec-tools failed with an
'unrecognized option' error followed by the usage(). The problem was
that the 'unrecognized option' error is printed to stderr, which got
redirected to /var/log/kdump.log, while the usage() is printed to
stdout, which ended up in the systemd journal. This caused confusion as
the user only checked the journal and found the usage() without any
error message.
Thus remove the default -d option and the redirection of stderr to
/var/log/kdump.log for the kexec-tools user space tool.
This commit ultimately reverts 88a8b94 ("kdumpctl: add the '-d' option to
enable the kexec loading debugging messages").
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-43581
Upstream: Fedora
Conflict: Applied by manual
commit 44a1b7da908a52c15a2b7ed286b59cfe7319b4c9
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date: Wed Feb 28 22:51:15 2024 +0530
ppc64le: replace kernel cmdline maxcpu=1 with nr_cpus=1
With patch series [1], PowerPC supports nr_cpus=1,
so use nr_cpus=1 instead of maxcpu=1 in the kdump environment.
Note this changes is dependent on kernel changes [1]
[1] https://lore.kernel.org/all/170800202447.601034.7290612623478478380.b4-ty@ellerman.id.au/#t
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Acked-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Upstream: fedora
Resolves: RHEL-3929
Conflict: Yes, for fedora there is no kdump.sysconfig.x86_64,
but gen-kdump-sysconfig.sh. So for backporting, the
modification is made on kdump.sysconfig.x86_64.
commit ada6f5edf1ae06fc88759aa2f94d09e2a98d21ef
Author: Tao Liu <ltao@redhat.com>
Date: Wed May 1 16:53:19 2024 +0800
sysconfig: add pcie_ports compat to KDUMP_COMMANDLINE_APPEND on x86_64
There have been some of failing cases of kdump in 2nd kernel, where
ususally only one cpu is enabled by "nr_cpus=1", but with a large
number of devices, which may easily exceed the maximum IRQ resources of
one cpu can handle. As a result, the 2nd kernel will hang and kdump
fails. This issue is often observed on machines with many cpus and many
devices.
On those systems, pcieports consume quite proportion of IRQ resources,
many following message can be seen in dmesg log:
pcieport 0000:18:01.0: PME: Signaling with IRQ 109
According to kernel doc[1], when "pcie_ports=compat" applied, it will disable
native PCIe services (PME, AER, DPC, PCIe hotplug). Those functions are
power management events, error reporting, performance, hotplug related,
which are not the must-have functions for kdump. In addition, after
testing, no side effects such as cannot writing vmcore into sdx, nvme
etc been noticed.
This patch will disable native PCIe services for 2nd kernel, to saving the
scarce IRQ resources and increase the kdump success.
Attach Prarit's comments:
This makes sense to me. The only concern anyone should have is that a PCIE
error could have been responsible for taking down the kernel in the first
place, and booting into the second kernel could then also have a fatal
problem. I'm not sure we can ever fix that type of cascade of panics :)
so it makes sense to disable these features.
[1]: https://www.kernel.org/doc/html/v6.9-rc1/admin-guide/kernel-parameters.html
Signed-off-by: Tao Liu <ltao@redhat.com>
Acked-by: Prarit Bhargava <prarit@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-35811
Conflict: None
Upstream Status: git@github.com:rhkdump/kdump-utils.git
commit 247c7a5f39b305f9a83bad2d936d00237165b7e0
Author: Mamoru Nishibe (Fujitsu) <nishibe.mamoru@fujitsu.com>
Date: Wed Apr 24 08:11:12 2024 +0000
mkdumprd: Fix makedumpfile parameter check.
If only "makedumpfile" is written in "core_collector" of /etc/kdump.conf
and try to run makedumpfile without options,
"makedumpfile --check-params" fails and terminates abnormally.
# grep ^core_collector /etc/kdump.conf
core_collector makedumpfile
# /usr/bin/kdumpctl start
:
Commandline parameter is invalid.
Try `makedumpfile --help' for more information.
kdump: makedumpfile parameter check failed.
kdump: mkdumprd: failed to make kdump initrd
kdump: Starting kdump: [FAILED]
On the other hand, "makedumpfile --check-params" works fine without any options.
# makedumpfile --check-params vmcore dumpfile
# echo $?
0
In addition, before verify_core_collector() was implemented,
initial RAM for kdump was successfully created using only "core_collector makedumpfile".
I consider it a regression.
This is due to a parameter extraction error in verify_core_collector().
Fix it to correctly extract only the options as follows.
Fixes: a1c28126 ("mkdumprd: Use makedumpfile --check-params option")
Signed-off-by: Mamoru Nishibe <nishibe.mamoru@fujitsu.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Related: https://issues.redhat.com/browse/RHEL-7028
Conflict: None
Upstream Status: git@github.com:rhkdump/kdump-utils.git
commit 7a8edc8de67dccae23b01461bc3b17c0ad42aa5f
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Sep 27 09:31:39 2023 +0800
Install the driver of physical device for a SR-IOV virtual device
Currently, network dumping failed over a NIC that is a Single Root I/O
Virtualization (SR-IOV) virtual device. Usually the driver of the
virtual device won't specify the dependency on the driver of the
physical device. So to fix this issue, the driver of the physical device
needs to be found and installed as well.
Fixes: a65dde2d ("Reduce kdump memory consumption by only installing needed NIC drivers")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-7028
Conflict: None
Upstream Status: git@github.com:rhkdump/kdump-utils.git
commit d057153a1c3c36612a14143b29c0ff0be34e4fc2
Author: Coiby Xu <coxu@redhat.com>
Date: Thu Sep 21 11:50:14 2023 +0800
Try to install PHY and MDIO bus drivers explicitly
Resolves: https://issues.redhat.com/browse/RHEL-7028
Currently, nfs dumping fails on some machines that has a dedicated PHY
driver (dealing with the physical layer) or MDIO bus (connecting the MAC
to PHY devices) driver. This is because kexec-tools doesn't install
dedicated PHY or MDIO driver explicitly. Usually a NIC driver shouldn't
specify the dependency on the needed PHY or MDIO driver because it
shouldn't a NIC (medium access control, MAC) driver is for dealing with
the Data link layer and a PHY driver is for physical layer. So as long
as a MAC driver can talk to the PHY layer via APIs, it shouldn't care
which PHY driver or device it's talking to. So when the
dependency on a PHY driver or MDIO driver is not found by dracut's
instmods, the PHY or MDIO driver won't be installed.
This patch passes =drivers/net/phy and =drivers/net/mdio to dracut's
instmods which will only install in-use PHY or MDIO driver(s).
Note ideally we should find out which PHY driver is used by a NIC but
unfortunately currently no universal way can be found
(/sys/class/net/NIC_NAME/phydev/driver/module can be used to find the
name of the PHY driver for some NICs but it doesn't exist for some NICs
like Qualcomm Atheros AR8031). So is it for a MDIO bus driver.
Fortunately currently no huge memory consumption is found for a PHY or
MDIO driver.
Fixes: a65dde2d ("Reduce kdump memory consumption by only installing needed NIC drivers")
Reported-by: Doreen Alongi <dalongi@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-35640
Upstream Status: git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
Conflict: None
commit 9d9cf8de8b2ad8273861a30476a46f34cd34871a
Author: Baoquan He <bhe@redhat.com>
Date: Tue Nov 14 23:20:30 2023 +0800
kexec_file: add kexec_file flag to support debug printing
This add KEXEC_FILE_DEBUG to kexec_file_flags so that it can be passed
to kernel when '-d' is added with kexec_file_load interface. With that
flag enabled, kernel can enable the debugging message printing.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@kernel.org>
Signed-off-by: Baoquan He <bhe@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-13996
Upstream: Fedora
Conflict: None
commit 468336700d
Author: Lichen Liu <lichliu@redhat.com>
Date: Mon Jan 22 15:59:09 2024 +0800
dracut-module-setup: Skip initrd-cleanup and initrd-parse-etc in kdump
When using multipath devices as the target for kdump, if user_friendly_name
is also specified, devices default to names like "mpath*", e.g., mpatha.
In dracut, we obtain a persistent device name via get_persistent_dev. However,
dracut currently believes using /dev/mapper/mpath* could cause issues, thus
alternatively names are used, here it's /dev/disk/by-uuid/<FS_UUID>.
During the kdump boot progress, the /dev/disk/by-uuid/<FS_UUID> will exist as
soon as one of the path devices exists, but it won't be usable by systemd,
since multipathd will claim that device as a path device. Then multipathd will
get stopped before it can create the multipath device.
Without user_friendly_name, /dev/mapper/<WWID> is considered a persistent
device name, avoiding the issue.
The exit of multipathd is due to two dependencies in the current dracut module
90multipath/multipathd.service, "Before=initrd-cleanup.service" and
"Conflicts=initrd-cleanup.service".
As per man 5 systemd.unit, if A.service has "Conflicts=B.service", starting
B.service will stop A.service.
This is useful during normal boot. However, we will never switch-root after
capturing vmcore in kdump.
We need to ensure that multipathd is not killed due to such dependency issue.
Without modifying multipathd.service, we add ConditionPathExists=!/proc/vmcore
to skip initrd-cleanup.service in kdump. This approach is beneficial as
it avoid the potential termination of other services that conflict with
initrd-cleanup.service. Also skip initrd-parse-etc.service as it will try to
start initrd-cleanup.service. Both of these services are used for switch root,
so they can be safely skipped in kdump.
Suggested-by: Benjamin Marzinski <bmarzins@redhat.com>
Suggested-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-17451
Upstream: Fedora
Conflict: None
commit c752cbb2d3
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Dec 6 16:15:50 2023 +0800
Explain the auto_reset_crashkernel option in more details
Resolves: https://issues.redhat.com/browse/RHEL-17451
Explain what factors affect the default crashkernel value and ask users
to reset it manually if needed.
Cc: Baoquan He <bhe@redhat.com>
Cc: Jie Li <jieli@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-11897
Upstream: Fedora
Conflict: None
commit 38d9990389
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Dec 26 11:17:29 2023 +0800
Use the same /etc/resolve.conf in kdump initrd if it's managed manually
Resolves: https://issues.redhat.com/browse/RHEL-11897
Previously fix 0177e248 ("Use the same /etc/resolve.conf in kdump initrd
if it's managed manually") is problematic,
1) it generated .conf file unrecognized by NetowrkManager ;
2) this .conf file was installed to current file system instead of to the kdump initrd;
3) this incorrect .conf file prevented the starting of NetworkManager.
This patch fixes the above issues and also suppresses a harmless warning
when systemd-resolved.service doesn't exist,
# systemctl -q is-enabled systemd-resolved
Failed to get unit file state for systemd-resolved.service: No such file or directory
Fixes: 0177e248 ("Use the same /etc/resolve.conf in kdump initrd if it's managed manually")
Reported-by: Jie Li <jieli@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-10484
Upstream: Fedora
Conflict: Missing upstream patch d4e8772("kdumpctl: make do_estimate more
robust")
commit 741861164e
Author: Lichen Liu <lichliu@redhat.com>
Date: Mon Oct 30 14:51:59 2023 +0800
kdumpctl: Only returns immediately after an error occurs in check_*_modified
Currently is_system_modified will return immediately when check_*_modified
return a non-zero value, and the remaining checks will not be executed.
For example, if there is a fs-related error exists, and someone changes the
kdump.conf, check_files_modified will return 1 and is_system_modified will
return 1 immediately. This will cause kdumpctl to skip check_fs/drivers_modified,
kdump.service will rebuild the initrd and start successfully, however, any
errors should prevent kdump.service from starting.
This patch will cause check_*_modifed to continue running until an error occurs
or all execution ends.
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Acked-by: Tao Liu <ltao@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-8727
Resolves: https://issues.redhat.com/browse/RHEL-8710
Upstream: Fedora
Conflict: The 1st hunk is merged manualy because of conflict caused
by context.
commit 4841bc6a6d
Author: Baoquan He <bhe@redhat.com>
Date: Thu Sep 21 18:01:02 2023 +0800
kdump-lib.sh: add extra 64M to default crashkernel if sme/sev is active
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>
Signed-off-by: Baoquan He <bhe@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-8727
Resolves: https://issues.redhat.com/browse/RHEL-8710
Upstream: Fedora
Conflict: spec/kdump-lib_spec.sh doesn't exist in RHEL, so I remove
the hunk directly.
commit 64f2827a4b
Author: Philipp Rudo <prudo@redhat.com>
Date: Wed Sep 6 10:49:47 2023 +0200
kdump-lib: Harden _crashkernel_add
_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>
Signed-off-by: Baoquan He <bhe@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-14003
Upstream: Fedora
Conflict: None
commit 4fa17b2ee4
Author: Nayna Jain <nayna@linux.ibm.com>
Date: Tue Oct 3 23:41:47 2023 -0400
powerpc: update kdumpctl to load kernel signing key for fadump
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>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-14003
Upstream: Fedora
Conflict: None
commit fe6eb30e67
Author: Nayna Jain <nayna@linux.ibm.com>
Date: Tue Oct 3 23:41:46 2023 -0400
powerpc: update kdumpctl to remove deletion of kernel signing key once loaded
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>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: RHEL-14000
Upstream: https://github.com/horms/kexec-tools
Conflict: None
commit bd0200c47c45dd420244b39ddabcecdab1fb9a8e
Author: Hari Bathini <hbathini@linux.ibm.com>
Date: Wed Sep 20 17:29:27 2023 +0530
kexec: update manpage with explicit mention of clean kexec
While the manpage does mention about kexec boot with a clean shutdown,
it is not explicit about it. Make it explicit.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Simon Horman <horms@kernel.org>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2232499
Upstream: Fedora Rawhide
Conflict: None
commit 4b7b7736ee
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date: Wed Aug 2 20:36:48 2023 +0530
Introduce a function to get reserved memory size
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>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2232499
Upstream: Fedora Rawhide
Conflict: Some newer patches has been rebased, which caused git am to
encounter some problems.
commit fc7c65312a
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date: Thu Aug 17 16:38:35 2023 +0530
powerpc: update fadump sysfs node path
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>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
