Commit Graph

197 Commits

Author SHA1 Message Date
Tao Liu
32276a35f2 Release 2.0.23-6
Resolves: bz2031736
Resolves: bz2017196
Resolves: bz2041911
Resolves: bz2017121
Resolves: bz2042726
Resolves: bz2045971
Resolves: bz2045969
Resolves: bz2024976

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-01-26 15:05:37 +08:00
Tao Liu
2bc8a0d274 Revert "Remove trace_buf_size and trace_event from the kernel bootparameters of the kdump kernel"
upstream: fedora
conflict: none
resolves: bz2042726

commit 99de77bba7
Author: Tao Liu <ltao@redhat.com>
Date:   Fri Jan 21 16:08:47 2022 +0800

    Revert "Remove trace_buf_size and trace_event from the kernel bootparameters of the kdump kernel"

    There is a mechanism to keep memory consumption minimum, i.e. equal
    to trace_buf_size=1, until tracing by ftrace is actually started:

        tracing: keep ring buffer to minimum size till used
        73c5162aa3

    Since ftrace is usually never used in the kdump 2nd kernel, the kdump
    2nd kernel behaves in the same way with or without trace_buf_size=1.
    So the issue which the patch want to solve never exists. Let's revert
    the patch for better maintainance and avoid confusion.

    ref link: https://bugzilla.redhat.com/show_bug.cgi?id=2034501#c20

    This reverts commit f39000f.

    Signed-off-by: Tao Liu <ltao@redhat.com>
    Acked-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-01-26 14:58:39 +08:00
Coiby Xu
80a37c95ee fix broken kdump_get_arch_recommend_size
Resolves: bz2045971
Upstream: Fedora
Conflict: None

commit 2df55984f6
Author: Coiby Xu <coxu@redhat.com>
Date:   Wed Jan 26 08:48:18 2022 +0800

    fix broken kdump_get_arch_recommend_size

    shellcheck finds the following problem,
    $ shellcheck kdump-lib.sh
    In kdump-lib.sh line 876:
            get_recommend_size "$sys_mem" "$ck_cmdline"
                                           ^---------^ SC2154: ck_cmdline is referenced but not assigned (did you mean '_ck_cmdline'?).

    s/ck_cmdline/_ck_cmdline to fix kdump_get_arch_recommend_size.

    Note s/sys_mem/_sys_mem as well to make the changes consistent.

    Fixes: 105c016 ("factor out kdump_get_arch_recommend_crashkernel")
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Acked-by: Tao Liu <ltao@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-26 14:41:01 +08:00
Coiby Xu
4e511ca370 remove the upper bound of 102400T for the range in default crashkernel
Resolves: bz2045969
Upstream: Fedora
Conflict: None

commit c67a836cde
Author: Coiby Xu <coxu@redhat.com>
Date:   Tue Jan 25 16:16:58 2022 +0800

    remove the upper bound of 102400T for the range in default crashkernel

    This patch makes the default crashkernel value consistent with previous
    one.

    Fixes: 105c016 ("factor out kdump_get_arch_recommend_crashkernel")
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-26 14:40:17 +08:00
Coiby Xu
e943713401 fix the error of parsing the container environ variable for osbuild
Resolves: bz2024976
Upstream: Fedora
Conflict: None

commit 6a3ce83a60
Author: Coiby Xu <coxu@redhat.com>
Date:   Wed Jan 19 11:16:29 2022 +0800

    fix the error of parsing the container environ variable for osbuild

    The environment variable entries in /proc/[pid]/environ are separated by
    null bytes instead of by spaces. Update the sed regex to fix this issue.

    Note that,
      1. this patch also fixes a issue which is kdumpctl would try to reset
         crashkernel even osbuild has provided custom crashkernel value.
      2. kernel hook 92-crashkernel.install installed by kexec-tools is
         guaranteed to be ran by kernel-install. kexec-tools doesn't recommend
         kernel so there is no guarantee kernel is installed after kexec-tools.
         But dnf invokes kernel-install in the posttrans scriptlet (of kernel-core)
         which is always ran after all packages including kexec-tools and kernel
         in a dnf transaction.
      3. To be able to do unit tests, the logic of reading environment variable
         has been extracted as a separate function.

    Fixes: ddd428a ("set up kernel crashkernel for osbuild in kernel hook")
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Pingfan Liu <piliu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-26 14:39:13 +08:00
Pingfan Liu
149a6dc9b2 mkdumprd (RHEL-only): add nvme module by force
Resolves: bz2017121
Upstream: RHEL-only

The following dracut commit can not detect the nvme module in some special
case, which causes vmcore dump failure.

commit c86f4d286000d1e76fd405560b4114537e2cbbff
Author: Pingfan Liu <piliu@redhat.com>
Date:   Wed Jul 28 18:13:43 2021 +0800

    fix(kernel-modules): detect block device's hardware driver

As a workaround, adding nvme module by force at present, and after a
real fix in dracut, we can revert this patch.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2022-01-26 11:19:56 +08:00
Philipp Rudo
4559f7bbd5 Remove dropped patches
Resolves: bz2041911
Upstream: RHEL-only

When updating makedumpfile to 1.7.0 the spec file was updated to no
longer apply these patches without removing the actual patch files.
Remove them now.

Fixes: d77fd26 ("Update makedumpfile to 1.7.0")
Signed-off-by: Philipp Rudo <prudo@redhat.com>
2022-01-19 10:35:02 +01:00
Philipp Rudo
1362366c86 s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()
Resolves: bz2041911
Upstream: git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
Conflicts: None

