Commit Graph

77 Commits

Author SHA1 Message Date
Coiby Xu
24020b226a powerpc: update kdumpctl to load kernel signing key for fadump
Resolves: https://issues.redhat.com/browse/RHEL-14003
Upstream: Fedora
Conflict: None

commit 4fa17b2ee4
Author: Nayna Jain <nayna@linux.ibm.com>
Date:   Tue Oct 3 23:41:47 2023 -0400

    powerpc: update kdumpctl to load kernel signing key for fadump

    On secure boot enabled systems with static keys, kexec with kexec_file_load(-s)
    fails as "Permission Denied" when fadump is enabled.

    Similar to kdump, load kernel signing key for fadump as well.

    Reported-by: Sachin P Bappalige <sachinpb@linux.vnet.ibm.com>
    Signed-off-by: Nayna Jain <nayna@linux.ibm.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-11-08 01:36:58 +00:00
Coiby Xu
b3263494ef powerpc: update kdumpctl to remove deletion of kernel signing key once loaded
Resolves: https://issues.redhat.com/browse/RHEL-14003
Upstream: Fedora
Conflict: None

commit fe6eb30e67
Author: Nayna Jain <nayna@linux.ibm.com>
Date:   Tue Oct 3 23:41:46 2023 -0400

    powerpc: update kdumpctl to remove deletion of kernel signing key once loaded

    Kernel signing key is deleted once kdump is loaded. This causes confusion in
    debugging since key is no longer visible. Unless someone knows how
    kdumpctl script works, it is difficult to find out how kdump could be
    loaded when there is no key on .ima keyring.

    Remove deletion of kernel signing key once loaded. And then to prevent
    multiple loading of same key when kdump service is disabled/enabled, update
    key description field as well.

    Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-11-08 01:36:58 +00:00
Lichen Liu
549f1f9495 Introduce a function to get reserved memory size
Resolves: bz2232499
Upstream: Fedora Rawhide
Conflict: None

commit 4b7b7736ee
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date:   Wed Aug 2 20:36:48 2023 +0530

    Introduce a function to get reserved memory size

    The size of the reserved memory in the functions show_reserved_mem,
    check_crash_mem_reserved, and do_estimate are fetched from the sysfs
    node `/sys/kernel/kexec_crash_size`. However, in the case of fadump,
    the reserved area size is instead present in
    /sys/kernel/fadump/mem_reserved.

    For example:

    $ kdumpctl showmem
    kdump: Dump mode is fadump
    kdump: Reserved 0MB memory for crash kernel

    The above command showed 0MB for Reserved memory which is incorrect, the
    actual reservation was 2048MB.

    To resolve this issue a new helper function is introduced to fetch
    reserved memory size based on the dump mode. For "fadump" mode,
    it looks in `/sys/kernel/fadump/mem_reserved`, otherwise, it uses
    `/sys/kernel/kexec_crash_size`. And all functions that previously
    fetching reserved memory directly from `/sys/kernel/kexec_crash_size`
    sysfs node are now updated to use this new function to get the reserved
    memory size.

    With the fix in place, the `kdumpctl showmem` command will now display
    correct reserved memory size.

    $ kdumpctl showmem
    kdump: Dump mode is fadump
    kdump: Reserved 2048MB memory for crash kernel

    Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
    Reported-by: Sachin P Bappalige <sachinpb@linux.vnet.ibm.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-09-21 16:24:52 +08:00
Lichen Liu
cbb7720e4f kdumpctl: merge check_current_{kdump,fadump}_status
Resolves: bz2232499
Upstream: Fedora Rawhide
Conflict: Some newer patches has been rebased, which caused git am to
encounter some problems.

