Commit Graph

116 Commits

Author SHA1 Message Date
Pingfan Liu
cb850aec26 Simplify the management of the kernel parameter crashkernel
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676
Upstream: Fedora rawhide
Conflict: applied manually due to slight difference in context

commit 5b31b099ae
Author: Coiby Xu <coxu@redhat.com>
Date:   Wed Apr 26 04:48:25 2023 +0800

    Simplify the management of the kernel parameter crashkernel

    Currently, kexec-tools only updates the crashkernel to a new default
    value only when both two conditions are met,
     - auto_reset_crashkernel=yes in kdump.conf
     - existing kernels or current running kernel should use the old default
       value.

    To address seen corner cases, the logic to tell if the second condition
    is met becomes quite complex. Instead of making the logic more complex
    to support aarch64-64k, this patch drops the second condition to
    simplify the management of the crashkernel kernel parameter.

    Another change brought by this simplification is kexec-tools will also
    set up the kernel crashkernel parameter for a fresh install (previously
    it's limited to osbuild).

    Note
    1. This patch also stop trying to update /etc/default/grub because
       a) it only affects the static file /boot/grub2/grub.cfg
       b) grubby is recommended to change the kernel command-line parameters
          for both Fedora [1] and RHEL9 [2][3]
       c) For the cases of aarch64 and POWER, different kernels could have
          different default crashkernel value.

    2. Starting with Fedora 37,  posttrans rpm scriplet distinguish between
       package install and upgrade.

    [1] https://fedoraproject.org/wiki/GRUB_2
    [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/configuring-kernel-command-line-parameters_managing-monitoring-and-updating-the-kernel#changing-kernel-command-line-parameters-for-all-boot-entries_configuring-kernel-command-line-parameters
    [3] https://access.redhat.com/solutions/1136173

    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-15 10:30:53 +08:00
Tao Liu
2c6e1b5d4c Release 2.0.26-5
Resolves: bz2144731

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-06-02 11:22:59 +08:00
Tao Liu
8f66aa349f Release 2.0.26-4
Resovles: bz2169720
Resovles: https://issues.redhat.com/browse/RHEL-512

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-05-31 15:18:12 +08:00
Tao Liu
206f59eaa6 kdumpctl: Add basic UKI support
Resolves: bz2169720
Upstream: src.fedoraproject.org/rpms/kexec-tools.git
Conflicts: Small context difference in kexec-tools.spec

commit ea7be0608e
Author: Philipp Rudo <prudo@redhat.com>
Date:   Fri May 5 17:14:42 2023 +0200

    kdumpctl: Add basic UKI support

    A Unified Kernel Image (UKI) is a single EFI PE executable combining an
    EFI stub, a kernel image, an initrd image, and the kernel command line.
    They are defined in the Boot Loader Specification [1] as type #2
    entries. UKIs have the advantage that all code as well as meta data that
    is required to boot the system, not only the kernel image, is combined
    in a single PE file and can be signed for EFI SecureBoot. This extends
    the coverage of SecureBoot extensively.

    For RHEL support for UKI were included into kernel-ark with 16c7e3ee836e
    ("redhat: Add sub-RPM with a EFI unified kernel image for virtual
    machines").

    There are two problems with UKIs from the kdump point of view at the
    moment. First, they cannot be directly loaded via kexec_file_load and
    second, the initrd included isn't suitable for kdump. In order to enable
    kdump on systems with UKIs build the kdump initrd as usual and extract
    the kernel image before loading the crash kernel.

    [1] https://uapi-group.org/specifications/specs/boot_loader_specification/

    Signed-off-by: Philipp Rudo <prudo@redhat.com>
    Reviewed-by: Pingfan Liu <piliu@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
2023-05-31 15:11:31 +08:00
Tao Liu
c04910eebd Release 2.0.26-3
Resovles: bz2173815
Resovles: bz2078176

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-05-09 18:39:00 +08:00
Tao Liu
3762c208aa Rebase makedumpfile to v1.7.3
Resolves: bz2173815

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-05-09 18:34:18 +08:00
Tao Liu
fa20bd98e5 Release 2.0.26-2
Resovles: bz2173815
Resovles: bz2151504

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-04-21 16:14:51 +08:00
Tao Liu
2ba6f6fb2f Rebase makedumpfile to upstream latest(8e8b8814be1)
Resolves: bz2173815

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-04-21 16:03:34 +08:00
Tao Liu
f698814882 Rebase kexec-tools to v2.0.26
Resovles: bz2173814

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-04-07 16:07:26 +08:00
Tao Liu
b9a8a181ac Release 2.0.25-14
Resolves: bz2140721
Resolves: bz2177574
Resolves: bz2177674

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-03-21 16:09:11 +08:00
Tao Liu
fe7198e928 Release 2.0.25-13
Resolves: bz2174836

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-03-10 11:14:01 +08:00
Tao Liu
577dc4415a Release 2.0.25-12
Resolves: bz2168504
Related: bz2060319

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-02-24 14:06:46 +08:00
Tao Liu
a95e71e516 Release 2.0.25-11
Resolves: bz2158296

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-01-11 17:17:15 +08:00
Pingfan Liu
54d8965261 Release 2.0.25-10
Resolves: bz2151500
Resolves: bz2060319
Resolves: bz2151842
Resolves: bz2139000

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2022-12-27 15:11:50 +08:00
Coiby Xu
e120508100 Don't try to update crashkernel when bootloader is not installed
Resolves: bz2060319
Upstream: Fedora
Conflict: commit a3da46d6 ("Skip reset_crashkernel_after_update
          during package install") hasn't been backported. Note it's now
          no longer needed.

commit 5951b5e268
Author: Coiby Xu <coxu@redhat.com>
Date:   Tue Dec 20 13:59:18 2022 +0800

    Don't try to update crashkernel when bootloader is not installed

    Currently when using anaconda to install the OS, the following errors
    occur,

        INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-70.el9.x86_64 ...
        INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory
        grep: /boot/grub2/grubenv: No such file or directory
        grep: /boot/grub2/grubenv: No such file or directory
        grep: /boot/grub2/grubenv: No such file or directory
        ...
        INF packaging: Configuring (running scriptlet for): kexec-tools-2.0.23-9.el9.x86_64 ...
        INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory
        grep: /boot/grub2/grubenv: No such file or directory
        grep: /boot/grub2/grubenv: No such file or directory

    Or for s390, the following errors occur,

        INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-71.el9.s390x ...
        03:37:51,232 INF dnf.rpm: grep: /etc/zipl.conf: No such file or directory
        grep: /etc/zipl.conf: No such file or directory
        grep: /etc/zipl.conf: No such file or directory

        INF packaging: Configuring (running scriptlet for): kexec-tools-2.0.23-9_1.el9_0.s390x ...
        INF dnf.rpm: grep: /etc/zipl.conf: No such file or directory

    This is because when anaconda installs the packages, bootloader hasn't
    been installed and /boot/grub2/grubenv or /etc/zipl.conf doesn't exist.
    So don't try to update crashkernel when bootloader isn't ready to avoid
    the above errors.

    Note this is the second attempt to fix this issue. Previously a file
    /tmp/kexec_tools_package_install was created to avoid running the
    related code thus to avoid the above errors but unfortunately that
    approach has two issues a) somehow osbuild doesn't delete it for RHEL b)
    this file could still exist if users manually remove kexec-tools.

    Fixes: e218128 ("Only try to reset crashkernel for osbuild during package install")
    Reported-by: Jan Stodola <jstodola@redhat.com>
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-12-27 03:11:43 +00:00
Lichen Liu
fb93b28df8 fadump: add a kernel install hook to clean up fadump initramfs
Resolves: bz2139000
Upstream: Fedora
Conflict: Upstream doesn't have Source37: supported-kdump-targets.txt,
so the number of SourceXX need to be changed.

commit 4a2dcab26a
Author: Hari Bathini <hbathini@linux.ibm.com>
Date:   Fri Dec 2 18:46:51 2022 +0530

    fadump: add a kernel install hook to clean up fadump initramfs

    Kdump service will create fadump initramfs when needed, but it won't
    clean up the fadump initramfs on kernel uninstall. So create a kernel
    install hook to do the clean up job.

    Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2022-12-22 14:36:23 +08:00
Lichen Liu
bfe235b413 spec: only install mkfadumprd for ppc
Resolves: bz2139000
Upstream: Fedora
Conflict: None

commit 748eb3a2a6
Author: Kairui Song <kasong@tencent.com>
Date:   Sun Jan 9 18:03:35 2022 +0800

    spec: only install mkfadumprd for ppc

    fadump is a ppc only feature, mkfadumprd is only needed for fadump, drop
    it for other arch.

    Reviewed-by: Philipp Rudo <prudo@redhat.com>
    Signed-off-by: Kairui Song <kasong@tencent.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2022-12-22 14:36:23 +08:00
Tao Liu
dc26e4b45e Release 2.0.25-9
Related: bz2085347
Resolves: bz2151832

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-12-19 12:23:58 +08:00
Tao Liu
243717f988 Release 2.0.25-8
Resolves: bz2145087
Resolves: bz2141536
Resolves: bz2078460

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-12-07 16:45:25 +08:00
Coiby Xu
d88a4a1402 kexec-tools: ppc64: remove rma_top limit
Resolves: bz2145087
Conflict: None

commit 6b6187f546f0ddad8ea84d22c3f7ad72133dcfe3
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date:   Thu Sep 15 14:12:40 2022 +0530

    ppc64: remove rma_top limit

    Restricting kexec tool to allocate hole for kexec segments below 768MB
    may not be relavent now since first memory block size can be 1024MB and
    more.

    Removing rma_top restriction will give more space to find holes for
    kexec segments and existing in-place checks make sure that kexec segment
    allocation doesn't cross the first memory block because every kexec segment
    has to be within first memory block for kdump kernel to boot properly.

    Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
    Acked-by: Hari Bathini <hbathini@linux.ibm.com>
    Signed-off-by: Simon Horman <horms@kernel.org>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-12-06 11:01:48 +08:00
Pingfan Liu
aa204a3b63 kdump.conf: use a simple generator script to maintain
Resolves: bz2078460
Upstream: Fedora

commit 787b041aab
Author: Pingfan Liu <piliu@redhat.com>
Date:   Tue Nov 15 12:00:09 2022 +0800

    kdump.conf: use a simple generator script to maintain

    This commit has the same motivation as the commit 677da8a "sysconfig:
    use a simple generator script to maintain".

    At present, only the kdump.conf generated for s390x has a slight
    difference from the other arches, where the core_collector asks the
    makedumpfile to use "-c" option to compress dump data by each page using
    zlib, which is more efficient than lzo on s390x.

    Signed-off-by: Pingfan Liu <piliu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2022-12-01 11:01:17 +08:00
Tao Liu
576b8fa374 Release 2.0.25-7
Resolves: bz2076416

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-11-25 14:46:56 +08:00
Tao Liu
0459f68dcc Release 2.0.25-6
Resolves: bz2076416

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-11-24 11:27:37 +08:00
Tao Liu
812f2c967f Release 2.0.25-5
Resolves: bz2083475

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-11-11 13:25:21 +08:00
Tao Liu
cd64a1a851 Release 2.0.25-4
Resolves: bz2120914
Resolves: bz2076206
Resolves: bz2133129
Resolves: bz2060319
Resolves: bz2048690

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-11-01 11:10:13 +08:00
Tao Liu
557230d1e8 Rebase makedumpfile to 1.7.2
Resolves: bz2120914

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-11-01 11:04:23 +08:00
Coiby Xu
a9968490a2 Only try to reset crashkernel for osbuild during package install
Resolves: bz2060319
Upstream: Fedora
Conflict: None

commit e218128e28
Author: Coiby Xu <coxu@redhat.com>
Date:   Thu Sep 8 14:30:02 2022 +0800

    Only try to reset crashkernel for osbuild during package install

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

    Currently, kexec-tools tries to reset crashkernel when using anaconda to
    install the system. But grubby isn't ready and complains that,
      10:33:17,631 INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-70.el9.x86_64 1645746534 03dcd32db234b72440ee6764d59b32347c5f0cd98ac3fb55beb47214a76f33b4
      10:34:16,696 INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory
      grep: /boot/grub2/grubenv: No such file or directory

    We only need to try resetting crashkernel for osbuild. Skip it for other
    cases. To tell if it's package install instead of package upgrade, make
    use of %pre to write a file /tmp/kexec-tools-install when "$1 == 1" [1].

    [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_syntax

    Reported-by: Jan Stodola <jstodola@redhat.com>
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Lichen Liu <lichenliu@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-10-27 14:47:57 +08:00
Coiby Xu
b1b95d234b Prefix reset-crashkernel-{for-installed_kernel,after-update} with underscore
Resolves: bz2048690
Upstream: Fedora
Conflict: None

commit a7ead187a4
Author: Coiby Xu <coxu@redhat.com>
Date:   Thu Sep 8 14:08:42 2022 +0800

    Prefix reset-crashkernel-{for-installed_kernel,after-update} with underscore

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

    To indicate they are for internal use only, underscore them.

    Reported-by: rcheerla@redhat.com
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Lichen Liu <lichenliu@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-10-27 14:47:57 +08:00
Coiby Xu
a091409f10 use /run/ostree-booted to tell if scriptlet is running on OSTree system
Related: bz2048690
Upstream: Fedora
Conflict: None

commit f6bcd819fc
Author: Coiby Xu <coxu@redhat.com>
Date:   Fri Jul 15 15:11:44 2022 +0800

    use /run/ostree-booted to tell if scriptlet is running on OSTree system

    Resolves: bz2092012

    According to the ostree team [1], the existence of /run/ostree-booted
    > is the most stable way to signal/check that a system has been
    > booted in ostree-style.  It is also used by rpm-ostree at
    > compose/install time in the sandboxed environment where scriptlets run,
    > in order to signal that the package is being installed/composed into
    > an ostree commit (i.e. not directly on a live system).  See
    > 8ddf5f40d9/src/libpriv/rpmostree-scripts.cxx (L350-L353)
    > for reference.

    By checking the existence of /run/ostree-booted, we could skip trying to
    update kernel cmdline during OSTree compose time.

    [1] https://bugzilla.redhat.com/show_bug.cgi?id=2092012#c3

    Reported-by: Luca BRUNO <lucab@redhat.com>
    Suggested-by: Luca BRUNO <lucab@redhat.com>
    Fixes: 0adb0f4 ("try to reset kernel crashkernel when kexec-tools updates the default crashkernel value")
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>
    Acked-by: Timothée Ravier <siosm@fedoraproject.org>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-10-27 14:47:57 +08:00
Tao Liu
1d4de1f185 Release 2.0.25-3
Resolves: bz2085347
Resolves: bz2045949
Resolves: bz2044804

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-10-26 15:47:38 +08:00
Tao Liu
b5a9e54629 Seperate dracut and dracut-squash compressor for zstd
Upstream: fedora
Resolves: bz2045949
Resolves: bz2044804
Conflict: none

commit fc1c79ffd2
Author: Tao Liu <ltao@redhat.com>
Date:   Sat Oct 8 12:09:08 2022 +0800

    Seperate dracut and dracut-squash compressor for zstd

    Previously kexec-tools will pass "--compress zstd" to dracut. It
    will make dracut to decide whether: a) call mksquashfs to make a
    zstd format squash-root.img, b) call cmd zstd to make a initramfs.

    Since dracut(>= 057) has decoupled the compressor for dracut and
    dracut-squash, So in this patch, we will pass the compressor seperately.

    Note:

    The is_squash_available && !dracut_has_option --squash-compressor
    && !is_zsdt_command_available case is left unprocessed on purpose.

    Actually, the situation when we want to call zstd compression is:
    1) If squash function OK, we want dracut to invoke mksquashfs to make
    a zstd format squash-root.img within initramfs.
    2) If squash function is not OK, and cmd zstd presents, we want dracut
    to invoke cmd zstd to make a zstd format initramfs.

    is_zstd_command_available check can handle case 2 completely.

    However, for the is_squash_available check, it cannot handle case 1
    completely. It only checks if the kernel supports squashfs, it doesn't
    check whether the squash module has been added by dracut when making
    initramfs. In fact, in kexec-tools we are unable to do the check,
    there are multiple ways to forbit dracut to load a module, such as
    "dracut -o module" and "omit_dracutmodules in dracut.conf".

    When squash dracut module is omitted, is_squash_available check will
    still pass, so "--compress zstd" will be appended to dracut cmdline,
    and it will call cmd zstd to do the compression. However cmd zstd may
    not exist, so it fails.

    The previous "--compress zstd" is ambiguous, after the intro of
    "--squash-compressor", "--squash-compressor" only effect for
    mksquashfs and "--compress" only effect for specific cmd.

    So for the is_squash_available && !dracut_has_option
    --squash-compressor && !is_zsdt_command_available case, we just leave
    it to be handled the default way.

    Reviewed-by: Philipp Rudo <prudo@redhat.com>
    Signed-off-by: Tao Liu <ltao@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-10-26 10:16:16 +08:00