commit 186e7b0752d8fce1618fa37519671c834c46340e
Author: Alexander Egorenkov <egorenar@linux.ibm.com>
Date:   Wed Dec 15 18:48:53 2021 +0100

    s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()

    Starting with gcc 11.3, the C compiler will generate PLT-relative function
    calls even if they are local and do not require it. Later on during linking,
    the linker will replace all PLT-relative calls to local functions with
    PC-relative ones. Unfortunately, the purgatory code of kexec/kdump is
    not being linked as a regular executable or shared library would have been,
    and therefore, all PLT-relative addresses remain in the generated purgatory
    object code unresolved. This in turn lets kexec-tools fail with
    "Unknown rela relocation: 0x14 0x73c0901c" for such relocation types.

    Furthermore, the clang C compiler has always behaved like described above
    and this commit should fix the purgatory code built with the latter.

    Because the purgatory code is no regular executable or shared library,
    contains only calls to local functions and has no PLT, all R_390_PLT32DBL
    relocation entries can be resolved just like a R_390_PC32DBL one.

    * https://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_zSeries/x1633.html#AEN1699

    Relocation entries of purgatory code generated with gcc 11.3
    ------------------------------------------------------------

    $ readelf -r purgatory/purgatory.o

    Relocation section '.rela.text' at offset 0x6e8 contains 27 entries:
      Offset          Info           Type           Sym. Value    Sym. Name + Addend
    00000000000c  000300000013 R_390_PC32DBL     0000000000000000 .data + 2
    00000000001a  001000000014 R_390_PLT32DBL    0000000000000000 sha256_starts + 2
    000000000030  001100000014 R_390_PLT32DBL    0000000000000000 sha256_update + 2
    000000000046  001200000014 R_390_PLT32DBL    0000000000000000 sha256_finish + 2
    000000000050  000300000013 R_390_PC32DBL     0000000000000000 .data + 102
    00000000005a  001300000014 R_390_PLT32DBL    0000000000000000 memcmp + 2
    ...
    000000000118  001600000014 R_390_PLT32DBL    0000000000000000 setup_arch + 2
    00000000011e  000300000013 R_390_PC32DBL     0000000000000000 .data + 2
    00000000012c  000f00000014 R_390_PLT32DBL    0000000000000000 verify_sha256_digest + 2
    000000000142  001700000014 R_390_PLT32DBL    0000000000000000
    post_verification[...] + 2

    Relocation entries of purgatory code generated with gcc 11.2
    ------------------------------------------------------------

    $ readelf -r purgatory/purgatory.o

    Relocation section '.rela.text' at offset 0x6e8 contains 27 entries:
      Offset          Info           Type           Sym. Value    Sym. Name + Addend
    00000000000e  000300000013 R_390_PC32DBL     0000000000000000 .data + 2
    00000000001c  001000000013 R_390_PC32DBL     0000000000000000 sha256_starts + 2
    000000000036  001100000013 R_390_PC32DBL     0000000000000000 sha256_update + 2
    000000000048  001200000013 R_390_PC32DBL     0000000000000000 sha256_finish + 2
    000000000052  000300000013 R_390_PC32DBL     0000000000000000 .data + 102
    00000000005c  001300000013 R_390_PC32DBL     0000000000000000 memcmp + 2
    ...
    00000000011a  001600000013 R_390_PC32DBL     0000000000000000 setup_arch + 2
    000000000120  000300000013 R_390_PC32DBL     0000000000000000 .data + 122
    000000000130  000f00000013 R_390_PC32DBL     0000000000000000 verify_sha256_digest + 2
    000000000146  001700000013 R_390_PC32DBL     0000000000000000 post_verification[...] + 2

    Corresponding s390 kernel discussion:
    * https://lore.kernel.org/linux-s390/20211208105801.188140-1-egorenar@linux.ibm.com/T/#u

    Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
    Reported-by: Tao Liu <ltao@redhat.com>
    Suggested-by: Philipp Rudo <prudo@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>
    [hca@linux.ibm.com: changed commit message as requested by Philipp Rudo]
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Simon Horman <horms@verge.net.au>

Signed-off-by: Philipp Rudo <prudo@redhat.com>
2022-01-19 10:35:02 +01:00
Pingfan Liu
4bc3baa72f spec: add hostname.rpm into Recommends list
Resolves: bz2017196
Upstream: Fedora
Conflict: None

commit c480be7ccf
Author: Pingfan Liu <piliu@redhat.com>
Date:   Wed Jan 12 19:24:26 2022 +0800

    spec: add hostname.rpm into Recommends list

    kexec-tools runs hostname binary in the case of fence_kdump. Since this
    is a trival dependency and should not block the kexec-tools installation
    if non-existent, using weak-dependency to resolve it.

    Signed-off-by: Pingfan Liu <piliu@redhat.com>
    Acked-by: Tao Liu <ltao@redhat.com>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2022-01-18 15:16:39 +08:00
Pingfan Liu
e5c3e96985 move variable FENCE_KDUMP_SEND from kdump-lib.sh to kdump-lib-initramfs.sh
Resolves: bz2031736
Upstream: Fedora
Conflict: None

commit 3cd561fcbcb3ba4f285e746d81e1e6dae17447c3 (HEAD)
Author: Pingfan Liu <piliu@redhat.com>
Date:   Tue Jan 18 10:42:00 2022 +0800

    move variable FENCE_KDUMP_SEND from kdump-lib.sh to kdump-lib-initramfs.sh

    Since kdump-lib-initramfs.sh is included by kdump-lib.sh, and
    FENCE_KDUMP_SEND is used by both 1st and 2nd kernel, moving
    FENCE_KDUMP_SEND from kdump-lib.sh to kdump-lib-initramfs.sh.

    Signed-off-by: Pingfan Liu <piliu@redhat.com>
    Acked-by: Tao Liu <ltao@redhat.com>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2022-01-18 15:16:29 +08:00