commit b9fd7a4076
Author: Philipp Rudo <prudo@redhat.com>
Date:   Thu Jan 12 16:31:02 2023 +0100

    kdumpctl: merge check_current_{kdump,fadump}_status

    Both functions are almost identical. The only differences are (1) the
    sysfs node the status is read from and (2) the fact the fadump version
    doesn't verify if the file it's trying to read actually exists. Thus
    merge the two functions and get rid of the check_current_status wrapper.

    While at it rename the function to is_kernel_loaded which explains
    better what the function does.

    Finally, after moving FADUMP_REGISTER_SYS_NODE shellcheck can no longer
    access the definition and starts complaining about it not being quoted.
    Thus quote all uses of FADUMP_REGISTER_SYS_NODE.

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

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-09-21 15:02:51 +08:00
Lichen Liu
64c0bfcc53 kdumpctl: remove unnecessary uses of $?
Resolves: bz2232499
Upstream: Fedora Rawhide
Conflict: None

commit b49083126f
Author: Philipp Rudo <prudo@redhat.com>
Date:   Fri Mar 25 15:47:00 2022 +0100

    kdumpctl: remove unnecessary uses of $?

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

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-09-21 14:29:58 +08:00
Tao Liu
401619f484 kdumpctl: Fix temporary directory location
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2215606
Upstream: Fedora Rawhide
Conflict: None

commit dda81d72c2
Author: Philipp Rudo <prudo@redhat.com>
Date:   Mon Jun 19 14:31:48 2023 +0200

    kdumpctl: Fix temporary directory location

    The temporary directory is currently created under the current working
    directory. That alone isn't ideal but works most of the time. However,
    it will fail when the current working directory is not writable. So make
    sure the directory is created within TMPDIR.

    Fixes: ea00b7d ("kdumpctl: Move temp file in get_kernel_size to global temp dir")
    Signed-off-by: Philipp Rudo <prudo@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-06-21 16:02:14 +08:00
Pingfan Liu
6189736a11 kdumpctl: Fix the matching of plus symbol by grep's EREs
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676
Upstream: Fedora rawhide
Conflict: None

commit 64d93c886f
Author: Pingfan Liu <piliu@redhat.com>
Date:   Fri Jun 9 16:04:29 2023 +0800

    kdumpctl: Fix the matching of plus symbol by grep's EREs

    After introducing 64k variant kernel on aarch64, an example kernel name
    looks like "vmlinuz-5.14.0-316.el9.aarch64+64k". To match the plus
    symbol, it demands an escape charater.

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

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-15 10:36:54 +08:00
Pingfan Liu
cde55285bd kdump-lib: add support for 64K aarch64
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676
Upstream: Fedora rawhide
Conflict: None

commit 05c4861443
Author: Pingfan Liu <piliu at redhat.com>
Date:   Tue Jun 13 17:43:22 2023 +0800

    kdump-lib: add support for 64K aarch64

    On aarch64, both 4K and 64K kernel can be installed, while they demand
    different size reserved memory for kdump kernel.

    'get_conf PAGE_SIZE' can not work if installing a 64K kernel when
    running a 4K kernel. Hence resorting to the kernel release naming rules.
    At present, the 64K kernel has the keyword '64k' in its suffix.

    The base line for 64K is decided based on 4K. The diff 100M is picked up
    since on a high end machine without smmu enabled, the diff of MemFree is
    82M.

    As for the smmu case, a huge difference in the memory consumption lies
    between 64k and 4k driver. And it should be calculated separatedly.

    Signed-off-by: Pingfan Liu <piliu@redhat.com>
    Reviewed-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:34:54 +08:00
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
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
bcd5eb5a45 kdumpctl: Move temp file in get_kernel_size to global temp dir
Resolves: bz2169720
Upstream: src.fedoraproject.org/rpms/kexec-tools.git
Conflicts: None

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

    kdumpctl: Move temp file in get_kernel_size to global temp dir

    Others will need to use a temporary files, too. In order to avoid
    potential clashes of multiple trap handlers move the local temp file
    into a global temp dir.

    While at it make sure that the trap handler returns the correct exit
    code.

    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:10:30 +08:00