Tao Liu
8b72bcfbab Release 2.0.25-2
Resolves: bz2090534
Resolves: bz2129842

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-10-17 13:34:00 +08:00
Tao Liu
5f3d92c802 Release 2.0.25-1
Resolves: bz2120916
Resolves: bz2104534
Resolves: bz2089871
Resolves: bz2111857

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-09-21 10:17:22 +08:00
Coiby Xu
928c386f97 Allow to update kexec-tools using virt-customize for cloud base image
Resolves: bz2089871
Upstream: Fedora
Conflict: None

commit da0ca0d205
Author: Coiby Xu <coxu@redhat.com>
Date:   Tue Jun 28 14:38:28 2022 +0800

    Allow to update kexec-tools using virt-customize for cloud base image

    Resolves: bz2089871

    Currently, kexec-tools can't be updated using virt-customize because
    older version of kdumpctl can't acquire instance lock for the
    get-default-crashkernel subcommand. The reason is /var/lock is linked to
    /run/lock which however doesn't exist in the case of virt-customize.

    This patch fixes this problem by using /tmp/kdump.lock as the lock
    file if /run/lock doesn't exist.

    Note
    1. The lock file is now created in /run/lock instead of /var/run/lock since
       Fedora has adopted adopted /run [2] since F15.
    2. %pre scriptlet now always return success since package update won't
       be blocked

    [1] https://fedoraproject.org/wiki/Features/var-run-tmpfs

    Fixes: 0adb0f4 ("try to reset kernel crashkernel when kexec-tools updates the default crashkernel value")

    Reported-by: Nicolas Hicher <nhicher@redhat.com>
    Suggested-by: Laszlo Ersek <lersek@redhat.com>
    Suggested-by: Philipp Rudo <prudo@redhat.com>
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-09-19 09:10:54 +08:00
Tao Liu
c9bdde4cfb Release 2.0.24-5
Resolves: bz2076425

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-07-12 09:57:55 +08:00
Tao Liu
a743eaeded Release 2.0.24-4
Resolves: bz2041729
Resolves: bz2096132

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-06-15 13:05:39 +08:00
Tao Liu
9daddc7878 Release 2.0.24-3
Resolves: bz2090533

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-06-07 09:45:44 +08:00
Tao Liu
ba836a59b2 Release 2.0.24-2
Resolves: bz2059492
Resolves: bz2073676
Resolves: bz2074473

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-05-23 14:34:43 +08:00
Tao Liu
23f151d7b5 Release 2.0.24-1
Resolves: bz2081323
Resolves: bz2076159
Resolves: bz2076157

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-05-05 16:07:27 +08:00
Tao Liu
d180b099fd Rebase kexec-tools to v2.0.24
Resolves: bz2076157

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-05-05 16:04:09 +08:00
Tao Liu
b5d4920e52 Rebase makedumpfile to 1.7.1
Resolves: bz2076159

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-05-05 15:46:44 +08:00
Philipp Rudo
6348884a9d Avoid false-positive mem_section validation with vmlinux
Resolves: bz2081323
Upstream: github.com/makedumpfile/makedumpfile.git
Conflicts: None

