With the introduction of kernel commit c6c5b14dac0d ("powerpc: make fadump
resilient with memory add/remove events") linux kernel now internally manages
the update of elfcorehdr during memory add/remove events. So no need to
re-register fadump if the /sys/kernel/fadump/hotplug_ready is set to 1.
No impact for kernels that do not have /sys/kernel/fadump/hotplug_ready
sysfs.
Relevant kernel commit links:
1. https://msgid.link/20240422195932.1583833-2-sourabhjain@linux.ibm.com
2. https://msgid.link/20240422195932.1583833-3-sourabhjain@linux.ibm.com
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
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>
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>
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>
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>
There is a bug report for RHEL10 about a grep error reading
grep: /var/tmp/dracut.DiZuKp/initramfs/etc/systemd/system.conf*: No such file or directory
that shows up when rebuilding the initrd. This is caused by systemd
v255 that allows installing the default systemd config files to
/usr/lib/systemd instead of /etc/systemd [1][2] which is done for RHEL.
So unless a user manually adds /etc/systemd/system.conf the file no
longer exists.
However the test that requires the call to grep is somewhat wonky. IIUC
the test is there so we don't overwrite a setting the user might have
made. In my opinion this only makes sense as long as the timeout set is
larger than what we would set. But this part of the logic is missing.
So fix the error message by removing the test and add our config
unconditionally.
While at it rename the created drop-ins to 99-kdump.conf to follow
the recommended naming convention and to make sure that our value takes
precedence.
Note: In case the test is still needed we can fall back to use
'systemd-analyse cat-config' that automatically considers all potential
locations for the config and its drop-ins.
[1] 6495361c7d ("meson: add build option for install path of main config files")
[2] 6378f257e7 ("various: use new config loader instead of config_parse_config_file()")
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Fix the following error found by rpmlint,
makedumpfile.x86_64: E: explicit-lib-dependency zlib
You must let rpm find the library dependencies by itself. Do not put unneeded
explicit Requires: tags.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
man files doesn't preserve line breaks. Construct a list to list the
cases where additional memory will be reserved.
Fixes: c752cbb2 ("Explain the auto_reset_crashkernel option in more details")
Reported-by: Jie Li <jieli@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Currently, the other options like "raw <partition>" become child items
of the auto_reset_crashkernel option,
auto_reset_crashkernel <yes|no>
...
raw <partition>
...
nfs <nfs mount>
...
...
Fix it by ending the auto_reset_crashkernel with ".RE".
Fixes: 73ced7f4 ("introduce the auto_reset_crashkernel option to kdump.conf")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None
commit b3620b0dbc3e0fb9a92ab5faf34ac3b4e7bb7bd9
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Apr 9 09:25:48 2024 +0800
makedumpfile: remove explicit-lib-dependency zlib
Fix the following error found by rpmlint,
makedumpfile.x86_64: E: explicit-lib-dependency zlib
You must let rpm find the library dependencies by itself. Do not put unneeded
explicit Requires: tags.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None
commit 2ed88633ade0f1e5523d8097d96df3fde1287ea7
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Apr 9 09:04:11 2024 +0800
kexec-tools: use make_install
use consistent build flags %make_install to have the benefits like
enabling parallel building automatically.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None
commit a5c17afe7e871f7a2593d04b97e8e77fb434642c
Author: Coiby Xu <coxu@redhat.com>
Date: Fri Jan 12 20:00:53 2024 +0800
Fix potential-bashisms in monitor_dd_progress
As suggested by Carl [1],
> /usr/lib/dracut/modules.d/99kdumpbase/monitor_dd_progress has some
> inconsistencies with other scripts in that directory. It is missing the
> .sh extension and is not executable. The latter is resulting in an
> rpmlint error.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2239566#c2
Suggested-by: Carl George <carl@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None
commit fe372afddde500249cd02fc3f152a164cfed321f
Author: Coiby Xu <coxu@redhat.com>
Date: Fri Mar 1 17:37:24 2024 +0800
Upstream kdump-utils
This patch upstreams the to-be-split-out kdump-utils to
https://github.com/rhkdump/kdump-utils. And it also simplify the .spec
file by putting the installation logic into a Makefile.
Cc: Philipp Rudo <prudo@redhat.com>
Cc: Carl George <carl@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None
commit d2b6547f55ca960463de6dca6791db3c7d10ec06
Author: Philipp Rudo <prudo@redhat.com>
Date: Thu Feb 8 17:06:12 2024 +0100
Supported targets: Merge hypervisor sections
The supported targets list has two separate hypervisor sections. Merge
them into one.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None
commit b6a066db5368d53a5e460ca1c948c0b43d66b1ef
Author: Philipp Rudo <prudo@redhat.com>
Date: Thu Feb 8 17:06:11 2024 +0100
Supported targets: Import from CentOS Stream 9
In CentOS Stream a list of supported targets is maintained. Where
"supported" means that these targets are tested regularly. Even though
there are some small differences between CentOS Stream and Fedora when
it comes to provided/supported packages and kernel configs, having this
list in Fedora as well makes sense. As it provides a entry point for
users to find out if a given setup is meant to work or not. Thus include
the supported-kdump-targets.txt from CentOS Stream 9 [1] into Fedora.
[1] 0a09d12d89/supported-kdump-targets.txt
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None
commit c7683d8aabdbbbaaefdeee4a3e6c35482dca48c7
Author: Coiby Xu <coxu@redhat.com>
Date: Thu Feb 29 11:18:00 2024 +0800
Don't disrupt current kdump users
Majority of current kexec-tools users have installed kexec-tools out of
the need for the kdump feature. To ensure a smooth transition, add
kdump-utils as weak dependency. If users only want to use kexec-tools,
they can uninstall kdump-utils.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Suggested-by: Carl George <carl@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None
commit 5fe098fec8eb19a942a608f19324601066c0467d
Author: Coiby Xu <coxu@redhat.com>
Date: Thu Feb 29 11:05:14 2024 +0800
Don't systemctl preset kdump when updating kexec-tools to kdump-utils
When an old version of kexec-tools gets replaced by kdump-utils,
"%systemd_post" will be executed in the post scriptlet which has the
purpose to "systemctl preset kdump" for freshly installed kexec-tools.
But in the case of kdump-utils replacing kexec-tools, it is not needed
so skip this case.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Suggested-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Currently kdump-dep-generator will source kdump-lib.sh. Notice
kdump-dep-generator have #!/bin/sh so it should be POSIX, but
kdump-lib.sh is a non-POSIX bash script. When Bash is configured to run
in POSIX mode for #!/bin/sh scripts, it will fail with:
/usr/lib/kdump/kdump-lib.sh: line 1042: syntax error near unexpected token `<'
/usr/lib/kdump/kdump-lib.sh: line 1042: ` done < <( _crashkernel_parse "$ck")'
This subshell call is easy to convert into a pipe but we should just
source kdump-lib-initramfs.sh here, the only thing kdump-dep-generator
needs is is_ssh_dump_target which is in kdump-lib-initramfs.sh, also
prevents further POSIX violations.
Signed-off-by: Kairui Song <kasong@tencent.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2242185
grep (3.8) warnings when running the unit tests or running
"kdumpctl reset-crashkernel" on >= F39,
# unit tests
Examples:
1) kdumpctl _find_kernel_path_by_release() returns the kernel path for the given release
When call _find_kernel_path_by_release vmlinuz-6.2.11-200.fc37.x86_64
1.1) WARNING: There was output to stderr but not found expectation
stderr: grep: warning: stray \ before /
# spec/kdumpctl_general_spec.sh:169-172
# kdumpctl reset-crashkernel
grep: warning: stray \ before /
kdump: Updated crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M for kernel=/boot/vmlinuz-6.6.8-200.fc39.x86_64. Please reboot the system for the change to take effect.
This warning can be reproduced by
echo 'kernel="/boot/vmlinuz-6.4.6-200.fc38.x86_64"' | grep -E "^kernel=.*$_release(\/\w+)?\"$"
This patch removes unneeded backslash. It also adds a test for
systemd-boot path. And for simplification, Parameters:dynamic is now
used to generate test data dynamically.
Fixes: 8af05dc4 ("kdumpctl: Add support for systemd-boot paths")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
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>
Resolves: https://issues.redhat.com/browse/FC-1046
We require that <user> be explicitly specified in 'ssh <user>@<hostname>'. When
forgetting to specify, such as 'ssh 192.168.10.2', a useful error log should be
printed instead of exiting directly.
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Since the previous commit reworks znet configuration to be based on the
active system configuration, there is no dependency on any existing
persistent configuration any more. Hence the old code handling systems with
exactly one s390-specific nmconnection as persistent configuration can be
removed.
Migration of the old persistent device configuration mechanism with
nmconnections (or ifcfg) to zdev is handled independently in s390utils.
[https://github.com/steffen-maier/s390utils/pull/1/commits
("znet: migrate to consolidated persistent device config with zdev
(#1937046,#1937048))"]
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
This is a preparation for consolidating s390 network device config with
https://github.com/dracutdevs/dracut/pull/2534
("feat(znet): use zdev for consolidated device configuration")
https://github.com/steffen-maier/s390utils/pull/1/commits
("znet: migrate to consolidated persistent device config with zdev
(#1937046,#1937048))"
("znet: clean up old deprecated persistent device config
(#1937046,#1937048)").
With above consolidation, s390-specific low-level configuration information
will no longer be in NetworkManager connections (nor ifcfg files), but in
the persistent configuration database of chzdev from s390-tools.
Since the kdump dracut module here depends on the "znet" dracut module [1]
and "znet" will copy all persistent configuration into initrd as of above
commit, all s390-specific information would already be in the kdump initrd.
[1] 08de712528 ("Move some dracut module dependencies checks to
module-setup.sh"), 7148c0a30d ("add s390x netdev setup")
However, it is more appropriate and also removes the copy dependency from
"znet" to introduce the consolidated zdev mechanism for importing just the
required network device config from the current active system
configuration. It does not depend on any of the pull requests above.
It does not depend on any existing persistent configuration
and can replace the old function code. This is similar to dracut block
device dependency handling in s390-tools zdev/dracut/95zdev-kdump.
The old code only seems to work if there is exactly one s390-specific
nmconnection (or ifcfg file). Related commits:
b5577c163a ("Simplify setup_znet by copying connection profile to initrd"),
7d47251568 ("Iterate /sys/bus/ccwgroup/devices to tell if we should set up rd.znet"),
8b08b4f17b ("Set up s390 znet cmdline by "nmcli --get-values""),
ce0305d4f9 ("Add a new option 'rd.znet_ifname' in order to use it in udev rules"),
7148c0a30d ("add s390x netdev setup").
A bonding or teaming setup would have multiple following network
interfaces, each of which would need a low-level config if they're s390
channel-attached network devices. The new code should be able to handle
that by iterating the involved network interfaces. Chzdev only exports
something if it's a device type it deems itself responsible for.
Additional debugging output can be generated with e.g. dracut option
"--stdlog 5" (or short -L5). It shows the chzdev export result, the output
of chzdev export and import, and an overview of the resulting persistent
config within the initrd. On systems, which default to using dracut option
"--quiet", you might need an additional "--verbose" to counter "--quiet" so
-L5 has effect. Typically combined with "--debug" to get a shell trace from
building an initrd (Note: --debug does not increase the log levels).
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
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>
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>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2247940
Currently, CoreOS image fails to be built. This is because since commit
00c37d8c ("spec: Drop special handling for IA64 machines"), the last
command is now servicelog_notify and it fails to run in such
invocation environment. Thus the %post scriptlet returns a non-zero
exit code which breaks package installation,
Running scriptlet: kexec-tools-2.0.27-4.fc40.ppc64le
/proc/ is not mounted. This is not a supported mode of operation. Please fix your invocation environment to mount /proc/ and /sys/ properly. Proceeding anyway. Your mileage may vary.
servicelog_notify: is not supported on the Unknown platform
warning: %post(kexec-tools-2.0.27-4.fc40.ppc64le) scriptlet failed, exit status 1
Error in POSTIN scriptlet in rpm package kexec-tools
Quoting [1],
> Non-zero exit codes from scriptlets can break installs/upgrades/erases
> such that no further actions will be taken for that package in a
> transaction (see Ordering), which may for example prevent an old version
> of a package from being erased on upgrades, ...
>
> All scriptlets MUST exit with the zero exit status. Because RPM in its
> default configuration does not execute shell scriptlets with the -e
> argument to the shell, excluding explicit exit calls (frowned upon with
> a non-zero argument!), the exit status of the last command in a
> scriptlet determines its exit status...
>
> Usually the most important bit is to apply this to the last command
> executed in a scriptlet, or to add a separate command such as plain “:”
> or “exit 0” as the last one in a scriptlet.
Following the above suggestion, add a separate command ":" as the last
one to the %post scriptlet.
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
Reported-by: Colin Walters <walters@redhat.com>
Cc: Dusty Mabe <dustymabe@redhat.com>
Cc: Philipp Rudo <prudo@redhat.com>
Fixes: 00c37d8c ("spec: Drop special handling for IA64 machines")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
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>
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>