Tao Liu
27f67f14ee kdumpctl: Move get_kernel_size to kdumpctl
Resolves: bz2169720
Upstream: src.fedoraproject.org/rpms/kexec-tools.git
Conflicts: None

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

    kdumpctl: Move get_kernel_size to kdumpctl

    The function is only used in do_estimate. Move it to kdumpctl to
    prevent confusion.

    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:09:37 +08:00
Lichen Liu
3a3c3a924a kdumpctl: lower the log level in reset_crashkernel_for_installed_kernel
Resolves: bz2078176
Upstream: Fedora
Conflict: None

commit d619b6dabe
Author: Lichen Liu <lichliu@redhat.com>
Date:   Tue Apr 4 14:13:14 2023 +0800

    kdumpctl: lower the log level in reset_crashkernel_for_installed_kernel

    Although upgrading the kernel with `rpm -Uvh` is not recommended, the
    kexec-tools plugin prints confusing error logs when a customer upgrades the
    kernel through it.

    ```
    kdump: kernel 5.14.0-80.el9.x86_64 doesn't exist
    kdump: Couldn't find current running kernel
    ```

    Not finding the currently running kernel will only make kdump unable to copy the
    grub entry parameters to the newly installed kernel, so lower the log level.

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

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-05-06 11:19:16 +08:00
Lichen Liu
e47ec659e9 kdump-lib: clear up references to Atomic/CoreOS
Resolves: bz2174836
Upstream: Fedora
Conflict: None

commit 980f10aa40
Author: Dusty Mabe <dusty@dustymabe.com>
Date:   Wed Jun 22 11:58:31 2022 -0400

    kdump-lib: clear up references to Atomic/CoreOS

    There are many variants on OSTree based systems these days so
    we should probably refer to the class of systems as "OSTree
    based systems". Also, Atomic Host is dead.

    Signed-off-by: Dusty Mabe <dusty@dustymabe.com>
    Acked-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-03-07 10:40:52 +08:00
Coiby Xu
ae272e2df8 Reset crashkernel to default value if newly installed kernel has crashkernel=auto
Resolves: bz2168504
Upstream: RHEL-only

After leapp upgrade from 8.8 to 9.2 on Azure,  RHEL9 kernel has
crashkernel=auto. This happens because kexec-tools's posttrans scriptlet
is executed before kernel's posttrans scriptlet (which in turn runs the
kernel-install hooks). One of the kernel-install hook is responsible for
adding a new boot entry for the new kernel. So when kexec-tools's posttrans
scriptlet is running, RHEL9 kernel is yet to have a boot entry so
kexec-tools couldn't set up the crashkernel parameter. Later one
kernel-install hook makes RHEL9 kernel inherit crashkernel=auto.

Fix this issue by letting 92-crashkernel.install reset crashkernel=auto.

Reported-by: Yuxin Sun <yuxisun@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-02-23 09:21:47 +08:00
Coiby Xu
ef81bb9f44 Use the correct command to get architecture
Related: bz2060319
Upstream: Fedora
Conflict: None

commit 12e6cd2b76
Author: Coiby Xu <coxu@redhat.com>
Date:   Mon Feb 20 17:33:08 2023 +0800

    Use the correct command to get architecture

    `uname -r` was used by mistake. As a result, kexec-tools failed to
    update crashkernel=auto during in-place upgrade from RHEL8 to RHEL9.

    `uname -m` should be used to get architecture instead.

    Fixes: 5951b5e2 ("Don't try to update crashkernel when bootloader is not installed")

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-02-21 12:16:09 +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
73721c9a94 fadump: fix default initrd backup and restore logic
Resolves: bz2139000
Upstream: Fedora
Conflict: None