commit 6d0d95ecc04a70f8448d562ff0fbbae237f5c929
Author: Kazuhito Hagio <k-hagio-ab@nec.com>
Date:   Thu Apr 21 08:58:29 2022 +0900

    [PATCH] Avoid false-positive mem_section validation with vmlinux

    Currently get_mem_section() validates if SYMBOL(mem_section) is the address
    of the mem_section array first.  But there was a report that the first
    validation wrongly returned TRUE with -x vmlinux and SPARSEMEM_EXTREME
    (4.15+) on s390x.  This leads to crash failing statup with the following
    seek error:

      crash: seek error: kernel virtual address: 67fffc2800  type: "memory section root table"

    Skip the first validation when satisfying the conditions.

    Reported-by: Dave Wysochanski <dwysocha@redhat.com>
    Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
    Reviewed-and-Tested-by: Philipp Rudo <prudo@redhat.com>
    Reviewed-by: Pingfan Liu <piliu@redhat.com>

Signed-off-by: Philipp Rudo <prudo@redhat.com>
2022-05-03 14:47:29 +02:00
Tao Liu
aab4b79f41 Release 2.0.23-10
Resolves: bz2060774
Resolves: bz2060824
Resolves: bz2069200

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-04-08 15:26:19 +08:00
Philipp Rudo
673f93346e s390: add support for --reuse-cmdline
Resolves: bz2060824
Upstream: git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
Conflicts: None

