Commit Graph

1717 Commits

Author SHA1 Message Date
Lichen Liu
ab539cd801
makedumpfile: remove explicit-lib-dependency zlib
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>
2024-04-29 10:35:57 +08:00
Lichen Liu
f46074e711
kexec-tools: use make_install
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>
2024-04-29 10:27:12 +08:00
Lichen Liu
ace7b80a5b
Fix potential-bashisms in monitor_dd_progress
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>
2024-04-29 10:26:51 +08:00
Lichen Liu
612b6d7395
Upstream kdump-utils
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>
2024-04-29 10:25:49 +08:00
Lichen Liu
c3db42361b
Supported targets: Merge hypervisor sections
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>
2024-04-29 10:24:58 +08:00
Lichen Liu
fc4e80cba7
Supported targets: Import from CentOS Stream 9
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>
2024-04-29 10:24:23 +08:00
Lichen Liu
b722e4bda8
Add URL for kexec-tools and kump-utils
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None

commit 3fa5df9a684f63e9aa5b42a4c9de538d3be457ed
Author: Coiby Xu <coxu@redhat.com>
Date:   Mon Apr 8 13:17:23 2024 +0800

    Add URL for kexec-tools and kump-utils

    Suggested-by: Dave Young <dyoung@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>
2024-04-29 10:06:17 +08:00
Lichen Liu
61137b101b
makedumpfile: re-use source Makefile's install logic
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None

commit f7bd239656269ea777454fe6c541aa0decaa4545
Author: Coiby Xu <coxu@redhat.com>
Date:   Tue Apr 9 07:26:13 2024 +0800

    makedumpfile: re-use source Makefile's install logic

    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>
2024-04-29 10:06:02 +08:00
Lichen Liu
b2d9f8e184
Remove unused scriptlets
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None

commit a442b4e51222114cbed354f298fce8f37c88cc75
Author: Coiby Xu <coxu@redhat.com>
Date:   Tue Mar 26 19:08:00 2024 +0800

    Remove unused scriptlets

    Suggested-by: Philipp Rudo <prudo@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>
2024-04-29 10:05:40 +08:00
Lichen Liu
82390462df
Don't disrupt current kdump users
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>
2024-04-29 10:05:23 +08:00
Lichen Liu
87c1eb4bc4
Don't systemctl preset kdump when updating kexec-tools to kdump-utils
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>
2024-04-29 10:05:09 +08:00
Lichen Liu
63441edc2d
Add kdump-utils subpackage
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None

commit 372b4c6c1597c3d9aaddda2d691260474973989e
Author: Coiby Xu <coxu@redhat.com>
Date:   Thu Feb 29 10:23:51 2024 +0800

    Add kdump-utils subpackage

    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>
2024-04-29 10:04:55 +08:00
Lichen Liu
27964382f6
Release 2.0.26-7
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None

commit 20dc67f0ea5bd73289be99666cf0871c5ad7a6e6
Author: Coiby Xu <coxu@redhat.com>
Date:   Sun Apr 7 14:49:11 2024 +0800

    Release 2.0.26-7

    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2269991

    Signed-off-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2024-04-29 10:04:27 +08:00
Lichen Liu
06bb5a10de
Release 2.0.28-6
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None

commit f9986edd25e8b414b2fc7f11f08d6d8f51a9b843
Author: Coiby Xu <coxu@redhat.com>
Date:   Sat Mar 16 10:22:54 2024 +0800

    Release 2.0.28-6

    Resovles: https://bugzilla.redhat.com/show_bug.cgi?id=2269640

    Let kexec-tools depends on makedumpfile.

    Signed-off-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2024-04-29 09:56:57 +08:00
Lichen Liu
73a0832b36
Add a makedumpfile subpackage
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None

commit ec3bccdf326881decd13f0ac7b4558f4a22875bd
Author: Carl George <carlwgeorge@fedoraproject.org>
Date:   Fri Feb 23 16:32:28 2024 -0600

    Add a makedumpfile subpackage

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2024-04-29 09:41:34 +08:00
Tao Liu
c2975fc921 Add gating.yaml to RHEL-10 kexec-tools
Signed-off-by: Tao Liu <ltao@redhat.com>
2024-04-22 17:12:25 +08:00
Coiby Xu
4eec72b56b 2.0.28 upstream release
Upstream tag: v2.0.28
Upstream commit: 328de8e0