commit 25411da966
Author: Hari Bathini <hbathini@linux.ibm.com>
Date:   Fri Dec 2 18:46:50 2022 +0530

    fadump: fix default initrd backup and restore logic

    In case of fadump, default initrd is rebuilt with dump capturing
    capability, as the same initrd is used for booting production kernel
    as well as capture kernel.

    The original initrd file is backed up with a checksum, to restore
    it as the default initrd when fadump is disabled. As the checksum
    file is not kernel version specific, switching between different
    kernel versions and kdump/fadump dump mode breaks the default initrd
    backup/restore logic. Fix this by having a kernel version specific
    checksum file.

    Also, if backing up initrd fails, retaining the checksum file isn't
    useful. Remove it.

    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
5b2306b562 fadump: avoid status check while starting in fadump mode
Resolves: bz2139000
Upstream: Fedora
Conflict: None

commit a833624fe5
Author: Hari Bathini <hbathini@linux.ibm.com>
Date:   Mon Nov 21 18:56:08 2022 +0530

    fadump: avoid status check while starting in fadump mode

    With kernel commit 607451ce0aa9b ("powerpc/fadump: register for fadump
    as early as possible"), 'kdumpctl start' prematurely returns with the
    below message:

        "Kdump already running: [WARNING]"

    instead of setting default initrd with dump capture capability as
    required for fadump. Skip status check in fadump mode to avoid this
    problem.

    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
fd2521df50 kdumpctl: Optimize _find_kernel_path_by_release regex string
Resolves: bz2141536
Upstream: Fedora
Conflict: None

commit 5eb77ee3fa
Author: Lichen Liu <lichliu@redhat.com>
Date:   Thu Nov 24 09:15:25 2022 +0800

    kdumpctl: Optimize _find_kernel_path_by_release regex string

    Currently _find_kernel_path_by_release uses grubby and grep to
    find the kernel path, if both the normal kernel and it's debug
    varient exist, the grep will give more than one kernel strings.

    ```
    kernel="/boot/vmlinuz-5.14.0-139.kpq0.el9.s390x+debug"
    kernel="/boot/vmlinuz-5.14.0-139.kpq0.el9.s390x"
    ```

    This will cause an error when installing debug kernel.

    ```
    The param "/boot/vmlinuz-5.14.0-139.kpq0.el9.s390x+debug
    /boot/vmlinuz-5.14.0-139.kpq0.el9.s390x" is incorrect
    ```

    Fixes: 945cbbd ("add helper functions to get kernel path by kernel release and the path of current running kernel")

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

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2022-12-05 08:57:09 +00:00
Tao Liu
fb9545bb2a Don't check fs modified when dump target is lvm2 thinp
upstream: fedora
resolves: bz2083475
conflict: none

commit 3ae8cf8876
Author: Tao Liu <ltao@redhat.com>
Date:   Thu Nov 10 10:25:58 2022 +0800

    Don't check fs modified when dump target is lvm2 thinp

    When the dump target is lvm2 thinp, if we didn't mount
    the dump target first, get_fs_type_from_target will get
    empty output:

    Before mount:
    $ get_fs_type_from_target /dev/vg00/thinlv

    After mount:
    $ mount /dev/vg00/thinlv /mnt
    $ get_fs_type_from_target /dev/vg00/thinlv
    ext4

    As a result, kdumpctl start will fail with:
    $ kdumpctl start
    kdump: Dump target is invalid
    kdump: Starting kdump: [FAILED]

    This patch fix the issue by bypassing check_fs_modified
    when the dump target is lvm2 thinp.

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

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-11-11 11:53:13 +08:00
Tao Liu
b57b206d62 lvm.conf should be check modified if lvm2 thinp enabled
resolves: bz2083475
upstream: fedora
conflict: none

commit 10ca970940
Author: Tao Liu <ltao@redhat.com>
Date:   Sat Oct 8 15:41:40 2022 +0800

    lvm.conf should be check modified if lvm2 thinp enabled

    lvm2 relies on /etc/lvm/lvm.conf to determine its behaviour. The
    important configs such as thin_pool_autoextend_threshold and
    thin_pool_autoextend_percent will be used during kdump in 2nd
    kernel. So if the file is modified, the initramfs should be
    rebuild to include the latest.

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

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-11-09 15:57:28 +08:00
Coiby Xu
5309c08efa Include the memory overhead cost of cryptsetup when estimating the memory requirement for LUKS-encrypted target
Resolves: bz2076206
Upstream: Fedora
Conflict: None

commit 6ce4b85bb3
Author: Coiby Xu <coxu@redhat.com>
Date:   Mon Sep 5 18:08:44 2022 +0800

    Include the memory overhead cost of cryptsetup when estimating the memory requirement for LUKS-encrypted target

    Currently, "kdumpctl estimate" neglects the memory overhead cost of
    cryptsetup itself. Unfortunately, there is no golden formula to
    calculate the overhead cost [1]. So estimate the overhead cost as 50M
    for aarch64 and 20M for other architectures based on the following
    empirical data,

    | Overhead (M) | OS                                        | arch    |
    | ------------ | ----------------------------------------- | ------- |
    | 14.1         | RHEL-9.2.0-20220829.d.1                   | ppc64le |
    | 14           | Fedora-37-20220830.n.0 Everything ppc64le | ppc64le |
    | 17           | Fedora 36                                 | ppc64le |
    | 8.8          | Fedora 35                                 | s390x   |
    | 10.1         | Fedora-Rawhide-20220829.n.0, fc38         | s390x   |
    | 42           | Fedora-Rawhide-20220829.n.0, fc38         | arch64  |
    | 40           | F35                                       | arch64  |
    | 42           | F36                                       | arch64  |
    | 42           | Fedora-Rawhide-20220901.n.0               | arch64  |
    | 10           | F35                                       | x86_64  |
    | 10           | Fedora-Rawhide-20220901.n.0               | x86_64  |
    | 11           | Fedora-Rawhide-20220901.n.0               | x86_64  |

    [1] https://lore.kernel.org/cryptsetup/20220616044339.376qlipk5h2omhx2@Rk/T/#u

    Fixes: e9e6a2c ("kdumpctl: Add kdumpctl estimate")
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-11-01 02:38:40 +00:00
Coiby Xu
4757b08830 Choosing the most memory-consuming key slot when estimating the memory requirement for LUKS-encrypted target
Related: bz2076206
Upstream: Fedora
Conflict: None

commit 50a8461fc7
Author: Coiby Xu <coxu@redhat.com>
Date:   Mon Sep 5 17:49:18 2022 +0800

    Choosing the most memory-consuming key slot when estimating the
    memory requirement for LUKS-encrypted target

    When there are multiple key slots, "kdumpctl estimate" uses the least
    memory-consuming key slot. For example, when there are two memory slots
    created with --pbkdf-memory=1048576 (1G) and --pbkdf-memory=524288 (512M),
    "kdumpctl estimate" thinks the extra memory requirement is only 512M.
    This will of course lead to OOM if the user uses the more
    memory-consuming key slot. Fix it by sorting in reverse order.

    Fixes: e9e6a2c ("kdumpctl: Add kdumpctl estimate")
    Signed-off-by: Coiby Xu <coxu@redhat.com>

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-11-01 02:38:40 +00:00
Coiby Xu
7266bb9a7e Skip reading /etc/defaut/grub for s390x
Resolves: bz2133129
Upstream: Fedora
Conflict: None

commit fdad7d9869
Author: Coiby Xu <coxu@redhat.com>
Date:   Thu Sep 29 12:35:00 2022 +0800

    Skip reading /etc/defaut/grub for s390x

    Currently, updating kexec-tools on s390x gives the warning
    sed: can't read /etc/default/grub: No such file or directory

    This happens because s390x doesn't use GRUB and /etc/default/grub
    doesn't exist. We need to skip both reading and writing to
    /etc/default/grub.

    Reported-by: Jie Li <jieli@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-10-27 14:47:57 +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
Tao Liu
dcaec956e8 virtiofs support for kexec-tools
upstream: fedora
resolves: bz2085347
conflict: yes, small conflict due to patch
          "kdumpctl: drop DUMP_TARGET variable" not
          backported to rhel9.

commit c743881ae6
Author: Tao Liu <ltao@redhat.com>
Date:   Fri Sep 23 18:13:11 2022 +0800

    virtiofs support for kexec-tools

    This patch add virtiofs support for kexec-tools by introducing a new option
    for /etc/kdump.conf:

    virtiofs myfs

    Where myfs is a variable tag name specified in qemu cmdline
    "-device vhost-user-fs-pci,tag=myfs".

    The patch covers the following cases:
    1) Dumping VM's vmcore to a virtiofs shared directory;
    2) When the VM's rootfs is a virtiofs shared directory and dumping the
       VM's vmcore to its subdirectory, such as /var/crash;
    3) The combination of case 1 & 2: The VM's rootfs is a virtiofs shared
       directory and dumping the VM's vmcore to another virtiofs shared
       directory.

    Case 2 & 3 need dracut >= 057, otherwise VM cannot boot from virtiofs
    shared rootfs. But it is not the issue of kexec-tools.

    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:24:57 +08:00