commit 2e1ec106dc5aac951ba884ebe4cca036e9a2d45f
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Thu Dec 16 12:43:56 2021 +0100

    s390: add support for --reuse-cmdline

    --reuse-cmdline reads the command line of the currently
    running kernel from /proc/cmdline and uses that for the
    kernel that should be kexec'd.

    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
    Signed-off-by: Simon Horman <horms@verge.net.au>

Signed-off-by: Philipp Rudo <prudo@redhat.com>
2022-04-06 18:05:47 +02:00
Philipp Rudo
1ac74b6d66 use slurp_proc_file() in get_command_line()
Resolves: bz2060824
Upstream: git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
Conflicts: None

commit d6516ba4c88f217fe14455db92c60cd0e9af18f8
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Thu Dec 16 12:43:55 2021 +0100

    use slurp_proc_file() in get_command_line()

    This way the size of the command line that get_command_line() can handle
    is no longer fixed.

    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Signed-off-by: Simon Horman <horms@verge.net.au>

Signed-off-by: Philipp Rudo <prudo@redhat.com>
2022-04-06 18:05:47 +02:00
Philipp Rudo
9e3d3bc043 add slurp_proc_file()
Resolves: bz2060824
Upstream: git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
Conflicts: None

commit 193e51deccc62544f6423eb5e5eefc8a23aad679
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Thu Dec 16 12:43:54 2021 +0100

    add slurp_proc_file()

    slurp_file() cannot be used to read proc files, as they are returning
    a size of zero in stat(). Add a function slurp_proc_file() which is
    similar to slurp_file(), but doesn't require the size of the file to
    be known.

    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Signed-off-by: Simon Horman <horms@verge.net.au>