Tao Liu
84fc25737e Release 2.0.23-5
resolves: bz1896698
resolves: bz1895258

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-01-11 10:07:07 +08:00
Tao Liu
a501dcbd7b Set zstd as recommented for kexec-tools
resolves: bz1896698
upstream: fedora
conflict: none

commit b8ec5cbda89610244fdd4711e5974350f78e63e3
Author: Tao Liu <ltao@redhat.com>
Date:   Fri Jan 7 19:47:06 2022 +0800

    Set zstd as recommented for kexec-tools

    This patch will make zstd as recommended instead of required for
    kexec-tools. If zstd command/package is unavaliable, it can failback to invoke
    gzip when making kdump initramfs.

    Fixes: 0311f6e ("Set zstd as the default compression method for kdump initrd")

    Signed-off-by: Tao Liu <ltao@redhat.com>
    Acked-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-01-11 10:02:52 +08:00
Coiby Xu
35486b6030 fix "kdump: Invalid kdump config option auto_reset_crashkernel" error
Resolves: bz1895258
Upstream: Fedora
Conflict: None

commit ae0cbdf34a
Author: Coiby Xu <coxu@redhat.com>
Date:   Fri Jan 7 10:45:40 2022 +0800

    fix "kdump: Invalid kdump config option auto_reset_crashkernel" error

    kdumpctl only accepts a specified set of options. Add
    auto_reset_crashkernel to this set.

    Fixes: 73ced7f ("introduce the auto_reset_crashkernel option to kdump.conf")
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Acked-by: Tao Liu <ltao@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-07 12:30:52 +08:00
Coiby Xu
d91054f2d3 use grep -s to suppress error messages about nonexistent or unreadable files
Resolves: bz1895258
Upstream: Fedora
Conflict: None

commit d5c31605f3
Author: Coiby Xu <coxu@redhat.com>
Date:   Thu Jan 6 09:48:17 2022 +0800

    use grep -s to suppress error messages about nonexistent or unreadable files

    When a file doesn't exist or isn't readable, grep complains as follows,

    grep: /proc/cmdline: No such file or directory
    grep: /etc/kernel/cmdline: No such file or directory

    /proc/cmdline doesn't exist when installing package for an OS image and
    /etc/kernel/cmdline may not exist if osbuild doesn't want set custom
    kernel cmdline.

    Use "-s" to suppress the error messages.

    Fixes: 0adb0f4 ("try to reset kernel crashkernel when kexec-tools updates the default crashkernel value")
    Fixes: ddd428a ("set up kernel crashkernel for osbuild in kernel hook")
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Acked-by: Tao Liu <ltao@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-07 12:30:52 +08:00
Tao Liu
40af76cf09 Release 2.0.23-4
resolves: bz1896698
resolves: bz2031735
resolves: bz2031737
resolves: bz1895258
resolves: bz2023165
resolves: bz2024976

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-01-06 14:49:15 +08:00
Tao Liu
96dc819c25 Set zstd as the default compression method for kdump initrd
resolves: bz1896698
upstream: fedora
conflict: none

commit 0311f6e25b
Author: Tao Liu <ltao@redhat.com>
Date:   Wed Jan 5 17:42:12 2022 +0800

    Set zstd as the default compression method for kdump initrd

    zstd has better compression ratio and time consumption balance.
    When no customized compression method specified in kdump.conf,
    we will use zstd as the default compression method.

    **The test method:

    I installed kexec-tools with and without the patch, executing the following
    command for 4 times, and calculate the averange time:

    $ rm -f /boot/initramfs-*kdump.img && time kdumpctl rebuild && \
      ls -ail /boot/initramfs-*kdump.img

    **The test result:

    Bare metal x86_64 machine:
            dracut with squash module
             zlib     lzo      xz       lz4        zstd
    real     10.6282  11.0398  11.395   8.6424    10.1676
    user      9.8932  11.9072  14.2304  2.8286     8.6468
    sys       3.523    3.4626   3.6028  3.5        3.4942
    size of
    kdump.img 30575616 31419392 27102208 36666368 29236224

            dracut without squash module
            zlib      lzo      xz       lz4        zstd
    real     9.509    19.4876  11.6724  9.0338    10.267
    user    10.6028   14.516   17.8662  4.0476     9.0936
    sys      2.942     2.9184   3.0662  2.9232     3.0662
    size of
    kdump.img 19247949 19958120 14505056 21112544 17007764

    PowerVM hosted ppc64le VM:
            dracut with squash module | dracut without sqaush module
             zlib        zstd         |  zlib          zstd
    real     10.6742     10.7572      |   9.7676       10.5722
    user     18.754      19.8338      |  20.7932       13.179
    sys       1.8358      1.864       |   1.637         1.663
                                      |
    size of                           |
    kdump.img 36917248   35467264     |  21441323      19007108

    **discussion

    zstd has a better compression ratio and time consumption balance.

    Acked-by: Coiby Xu <coxu@redhat.com>
    Signed-off-by: Tao Liu <ltao@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-01-06 14:36:29 +08:00
Tao Liu
90223d3c71 kdump-lib.sh: Escape '|' for 'failure_action|default' in is_dump_to_rootfs
resolves: bz2031735
upstream: fedora
conflict: none

commit 2bd59ee156 (origin/rawhide, origin/main)
Author: Tao Liu <ltao@redhat.com>
Date:   Thu Jan 6 11:46:54 2022 +0800

    kdump-lib.sh: Escape '|' for 'failure_action|default' in is_dump_to_rootfs

    The '|' in 'failure_action|default' should be replaced with '\|' when
    passed to kdump_get_conf_val function. Because '|' needs to be escaped
    to mean OR operation in sed regex, otherwise it will consider
    'failure_action|default' as a whole string.

    Fixes: ab1ef78 ("kdump-lib.sh: use kdump_get_conf_val to read config values")

    Signed-off-by: Tao Liu <ltao@redhat.com>
    Acked-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-01-06 14:35:53 +08:00