Coiby Xu
e9088ae71a remove useless --zipl when calling grubby to update kernel command line
Related: bz2104534
Upstream: Fedora
Conflict: None

commit 58eef4582a
Author: Coiby Xu <coxu@redhat.com>
Date:   Tue Jul 12 16:07:37 2022 +0800

    remove useless --zipl when calling grubby to update kernel command line

    "grubby --zipl" only takes effect when setting default kernel. It's
    useless to add "--zipl" when updating kernel command line. Also rename
    _update_grub to _update_kernel_cmdline since s390x doesn't use GRUB.

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-09-19 09:10:54 +08:00
Coiby Xu
3aeb03c97e skip updating /etc/default/grub for s390x
Resolves: bz2104534
Upstream: Fedora
Conflict: None

commit e8ae897595
Author: Coiby Xu <coxu@redhat.com>
Date:   Tue Jul 12 14:06:25 2022 +0800

    skip updating /etc/default/grub for s390x

    Resolves: bz2104534

    When running "kdumpctl reset-crashkernel --kernel=ALL" on s390x,
    sed: can't read /etc/default/grub: No such file or directory
    sed: can't read /etc/default/grub: No such file or directory

    This happens because s390x doesn't use the grub bootloader and
    /etc/default/grub doesn't exist.

    Reported-by: smitterl@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-09-19 09:10:54 +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