Signed-off-by: Philipp Rudo <prudo@redhat.com>
2022-04-06 18:05:47 +02:00
Philipp Rudo
f8e3f42ec1 s390: use KEXEC_ALL_OPTIONS
Resolves: bz2060824
Upstream: git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
Conflicts: None

commit 91a3d0e00a5c18ee9bdd2c6c03ac64a6471e2559
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Thu Dec 16 12:43:53 2021 +0100

    s390: use KEXEC_ALL_OPTIONS

    KEXEC_ALL_OPTIONS could be used instead defining the same
    array several times. This makes code easier to maintain when
    new options are added.

    Suggested-by: Alexander Egorenkov <egorenar@linux.ibm.com>
    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
    Signed-off-by: Simon Horman <horms@verge.net.au>

Signed-off-by: Philipp Rudo <prudo@redhat.com>
2022-04-06 18:05:47 +02:00
Philipp Rudo
5c6595e4c0 s390: add variable command line size
Resolves: bz2060824
Upstream: git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
Conflicts: None

commit defb80a20bf1e4d778596ce2447e19d44f31ae5a
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Thu Dec 16 12:43:52 2021 +0100

    s390: add variable command line size

    Newer s390 kernels support a command line size longer than 896
    bytes. Such kernels contain a new member in the parameter area,
    which might be utilized by tools like kexec. Older kernels have
    the location initialized to zero, so we check whether there's a
    non-zero number present and use that. If there isn't, we fallback
    to the legacy command line size of 896 bytes.

    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
    Signed-off-by: Simon Horman <horms@verge.net.au>