Tao Liu
745d063053 dracut-early-kdump-module-setup.sh: install xargs and kdump-lib-initramfs.sh
resolves: bz2031737
upstream: fedora
conflict: none

commit 004daebeff
Author: Tao Liu <ltao@redhat.com>
Date:   Sat Dec 18 16:14:44 2021 +0800

    dracut-early-kdump-module-setup.sh: install xargs and kdump-lib-initramfs.sh

    For earlykdump, kdump-lib-initramfs.sh is sourced by kdump-lib.sh,
    however it is not installed in dracut-early-kdump-module-setup.sh. Same
    as xargs, which is used by kdump-lib.sh. Otherwise earlykdump will report
    file not found errors.

    Fixes: a5faa052d4
           ("kdump-lib-initramfs.sh: prepare to be a POSIX compatible lib")
    Fixes: 4f01cb1b0a
           ("kdump-lib.sh: fix variable quoting issue")

    Signed-off-by: Tao Liu <ltao@redhat.com>
    Acked-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-01-06 14:31:33 +08:00
Coiby Xu
51bbe682ee update crashkernel-howto
Resolves: bz1895258
Upstream: Fedora
Conflict: None

commit 0e162120b6
Author: Coiby Xu <coxu@redhat.com>
Date:   Mon Dec 13 12:44:14 2021 +0800

    update crashkernel-howto

    Update crashkernel-howto since crashkernel.default has been removed. The
    documentation is also simplified as a result.

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-06 03:55:25 +00:00
Coiby Xu
fc136290bf set up kernel crashkernel for osbuild in kernel hook
Resolves: bz1895258
Resolves: bz2024976
Upstream: Fedora
Conflict: None

commit ddd428a1d0
Author: Coiby Xu <coxu@redhat.com>
Date:   Wed Dec 15 21:45:18 2021 +0800

    set up kernel crashkernel for osbuild in kernel hook

    osbuild is a tool to build OS images. It uses bwrap to install packages
    inside a sandbox/container. Since the kernel package recommends
    kexec-tools which in turn recommends grubby, the installation order would
    be grubby -> kexec-tools -> kernel. So we can use the kernel hook
    92-crashkernel.install provided by kexec-tools to set up kernel
    crashkernel for the target OS image. But in osbuild's case, there is no
    current running kernel and running `uname -r` in the container/sandbox
    actually returns the host kernel release. To set up kernel crashkernel for
    the OS image built by osbuild, a different logic is needed.

    We will check if kernel hook is running inside the osbuild container
    then set up kernel crashkernel only if osbuild hasn't specified a
    custome value. osbuild exposes [1] the container=bwrap-osbuild environment
    variable. According to [2], the environment variable is not inherited down
    the process tree, so we need to check /proc/1/environ to detect this
    environment variable to tell if the kernel hook is running inside a
    bwrap-osbuild container. After that we need to know if osbuild wants to use
    custom crashkernel value. This is done by checking if /etc/kernel/cmdline
    has crashkernel set [3]. /etc/kernel/cmdline is written before packages
    are installed.

    [1] https://github.com/osbuild/osbuild/pull/926
    [2] https://systemd.io/CONTAINER_INTERFACE/
    [3] https://bugzilla.redhat.com/show_bug.cgi?id=2024976#c5

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-06 03:55:25 +00:00
Coiby Xu
2589c40c4e reset kernel crashkernel for the special case where the kernel is updated right after kexec-tools
Resolves: bz1895258
Upstream: Fedora
Conflict: None

commit 5e8c751c39
Author: Coiby Xu <coxu@redhat.com>
Date:   Thu Dec 2 17:19:50 2021 +0800

    reset kernel crashkernel for the special case where the kernel is updated right after kexec-tools

    When kexec-tools updates the default crashkernel value, it will try to
    reset the existing installed kernels including the currently running
    kernel. So the running kernel could have different kernel cmdline
    parameters from /proc/cmdline. When installing a kernel after updating
    kexec-tools, /usr/lib/kernel/install.d/20-grub.install would be called
    by kernel-install [1] which would use /proc/cmdline to set up new kernel's
    cmdline. To address this special case, reset the new kernel's crashkernel
    and fadump value to the value that would be used by running kernel after
    rebooting by the installation hook. One side effect of this commit is it
    would reset the installed kernel's crashkernel even currently running kernel
    don't use the default crashkernel value after rebooting. But I think this
    side effect is a benefit for the user.

    The implementation depends on kernel-install which run the scripts in
    /usr/lib/kernel/install.d passing the following arguments,

      add KERNEL-VERSION $BOOT/MACHINE-ID/KERNEL-VERSION/ KERNEL-IMAGE [INITRD-FILE ...]

    An concrete example is given as follows,
      add 5.11.12-300.fc34.x86_64 /boot/e986846f63134c7295458cf36300ba5b/5.11.12-300.fc34.x86_64 /lib/modules/5.11.12-300.fc34.x86_64/vmlinuz

    kernel-install could be started by the kernel package's RPM scriplet [2].
    As mentioned in previous commit "try to reset kernel crashkernel when
    kexec-tools updates the default crashkernel value", kdumpctl has difficulty
    running in RPM scriptlet fore CoreOS. But rpm-ostree ignores all kernel hooks,
    there is no need to disable the kernel hook for CoreOS/Atomic/Silverblue. But a
    collaboration between rpm-ostree and kexec-tools is needed [3] to take care
    of this special case.

    Note the crashkernel.default support is dropped.

    [1] https://www.freedesktop.org/software/systemd/man/kernel-install.html
    [2] https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec#_2680
    [3] https://github.com/coreos/rpm-ostree/issues/2894

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-06 03:55:25 +00:00
Coiby Xu
224984355d try to reset kernel crashkernel when kexec-tools updates the default crashkernel value
Resolves: bz1895258
Upstream: Fedora
Conflict: None