Signed-off-by: Coiby Xu <coxu@redhat.com>
2024-02-02 20:13:00 +08:00
Kairui Song
2974fa3f26 kdump-dep-generator: source kdump-lib-initramfs.sh instead
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>
2024-01-31 14:38:49 +08:00
Coiby Xu
97b3b962a9 Get rid of "grep: warning: stray \ before /"
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>
2024-01-31 14:38:49 +08:00
Fedora Release Engineering
95f086ca9f Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild 2024-01-24 23:55:58 +00:00
Lichen Liu
468336700d 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>
2024-01-24 15:13:31 +08:00
Lichen Liu
6943de2cdc Print error msg when forget to specify user for ssh target
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>
2024-01-24 15:13:31 +08:00
Fedora Release Engineering
753e5060d7 Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild 2024-01-21 00:15:51 +00:00
Coiby Xu
d78cab14bc 2.0.28 upstream release
Upstream tag: v2.0.28
Upstream commit: adef8a8e

Signed-off-by: Coiby Xu <coxu@redhat.com>
2024-01-17 13:51:27 +08:00
Steffen Maier
73c9eb71e9 dracut-module-setup: remove old s390 network device config (#1937048)
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>
2024-01-17 11:59:58 +08:00
Steffen Maier
0d90d580b4 dracut-module-setup: consolidate s390 network device config (#1937048)
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>
2024-01-17 11:59:58 +08:00
Coiby Xu
38d9990389 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>
2023-12-26 12:44:14 +08:00
Coiby Xu
c752cbb2d3 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>
2023-12-20 18:29:41 +08:00
Coiby Xu
00d40c448b Release 2.0.27-5
Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-12-11 18:17:57 +08:00
Coiby Xu
bc31f6dd0f Let %post scriptlet always exits with the zero exit status
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>
2023-12-11 18:16:30 +08:00
Coiby Xu
0177e24832 Use the same /etc/resolve.conf in kdump initrd if it's managed manually
Resolves: https://issues.redhat.com/browse/RHEL-11897

Some users may choose to manage /etc/resolve.conf manually [1]
by setting dns=none or use a symbolic link resolve.conf [2].
In this case, network dumping will not work because DNS resolution
fails. Use the same /etc/resolve.conf in kdump initrd to fix this
problem.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=690404
[2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/manually-configuring-the-etc-resolv-conf-file_configuring-and-managing-networking

Fixes: 63c3805c ("Set up kdump network by directly copying NM connection profile to initrd")
Reported-by: Curtis Taylor <cutaylor@redhat.com>
Cc: Jie Li <jieli@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
2023-11-24 15:44:02 +08:00
Lichen Liu
741861164e 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>
2023-11-16 13:18:35 +08:00
Coiby Xu
cb761c7224 Release 2.0.27-4
Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-11-08 11:28:28 +08:00
Baoquan He
4841bc6a6d 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>
2023-11-08 09:42:31 +08:00
Coiby Xu
3d253ab811 Allow _crashkernel_add to address larger memory ranges
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>
2023-11-08 09:42:31 +08:00
Coiby Xu
c9ac933cc2 Release 2.0.27-3
Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-10-17 13:54:48 +08:00
Coiby Xu
0ffce0ef4e Only try to reset crashkernel when kdump.service is enabled
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>
2023-10-17 13:45:30 +08:00
Coiby Xu
5058cef90c Release 2.0.27-2
This release fixes https://datawarehouse.cki-project.org/kcidb/tests/9435999.

Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-10-13 11:00:07 +08:00
Coiby Xu
7af94019cf [packit] 2.0.27 upstream release
Upstream tag: v2.0.27
Upstream commit: 2495ccfc
2023-10-10 15:58:01 +08:00
Nayna Jain
4fa17b2ee4 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>
2023-10-10 08:42:01 +08:00
Nayna Jain
fe6eb30e67 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>
2023-10-10 08:42:01 +08:00
Coiby Xu
8bf11dc3f6 unit tests: fix test failures "The param /boot/boot/vmlinuz-xxx is incorrect"
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>
2023-10-10 08:40:26 +08:00
Philipp Rudo
2f52973feb unit tests: Fix parse_config test case
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>
2023-09-14 15:01:52 +08:00
Philipp Rudo
00c37d8c2c spec: Drop special handling for IA64 machines
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>
2023-09-14 15:01:52 +08:00
Philipp Rudo
64f2827a4b 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>
2023-09-14 15:01:52 +08:00
Philipp Rudo
d89459c5ec spec: Silence unversioned Obsolete warning
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>
2023-09-14 15:01:52 +08:00
Philipp Rudo
8e0b3598c1 spec: Clean up handling of dracut files
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>
2023-09-14 15:01:52 +08:00
Philipp Rudo
755ba199a7 kdump.conf: Remove option override_resettable
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>
2023-09-14 15:01:52 +08:00
Philipp Rudo
8175924e89 kdumpctl: Stop updating grub config in reset_crashkernel
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>
2023-09-14 15:01:52 +08:00
Philipp Rudo
099434b993 kdumpctl: Prevent option --fadump on non-PPC in reset_crashkernel
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>
2023-09-14 15:01:52 +08:00