Signed-off-by: Philipp Rudo <prudo@redhat.com>
2022-04-06 18:05:47 +02:00
Philipp Rudo
574a202f62 util_lib/elf_info: harden parsing of printk buffer
Resolves: bz2069200
Upstream: git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
Conflicts: None

commit f4c59879b830c7d574a953e6ce970ddaf20910d7
Author: Philipp Rudo <prudo@redhat.com>
Date:   Wed Mar 23 16:35:36 2022 +0100

    util_lib/elf_info: harden parsing of printk buffer

    The old printk mechanism (> v3.5.0 and < v5.10.0) had a fixed size
    buffer (log_buf) that contains all messages. The location for the next
    message is stored in log_next_idx. In case the log_buf runs full
    log_next_idx wraps around and starts overwriting old messages at the
    beginning of the buffer. The wraparound is denoted by a message with
    msg->len == 0.

    Following the behavior described above blindly is dangerous as e.g. a
    memory corruption could overwrite (parts of) the log_buf. If the
    corruption adds a message with msg->len == 0 this leads to an endless
    loop when dumping the dmesg. Fix this by verifying that not wrapped
    around before when it encounters a message with msg->len == 0.

    While at it also verify that the index is within the log_buf and thus
    guard against corruptions with msg->len != 0.

    The same bug has been reported and fixed in makedumpfile [1].

    [1] http://lists.infradead.org/pipermail/kexec/2022-March/024272.html

    Signed-off-by: Philipp Rudo <prudo@redhat.com>
    Signed-off-by: Simon Horman <horms@verge.net.au>