commit 0adb0f4a8c
Author: Coiby Xu <coxu@redhat.com>
Date:   Wed Dec 1 15:33:13 2021 +0800

    try to reset kernel crashkernel when kexec-tools updates the default crashkernel value

    kexec-tools could update the default crashkernel value.
    When auto_reset_crashkernel=yes, reset kernel to new crashkernel
    value in the following two cases,
     - crashkernel=auto is found in the kernel cmdline
     - the kernel crashkernel was previously set by kexec-tools i.e.
       the kernel is using old default crashkernel value

    To tell if the user is using a custom value for the kernel crashkernel
    or not, we assume the user would never use the default crashkernel value
    as custom value. When kexec-tools gets updated,
     1. save the default crashkernel value of the older package to
        /tmp/crashkernel (for POWER system, /tmp/crashkernel_fadump is saved
        as well).
     2. If auto_reset_crashkernel=yes, iterate all installed kernels.
        For each kernel, compare its crashkernel value with the old
        default crashkernel and reset it if yes

    The implementation makes use of two RPM scriptlets [2],
     - %pre is run before a package is installed so we can use it to save
       old default crashkernel value
     - %post is run after a package installed so we can use it to try to reset
       kernel crashkernel

    There are several problems when running kdumpctl in the RPM scripts
    for CoreOS/Atomic/Silverblue, for example, the lock can't be acquired by
    kdumpctl, "rpm-ostree kargs" can't be run and etc.. So don't enable this
    feature for CoreOS/Atomic/Silverblue.

    Note latest shellcheck (0.8.0) gives false positives about the
    associative array as of this commit. And Fedora's shellcheck is 0.7.2
    and can't even correctly parse the shell code because of the associative
    array.

    [1] https://github.com/koalaman/shellcheck/issues/2399
    [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-06 03:55:25 +00:00
Coiby Xu
7ac560ef9b introduce the auto_reset_crashkernel option to kdump.conf
Resolves: bz1895258
Upstream: Fedora
Conflict: None

commit 73ced7f451
Author: Coiby Xu <coxu@redhat.com>
Date:   Mon Nov 15 15:45:59 2021 +0800

    introduce the auto_reset_crashkernel option to kdump.conf

    This option will determine whether to reset kernel crashkernel
    to new default value or not when kexec-tools updates the default
    crashkernel value and existing kernels using the old default kernel
    crashkernel value. Default to yes.

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-06 03:55:25 +00:00
Coiby Xu
3f828198af rewrite reset_crashkernel to support fadump and to used by RPM scriptlet
Resolves: bz1895258
Upstream: Fedora
Conflict: None

commit 140da74a34
Author: Coiby Xu <coxu@redhat.com>
Date:   Wed Dec 1 13:39:40 2021 +0800

    rewrite reset_crashkernel to support fadump and to used by RPM scriptlet

    Rewrite kdumpctl reset-crashkernel KERNEL_PATH as
    kdumpctl reset-crashkernel [--fadump=[on|off|nocma]]  [--kernel=path_to_kernel] [--reboot]

    This interface would reset a specific kernel to the default crashkernel value
    given the kernel path. And it also supports grubby's syntax so there are the
    following special cases,
     - if --kernel not specified,
        - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump
        - otherwise use current running kernel, i.e. `uname -r`
     - if --kernel=DEFAULT, the default boot kernel is chosen
     - if --kernel=ALL, all kernels would have its crashkernel reset to the
       default value and the /etc/default/grub is updated as well

    --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided
    in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by
    parsing the kernel command line for the kernel(s) to update.

    CoreOS/Atomic/Silverblue needs to be treated as a special case because,
     - "rpm-ostree kargs" is used to manage kernel command line parameters
        so --kernel doesn't make sense and there is no need to find current
        running kernel
     - "rpm-ostree kargs" itself would prompt the user to reboot the system
       after modify the kernel command line parameter
     - POWER is not supported so we can assume the dump mode is always kdump

    This interface will also be called by kexec-tools RPM scriptlets [1]
    to reset crashkernel.

    Note the support of crashkenrel.default is dropped.

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

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-06 03:55:25 +00:00
Coiby Xu
16777a88b8 fix incorrect usage of rpm-ostree to update kernel command line parameters
Resolves: bz1895258
Upstream: Fedora
Conflict: None

commit 12ecbce359
Author: Coiby Xu <coxu@redhat.com>
Date:   Mon Dec 13 10:57:13 2021 +0800

    fix incorrect usage of rpm-ostree to update kernel command line parameters

    CoreOS/Atomic/Silverblue use "rpm-ostree kargs" to manage kernel command
    line parameters.

    Fixes: 86130ec ("kdumpctl: Add kdumpctl reset-crashkernel")

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-06 03:55:25 +00:00
Coiby Xu
b3d9b9bd5c add helper functions to get kernel path by kernel release and the path of current running kernel
Resolves: bz1895258
Upstream: Fedora
Conflict: None

commit 945cbbd59b
Author: Coiby Xu <coxu@redhat.com>
Date:   Tue Dec 7 15:16:07 2021 +0800

    add helper functions to get kernel path by kernel release and the path of current running kernel

    grubby --info=kernel-path or --add-kernel=kernel-path accepts a kernel
    path (e.g. /boot/vmlinuz-5.14.14-200.fc34.x86_64) instead of kernel release
    (e.g 5.14.14-200.fc34.x86_64). So we need to know the kernel path given
    a kernel release. Although for Fedora/RHEL, the kernel path is
    "/boot/vmlinuz-<KERNEL_RELEASE>", a path kernel could also be
    /boot/<machine-id>/<KERNEL_RELEASE>/vmlinuz. So the most reliable way to
    find the kernel path given a kernel release is to use "grubby --info".

    For osbuild, a kernel path may not yet exist but it's valid for
    "grubby --update-kernel=KERNEL_PATH". For example, "grubby -info" may
    output something as follows,

    index=0
    kernel="/var/cache/osbuild-worker/osbuild-store/tmp/tmp2prywdy5object/tree/boot/vmlinuz-5.15.10-100.fc34.x86_64"
    args="ro no_timer_check net.ifnames=0 console=tty1 console=ttyS0,115200n8"
    root="UUID=76a22bf4-f153-4541-b6c7-0332c0dfaeac"
    initrd="/var/cache/osbuild-worker/osbuild-store/tmp/tmp2prywdy5object/tree/boot/initramfs-5.15.10-100.fc34.x86_64.img"

    There is no need to check if path like
    /var/cache/osbuild-worker/osbuild-store/tmp/tmp2prywdy5object/tree/boot/vmlinuz-5.15.10-100.fc34.x86_64
    physically exists.

    Note these helper functions doesn't support CoreOS/Atomic/Silverblue
    since grubby isn't used by them.

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-06 03:55:25 +00:00
Coiby Xu
d5cf913260 add helper functions to get dump mode
Resolves: bz1895258
Upstream: Fedora
Conflict: None

commit 3d2079c31c
Author: Coiby Xu <coxu@redhat.com>
Date:   Wed Dec 1 16:57:15 2021 +0800

    add helper functions to get dump mode

    Add a helper function to get dump mode. The dump mode would be
     - fadump if fadump=on or fadump=nocma
     - kdump if fadump=off or empty fadump

    Otherwise return 1.

    Also add another helper function to return a kernel's dump mode.

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-06 03:55:25 +00:00
Coiby Xu
27b5ab3cbb add a helper function to read kernel cmdline parameter from grubby --info
Resolves: bz1895258
Upstream: Fedora
Conflict: None

commit fb9e6838ab
Author: Coiby Xu <coxu@redhat.com>
Date:   Tue Nov 16 06:48:40 2021 +0800

    add a helper function to read kernel cmdline parameter from grubby --info

    This helper function will be used to retrieve the value of kernel
    cmdline parameters including crashkernel, fadump, swiotlb and etc.

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-06 03:55:25 +00:00
Coiby Xu
acf9f64ca6 provide kdumpctl get-default-crashkernel for kdump_anaconda_addon and RPM scriptlet
Resolves: bz1895258
Upstream: Fedora
Conflict: None

commit 796d0f6fd2
Author: Coiby Xu <coxu@redhat.com>
Date:   Tue Nov 16 12:23:02 2021 +0800

    provide kdumpctl get-default-crashkernel for kdump_anaconda_addon and RPM scriptlet

    Provide "kdumpctl get-default-crashkernel" for kdump_anaconda_addon
    so crashkernel.default isn't needed.

    When fadump is on, kdump_anaconda_addon would need to specify the dump
    mode, i.e. "kdumpctl get-default-crashkernel fadump".

    This interface would also be used by RPM scriptlet [1] to fetch default
    crashkernel value.

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

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-06 03:55:25 +00:00
Coiby Xu
1ab9685afa factor out kdump_get_arch_recommend_crashkernel
Resolves: bz1895258
Upstream: Fedora
Conflict: None

commit 105c01691a
Author: Coiby Xu <coxu@redhat.com>
Date:   Tue Nov 16 11:26:31 2021 +0800

    factor out kdump_get_arch_recommend_crashkernel

    Factor out kdump_get_arch_recommend_crashkernel to prepare for
    kdump-anaconda-plugin for example to retrieve the default crashkernel
    value.

    Note the support of crashkenrel.default is dropped.

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-06 03:55:25 +00:00
Coiby Xu
33a9e54ff2 update default crashkernel value
Resolves: bz1895258
Upstream: Fedora
Conflict: None

commit 34d27c4c30
Author: Coiby Xu <coxu@redhat.com>
Date:   Tue Nov 16 09:12:49 2021 +0800

    update default crashkernel value

    It has been decided to increase default crashkernel value to reduce the
    possibility of OOM.

    Fixes: 7b7ddab ("kdump-lib.sh: kdump_get_arch_recommend_size uses crashkernel.default")

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-06 03:55:25 +00:00
Pingfan Liu
5ac720fc20 ppc64/ppc64le: drop cpu online rule in 40-redhat.rules in kdump initramfs
Resolves: bz2023165
Upstream: Fedora
Conflict: None

commit a3c1e70fc1c0e4bab4149f617cbd629e89bd5ca0 (HEAD -> main)
Author: Pingfan Liu <piliu@redhat.com>
Date:   Wed Dec 8 10:46:38 2021 +0800

    ppc64/ppc64le: drop cpu online rule in 40-redhat.rules in kdump initramfs

    Onlining secondary cpus breaks kdump completely on KVM on Power hosts
    Though we use maxcpus=1 by default but 40-redhat.rules will bring up all
    possible cpus by default.

    Thus before we get the kernel fix and the systemd rule fix let's remove
    the cpu rule in 40-redhat.rules for ppc64/ppc64le kdump initramfs.

    This is back ported from RHEL, and original credit goes to Dave Young
    <dyoung@redhat.com>

    Signed-off-by: Pingfan Liu <piliu@redhat.com>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2021-12-29 11:21:42 +08:00
Tao Liu
9fd4d2a0c6 Release 2.0.23-3
Related: bz2003832
Related: bz2027568

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-12-08 09:13:27 +08:00
Tao Liu
d2bb9a1d9a Update eppic to latest upstream snapshot
upstream: fedora
related:  bz2003832
conflict: yes, non-functional modifications made.

commit 91f1d5989b
Author: Kairui Song <kasong@redhat.com>
Date:   Thu Apr 1 16:53:35 2021 +0800

    Update eppic to latest upstream snapshot

    Also fixes a package build failure:
    ar ccurl libeppic.a eppic_util.o eppic_node.o eppic_var.o eppic_func.o eppic_str.o eppic_op.o eppic_num.o eppic_stat.o eppic_builtin.o eppic_type.o eppic_case.o eppic_api.o eppic_member.o eppic_alloc.o eppic_define.o eppic_input.o eppic_print.o eppicpp.tab.o eppic.tab.o lex.eppic.o lex.eppicpp.o baseops.o
    ar: eppic_util.o: file format not recognized

    See eppic commit 0037321e64952b4feb3bd37761fb1067266e9e72 for more
    details.

    Signed-off-by: Kairui Song <kasong@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-12-08 09:01:11 +08:00
Tao Liu
6120984200 Update crashkernel-howto.txt
upstream: fedora
related:  bz2003832
conflict: none

commit 7435ecf3c4
Author: Kairui Song <kasong@redhat.com>
Date:   Wed Jul 21 14:05:25 2021 +0800

    Update crashkernel-howto.txt

    Fix some grammar issues.

    Signed-off-by: Kairui Song <kasong@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-12-08 09:01:11 +08:00
Tao Liu
edb8691a8e Remove references to systemd-sysv-convert
upstream: fedora
related:  bz2003832
conflict: yes, non-functional modification made

commit c894022e9b
Author: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Date:   Tue Jun 1 10:15:11 2021 +0200

    Remove references to systemd-sysv-convert

    Packaging guidelines have been amended to not require systemd for scriptlets,
    see https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_scriptlets.

    The comment duplicates what the macro contains.

    systemd-sysv-convert binary was removed in 2013, trying to call it is
    unlikely to succeed.

    chkconfig binary is provided by the chkconfig package, which is not in
    Requires. (And makes little sense to call nowadays anyway.)

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-12-08 09:01:11 +08:00
Tao Liu
4dfb0840df kdump/ppc64: suppress the error message "Could not find a registered notification tool" from servicelog_notify
upstream: fedora
related:  bz2027568
conflict: none

commit f0892eeceb
Author: Coiby Xu <coxu@redhat.com>
Date:   Wed Dec 1 15:37:06 2021 +0800

    kdump/ppc64: suppress the error message "Could not find a registered notification tool" from servicelog_notify

    When kexec-tools is newly installed, kdump migration action hasn't
    registered and the following error could occur,
      INF dnf.rpm: Could not find a registered notification tool with the specified command ('/usr/lib/kdump/kdump-migrate-action.sh').

    "servicelog_notify --list" could list registered notification tools for
    a command but it outputs the above error as well. So simply redirect the
    error to /dev/null when running "servicelog_notify --remove".

    Fixes: commit 146f662622
           ("kdump/ppc64: migration action registration clean up")

    Acked-by: Tao Liu <ltao@redhat.com>
    Acked-by: Hari Bathini <hbathini@linux.ibm.com>
    Signed-off-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-12-08 09:01:11 +08:00
Tao Liu
e8e40f6571 fadump: improve fadump-howto.txt about remote dump target setup
upstream: fedora
related:  bz2003832
conflict: none

commit da6f381b08
Author: Hari Bathini <hbathini@linux.ibm.com>
Date:   Thu Feb 18 14:12:00 2021 +0530

    fadump: improve fadump-howto.txt about remote dump target setup

    While fadump-howto.txt talks about what happens to network interface
    name on setting up a remote dump target in FADump mode, it doesn't
    explicitly specify the negative consequences of it. Make it explicit
    and provide a recommendation to overcome the same.

    Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
    Acked-by: Kairui Song <kasong@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-12-08 08:59:31 +08:00
Tao Liu
b256e1f9a6 Don't exit 1 from 92-crashkernel.install if zipl is absent (#1993505)
upstream: fedora
related:  bz2003832
conflict: yes, the upstream patch modified kexec-tools.spec for a
          new fedora release, thus the modification is removed when
          backporting.

commit 5270d40dd0
Author: Adam Williamson <awilliam@redhat.com>
Date:   Tue Aug 31 16:07:51 2021 -0700

    Don't exit 1 from 92-crashkernel.install if zipl is absent (#1993505)

    At least, this is a plausible suspect for #1993505 - thanks to
    @kevin for identifying it - and fixing it should be safe and
    correct, so we may as well do it and see if it helps.

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-12-07 20:06:48 +08:00
Tao Liu
e38a68c132 Document/kexec-kdump-howto.txt: improve notes for kdump_pre and kdump_post scripts
upstream: fedora
related:  bz2003832
conflict: none

commit 8cc51f3ab9
Author: Pingfan Liu <piliu@redhat.com>
Date:   Mon Nov 15 22:23:42 2021 +0800

    Document/kexec-kdump-howto.txt: improve notes for kdump_pre and kdump_post scripts

    Signed-off-by: Pingfan Liu <piliu@redhat.com>
    Acked-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-12-07 20:02:41 +08:00
Tao Liu
404517744b Release 2.0.23-2
resolves: bz2027568
related:  bz1986667
resolves: bz2024450
resolves: bz1931802
resolves: bz1895232
resolves: bz1881876

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-12-03 18:14:47 +08:00
Tao Liu
ec53fb983d kdump/ppc64: migration action registration clean up
resolves: bz2027568
upstream: fedora
conflict: None-functional conflict in spec file.

commit 146f662622
Author: Hari Bathini <hbathini@linux.ibm.com>
Date:   Tue Jul 27 23:59:48 2021 +0530

    kdump/ppc64: migration action registration clean up

    While kdump migration action is registered for LPM event, ensure it is
    cleared as appropriate to avoid duplicate/stale notification entries.

    Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
    Acked-by: Kairui Song <kasong@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-12-03 18:14:03 +08:00
Tao Liu
de65197ba0 kdump/ppc64: rebuild initramfs image after migration
upstream: fedora
resolves: bz2027568
conflict: The upstream patch was submitted before
          "Add file supported-kdump-targets.txt to kexec-tools"
          was added to rhel9. So there are SourceXX conflict
          in spec file. And similar code merge with patch
          "add keyutils as a weak dependency for POWER"

commit 71b7a2f47c
Author: Hari Bathini <hbathini@linux.ibm.com>
Date:   Mon Jul 12 15:33:03 2021 +0530

    kdump/ppc64: rebuild initramfs image after migration

    Dump capture initramfs needs rebuild after partition migration (LPM).
    Use servicelog notification mechanism to invoke kdump rebuild after
    migration.

    Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
    Reviewed-by: Pingfan Liu <piliu@redhat.com>
    Acked-by: Kairui Song <kasong@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-12-03 18:13:09 +08:00
Tao Liu
9e86be70ac Update supported-kdump-targets.txt
Related: bz1986667
Upstream: RHEL-only

Modification based on bz link:
https://bugzilla.redhat.com/show_bug.cgi?id=1986667#c11

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-11-26 13:38:12 +08:00
Coiby Xu
b468814961 add keyutils as a weak dependency for POWER
Resolves: bz2024450
Upstream: Fedora
Conflict: RHEL9 POWER kexec-tools doesn't have any dependency on other
          packages.

commit c3c8df3745
Author: Coiby Xu <coxu@redhat.com>
Date:   Thu Nov 18 12:26:01 2021 +0800

    add keytuils as a weak dependency for POWER

    When secureboot is enabled, kdumpctl needs to use keyctl to add/remove
    a key to/from the .ima keyring.

    Fixes: commit 596fa0a07f
           ("kdumpctl: enable secure boot on ppc64le LPARs")

    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Acked-by: Hari Bathini <hbathini@linux.ibm.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2021-11-26 12:08:52 +08:00
Coiby Xu
eb95f93880 kdumpctl: enable secure boot on ppc64le LPARs
Resolves: bz1931802
Upstream: Fedora
Conflict: The upstream commit was submitted before shfmt and .editorconfig.
          So there are issues like 4 spaces verse tab indentation, double
          brackets verse single bracket and etc.

commit 596fa0a07f
Author: Pingfan Liu <piliu@redhat.com>
Date:   Thu Feb 18 14:01:18 2021 +0800

    kdumpctl: enable secure boot on ppc64le LPARs

    On ppc64le LPAR, secure-boot is a little different from bare metal,
    Where
      host secure boot: /ibm,secure-boot/os-secureboot-enforcing DT property exists
    while
      guest secure boot: /ibm,secure-boot >= 2

    Make kexec-tools adapt to LPAR

    Signed-off-by: Pingfan Liu <piliu@redhat.com>
    Acked-by: Kairui Song <kasong@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2021-11-26 12:03:07 +08:00
Pingfan Liu
058f49c0ad kdump.sysconfig: make kexec_file_load as default option on arm64
Resolves: bz1895232
Upstream: Fedora
Conflict: None

commit 4948fd88d5ff328a69ecc1c1b55e5f09cd65556a
Author: Pingfan Liu <piliu@redhat.com>
Date:   Thu Oct 21 10:12:18 2021 +0800

    sysconfig: make kexec_file_load as default option on aarch64

    Signed-off-by: Pingfan Liu <piliu@redhat.com>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2021-11-12 05:58:48 +00:00
Pingfan Liu
888c24c90b kdump.sysconfig: make kexec_file_load as default option on ppc64le
Resolves: bz1881876
Upstream: Fedora
Conflict: None

commit a239a939237ced11c35d52d722a7eecb84091de6
Author: Pingfan Liu <piliu@redhat.com>
Date:   Thu Oct 21 10:13:10 2021 +0800

    sysconfig: make kexec_file_load as default option on ppc64le

    Signed-off-by: Pingfan Liu <piliu@redhat.com>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2021-11-12 09:47:42 +08:00
Tao Liu
08975beb59 Release 2.0.23-1
Update kexec-tools to 2.0.23
resolves: bz2008397
resolves: bz1972513

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-11-11 17:34:08 +08:00
Tao Liu
5e96c98892 Enable zstd compression for makedumpfile in kexec-tools.spec
upstream: fedora
resolves: bz2008397
conflict: none

commit 9ffda5bc1c
Author: Tao Liu <ltao@redhat.com>
Date:   Wed Nov 10 16:56:53 2021 +0800

    Enable zstd compression for makedumpfile in kexec-tools.spec

    The Zstandard (zstd) compression method is not enabled:

        $ makedumpfile -v
        makedumpfile: version 1.7.0 (released on 8 Nov 2021)
        lzo         enabled
        snappy      enabled
        zstd        disabled

    This patch will enable it when building kexec-tools rpm package.

    Signed-off-by: Tao Liu <ltao@redhat.com>
    Acked-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-11-11 17:15:52 +08:00