Lichen Liu
bd92125753 kdumpctl: make the kdump.log root-readable-only
Resolves: bz2111857
Upstream: Fedora
Conflict: None

commit 4edcd9a400
Author: Lichen Liu <lichliu@redhat.com>
Date:   Wed Aug 24 16:16:14 2022 +0800

    kdumpctl: make the kdump.log root-readable-only

    Decrease the risk that of leaking information that could potentially
    be used to exploit the crash further (think location of keys).

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

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2022-09-07 11:35:38 +08:00
Tao Liu
dd05affb9f try to update the crashkernel in GRUB_ETC_DEFAULT after kexec-tools updates the default crashkernel value
Upstream: fedora
Conflict: none
Resolves: bz2060774

commit 6d4062a936
Author: Coiby Xu <coxu@redhat.com>
Date:   Wed Feb 16 09:42:54 2022 +0800

    try to update the crashkernel in GRUB_ETC_DEFAULT after kexec-tools updates the default crashkernel value

    If GRUB_ETC_DEFAULT use crashkernel=auto or
    crashkernel=OLD_DEFAULT_CRASHKERNEL, it should be updated as well.

    Add a helper function to read kernel cmdline parameter from
    GRUB_ETC_DEFAULT. This function is used to read kernel cmdline
    parameter like fadump or crashkernel.

    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-04-08 15:20:04 +08:00
