Commit Graph

75 Commits

Author SHA1 Message Date
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
Philipp Rudo
fb25c11f79 use cycle detection when parsing the prink log_buf
Resolves: bz2069200
Upstream: github.com/makedumpfile/makedumpfile.git
Conflicts: None

commit 68d120b30af5e930afafed81e79712af3c1a278c
Author: Philipp Rudo <prudo@redhat.com>
Date:   Mon Mar 14 17:04:31 2022 +0100

    [PATCH v2 3/3] use cycle detection when parsing the prink log_buf

    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 in makedumpfile 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 with makedumpfile appending
    the messages up to the corruption over and over again to the output file
    until file system is full. Fix this by using cycle detection and aboard
    once one is detected.

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

    Reported-by: Audra Mitchell <aubaker@redhat.com>
    Suggested-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: Philipp Rudo <prudo@redhat.com>
2022-03-28 18:39:31 +02:00
Philipp Rudo
92f7d2ba5e use pointer arithmetics for dump_dmesg
Resolves: bz2069200
Upstream: github.com/makedumpfile/makedumpfile.git
Conflicts: None

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

    [PATCH v2 2/3] use pointer arithmetics for dump_dmesg

    When parsing the printk buffer for the old printk mechanism (> v3.5.0+ and
    < 5.10.0) a log entry is currently specified by the offset into the
    buffer where the entry starts. Change this to use a pointers instead.
    This is done in preparation for using the new cycle detection mechanism.

    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 18:39:04 +02:00
Philipp Rudo
90da030e61 add generic cycle detection
Resolves: bz2069200
Upstream: github.com/makedumpfile/makedumpfile.git
Conflicts: None

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

    [PATCH v2 1/3] add generic cycle detection

    In order to work makedumpfile needs to interpret data read from the
    dump. This can cause problems as the data from the dump cannot be
    trusted (otherwise the kernel wouldn't have panicked in the first
    place). This also means that every loop which stop condition depend on
    data read from the dump has a chance to loop forever. Thus add a generic
    cycle detection mechanism that allows to detect and handle such
    situations appropriately.

    For cycle detection use Brent's algorithm [1] as it has constant memory
    usage. With this it can also be used in the kdump kernel without the
    danger that it runs oom when iterating large data structures.
    Furthermore it only depends on some pointer arithmetic. Thus the
    performance impact (as long as no cycle was detected) should be
    comparatively small.

    [1] https://en.wikipedia.org/wiki/Cycle_detection#Brent's_algorithm

    Suggested-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: Philipp Rudo <prudo@redhat.com>
2022-03-28 18:38:30 +02:00
Tao Liu
1eadf2b8a8 Release 2.0.23-9
Resolves: bz2055498

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-02-25 09:58:26 +08:00
Tao Liu
6e2f52ede1 makedumpfile: sadump, kaslr: fix failure of calculating kaslr_offset
upstream: fedora
resolves: bz2055498
conflict: none