Signed-off-by: Philipp Rudo <prudo@redhat.com>
2022-03-28 19:20:45 +02:00
Philipp Rudo
7620d676de print error when reading with unsupported compression
Resolves: bz2069200
Upstream: github.com/makedumpfile/makedumpfile.git
Conflicts: goto out_error --> return FALSE
	   due to missing 64b5b29 ("[PATCH 03/15] remove variable length
	   array in readpage_kdump_compressed()")

commit 5035c0821f07da3badda645cd0064d4b80e1667d
Author: Philipp Rudo <prudo@redhat.com>
Date:   Mon Mar 14 17:04:32 2022 +0100

    [PATCH] print error when reading with unsupported compression

    Currently makedumpfile only checks if the required compression algorithm
    was enabled during build when compressing a dump but not when reading
    from one. This can lead to situations where, one version of makedumpfile
    creates the dump using a compression algorithm an other version of
    makedumpfile doesn't support. When the second version now tries to, e.g.
    extract the dmesg from the dump it will fail with an error similar to

      # makedumpfile --dump-dmesg vmcore dmesg.txt
      __vtop4_x86_64: Can't get a valid pgd.
      readmem: Can't convert a virtual address(ffffffff92e18284) to physical address.
      readmem: type_addr: 0, addr:ffffffff92e18284, size:390
      check_release: Can't get the address of system_utsname.

      makedumpfile Failed.

    That's because readpage_kdump_compressed{_parallel} does not return
    with an error if the page it is trying to read is compressed with an
    unsupported compression algorithm. Thus readmem copies random data from
    the (uninitialized) cachebuf to its caller and thus causing the error
    above.

    Fix this by checking if the required compression algorithm is supported
    in readpage_kdump_compressed{_parallel} and print a proper error message
    if it isn't.

    Reported-by: Dave Wysochanski <dwysocha@redhat.com>
    Signed-off-by: Philipp Rudo <prudo@redhat.com>
    Reviewed-and-tested-by: Dave Wysochanski <dwysocha@redhat.com>
    Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>

Signed-off-by: Philipp Rudo <prudo@redhat.com>
2022-03-28 19:19:43 +02:00