Tao Liu
738bf03f04 address the case where there are multiple values for the same kernel arg
Resolves: bz2060774
Upstream: fedora
Conflict: none

commit 37f4f2c1f6
Author: Coiby Xu <coxu@redhat.com>
Date:   Tue Feb 15 13:24:19 2022 +0800

    address the case where there are multiple values for the same kernel arg

    There is the case where there are multiple entries of the same parameter on
    the command line, e.g.
    GRUB_CMDLINE_LINUX="crashkernel=110M crashkernel=220M fadump=on crashkernel=330M".

    In such an situation _update_kernel_cmdline_in_grub_etc_default only
    updates/removes the last entry which is usually not what you want as the
    kernel (for crashkernel) takes the last entry it can find.

    Thus make sure the case with multiple entries of the same parameter is
    handled properly by removing all occurrences of given parameter first.

    Note
    1. sed command group and conditional control has been used to get rid of
       grep.
    2. Fully supporting kernel cmdline as documented in
       Documentation/admin-guide/kernel-parameters.rst is complex and in
       foreseeable future a full implementation is not needed. So simply
       document the unsupported cases instead.

    Fixes: 140da74 ("rewrite reset_crashkernel to support fadump and to used by RPM scriptlet")

    Reported-by: Philipp Rudo <prudo@redhat.com>
    Suggested-by: Philipp Rudo <prudo@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
2022-04-08 15:19:47 +08:00
Coiby Xu
9b4f6070ec fix incorrect usage of _get_all_kernels_from_grubby
Related: bz1895258
Upstream: Fedora
Conflict: None

commit 41b8f9528c
Author: Coiby Xu <coxu@redhat.com>
Date:   Wed Feb 9 08:04:39 2022 +0800

    fix incorrect usage of _get_all_kernels_from_grubby

    It's found that the kernel cmdline crashkernel=auto doesn't get updated
    when upgrading kexec-tools. This happens because _get_all_kernels_from_grubby
    is called with no argument by reset_crashkernel_after_update. When retrieving
    all kernel paths on the system, "grubby --info ALL" should be used. Fix this
    error by passing "ALL" argument.

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

    Reported-by: Jie Li <jieli@redhat.com>
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Tao Liu <ltao@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-02-14 11:04:47 +08:00
Coiby Xu
7a61e066b7 fix the mistake of swapping function parameters of read_proc_environ_var
Resolves: bz2024976
Upstream: Fedora
Conflict: None

commit 5111c01334
Author: Coiby Xu <coxu@redhat.com>
Date:   Mon Feb 7 08:08:01 2022 +0800

    fix the mistake of swapping function parameters of read_proc_environ_var

    _is_osbuild fails because it expects the 1st and 2nd function parameter
    to be the environment variable and environ file path respectively. Fix
    it by swapping the parameters in read_proc_environ_var.

    Note the osbuild environ file path is defined in _OSBUILD_ENVIRON_PATH
    so _is_osbuild can be unit-tested by overwriting _OSBUILD_ENVIRON_PATH.

    Fixes: 6a3ce83 ("fix the error of parsing the container environ variable for osbuild")
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Pingfan Liu <piliu@redhat.com>
2022-02-08 11:14:53 +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
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
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
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
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
Tao Liu
b494b7f193 bash scripts: reformat with shfmt
upstream: fedora
resolves: bz2003832
conflict:
    function load_kdump_kernel_key() not exist in rhel9,
    so related patch hunk is removed.

commit 0e4b66b1ab
Author: Kairui Song <kasong@redhat.com>
Date:   Tue Sep 14 02:25:40 2021 +0800

    bash scripts: reformat with shfmt

    This is a batch update done with:
    shfmt -s -w mkfadumprd mkdumprd kdumpctl *-module-setup.sh

    Clean up code style and reduce code base size, no behaviour change.

    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:42:45 +08:00