commit 59b1726fbcc251155140c8a1972384498fee4daf
Author: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
Date:   Tue Jan 25 12:55:15 2022 +0000

    [PATCH] sadump, kaslr: fix failure of calculating kaslr_offset

    On kernels v5.8 or later, makedumpfile fails for memory dumps in the
    sadump-related formats as follows:

        # makedumpfile -f -l -d 31 -x ./vmlinux /dev/sdd4 /root/vmcore-ld31
        __vtop4_x86_64: Can't get a valid pud_pte.
        ...110 lines of the same message...
        __vtop4_x86_64: Can't get a valid pud_pte.
        calc_kaslr_offset: failed to calculate kaslr_offset and phys_base; default to 0
        readmem: type_addr: 1, addr:ffffffff85411858, size:8
        __vtop4_x86_64: Can't get pgd (page_dir:ffffffff85411858).
        readmem: Can't convert a virtual address(ffffffff059be980) to physical address.
        readmem: type_addr: 0, addr:ffffffff059be980, size:1024
        cpu_online_mask_init: Can't read cpu_online_mask memory.

        makedumpfile Failed.

    This is caused by the kernel commit 9d06c4027f21 ("x86/entry: Convert
    Divide Error to IDTENTRY") that renamed divide_error to
    asm_exc_divide_error, breaking logic for calculating kaslr offset.

    Fix this by adding initialization of asm_exc_divide_error.

    Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-02-25 09:53:51 +08:00
Tao Liu
c19658357d Release 2.0.23-8
Resolves: bz2051822

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-02-21 10:37:44 +08:00
Coiby Xu
06b51aac41 update kernel crashkernel in posttrans RPM scriptlet when updating kexec-tools
Resolves: bz2051822
Upstream: Fedora
Conflict: None

commit 311b5b100b
Author: Coiby Xu <coxu@redhat.com>
Date:   Fri Feb 11 13:11:17 2022 +0800

    update kernel crashkernel in posttrans RPM scriptlet when updating kexec-tools

    When doing in-place upgrading using leapp on x86_64, kdumpcl can't
    acquire instance lock when running in %post RPM scriplet on x86_64,
      localhost upgrade[1306]: /bin/kdumpctl: line 49: /var/lock/kdump: No such file or directory
      localhost upgrade[1306]: kdump: Create file lock failed

    and running "touch /var/lock/dkump" also fails with
    "No such file or directory". Thus kdumpctl can't be run in %post
    scriptlet. But kdumpctl can be run in %posttrans RPM scriplet.

    Besides, it's better to update crashkernel after the kernel has been
    updated. So let's update kernel crashkernel in the %posttrans
    scriptlet which will be run in the end of a transaction i.e. after
    the kernel has been updated.

    Note for %posttrans scriptlet, "$1 == 1" means both installing a new
    package and upgrading a package.

    [1] https://github.com/apptainer/singularity/issues/2386#issuecomment-474747054

    Reported-by: Jie Li <jieli@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-02-18 09:05:25 +08:00
Tao Liu
e2d1f68d0f Release 2.0.23-7
Related: bz1895258
Resolves: bz2024976

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-02-14 12:37:55 +08:00
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
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
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
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
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
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
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
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
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
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
Tao Liu
d77fd26026 Update makedumpfile to 1.7.0
resolves: bz2008397

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-11-10 15:49:42 +08:00
Tao Liu
df46b8c7e7 Release 2.0.22-16
resolves: bz1982535
resolves: bz2003832
resolves: bz2014626
resolves: bz1989451

Increased release subversion for the commit message.

Fixes: commit c1406d2cab
       ("Rebuilt for IMA sigs, glibc 2.34, aarch64 flags")
The release subversion wasn't increased for this commit.

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-11-10 13:57:44 +08:00
Tao Liu
13a24c49ab Merge kdump-error-handler.sh into kdump.sh
upstream: fedora
resolves: bz2003832
conflict: none

commit e7118d1de8
Author: Kairui Song <kasong@redhat.com>
Date:   Mon Aug 2 00:50:22 2021 +0800

    Merge kdump-error-handler.sh into kdump.sh

    kdump-error-handler.sh does nothing except calling three functions,
    it can be easily merged into kdump.sh by using a parameter to run the
    error handling routine.

    kdump-lib-initramfs.sh was created to hold the three shared functions
    and related code, so by merging these two files, kdump-lib-initramfs.sh
    can be simplified by a lot.

    Following up commits will clean up kdump-lib-initramfs.sh.

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

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-11-09 21:45:31 +08:00
Tao Liu
7ccb7e18e7 Remove hard requirement on grubby
Resolves: bz2014626
Upstream: Fedora
Conflict: None

commit 7ddda7e6d0
Author: Kairui Song <kasong@redhat.com>
Date:   Wed Aug 18 22:25:22 2021 +0800

    Remove hard requirement on grubby

    Downgrade to "Recommends:" as suggested by CoreOS team.

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

Signed-off-by: Tao Liu <ltao@redhat.com>
Signed-off-by: Timothée Ravier <travier@redhat.com>
2021-10-28 13:26:19 +08:00
Tao Liu
c65278f12a Release 2.0.22-14
Resolves: bz1986667

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-09-08 14:11:53 +08:00
Tao Liu
220b190cd8 Add file supported-kdump-targets.txt to kexec-tools
Resolves: bz1986667
Copied from rhel-8.5

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-09-07 14:32:27 +08:00
Mohan Boddu
c1406d2cab Rebuilt for IMA sigs, glibc 2.34, aarch64 flags
Related: rhbz#1991688
Signed-off-by: Mohan Boddu <mboddu@redhat.com>
2021-08-09 21:11:43 +00:00
Tao Liu
572dfb2ae8 Release 2.0.22-13
Resolves: bz1986250

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-08-09 09:56:52 +08:00
Tao Liu
a42016ff19 Release 2.0.22-12
Resolves: bz1981684
Resolves: bz1986281

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-08-02 10:31:39 +08:00
Tao Liu
0ef6c1aa27 Release 2.0.22-11
Resolves: bz1972463
Resolves: bz1982474
Resolves: bz1979879

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-07-26 10:30:33 +08:00
Tao Liu
b84de553b4 Release 2.0.22-10
Resolves: bz1924115
Resolves: bz1972463
Resolves: bz1977559

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-07-20 15:51:38 +08:00
Kairui Song
96a3fc1ac8 fadump: isolate fadump initramfs image within the default one
Resolves: bz1924115
Conflict: None
Upstream: Fedora

commit fa9201b240 (devel)
Author: Hari Bathini <hbathini@linux.ibm.com>
Date:   Wed Jun 23 20:06:48 2021 +0530

    fadump: isolate fadump initramfs image within the default one

    In case of fadump, the initramfs image has to be built to boot into
    the production environment as well as to offload the active crash dump
    to the specified dump target (for boot after crash). As the same image
    would be used for both boot scenarios, it could not be built optimally
    while accommodating both cases.

    Use --include to include the initramfs image built for offloading
    active crash dump to the specified dump target. Also, introduce a new
    out-of-tree dracut module (99zz-fadumpinit) that installs a customized
    init program while moving the default /init to /init.dracut. This
    customized init program is leveraged to isolate fadump image within
    the default initramfs image by kicking off default boot process
    (exec /init.dracut) for regular boot scenario and activating fadump
    initramfs image, if the system is booting after a crash.

    If squash is available, ensure default initramfs image is also built
    with squash module to reduce memory consumption in capture kernel.

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

Signed-off-by: Kairui Song <kasong@redhat.com>
2021-07-20 15:43:11 +08:00
Tao Liu
0fb5d148a2 Release 2.0.22-9
Resolves: bz1974638
Resolves: bz1977543

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-07-12 09:04:31 +08:00
Kairui Song
f5ffd4fd22 Add a crashkernel-howto.txt doc
Resolves: bz1974638
Upstream: Fedora
Conflict: None

commit 7dbbb4bb31
Author: Kairui Song <kasong@redhat.com>
Date:   Fri Jun 25 04:01:45 2021 +0800

    Add a crashkernel-howto.txt doc

    Signed-off-by: Kairui Song <kasong@redhat.com>
    Acked-by: Baoquan He <bhe@redhat.com>

Signed-off-by: Kairui Song <kasong@redhat.com>
2021-07-08 15:43:40 +08:00