Commit Graph

59 Commits

Author SHA1 Message Date
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
Tao Liu
63308480fc bash scripts: declare and assign separately
upstream: fedora
resolves: bz2003832
conflict: none

commit 4f75e16700
Author: Kairui Song <kasong@redhat.com>
Date:   Wed Aug 18 02:04:45 2021 +0800

    bash scripts: declare and assign separately

    Declare and assign separately to avoid masking return values:
    https://github.com/koalaman/shellcheck/wiki/SC2155

    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:37:15 +08:00
Tao Liu
f6d6b60a6a bash scripts: fix redundant exit code check
upstream: fedora
resolves: bz2003832
conflict: none

commit a4648fc851
Author: Kairui Song <kasong@redhat.com>
Date:   Wed Sep 8 17:23:16 2021 +0800

    bash scripts: fix redundant exit code check

    As suggested by:
    https://github.com/koalaman/shellcheck/wiki/SC2181

    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:35:45 +08:00
Tao Liu
bf4667b866 bash scripts: fix variable quoting issue
upstream: fedora
resolves: bz2003832
conflict:
    function remove_kdump_kernel_key() not presented in rhel9,
    so related patch hunk are removed.

commit 86538ca6e2
Author: Kairui Song <kasong@redhat.com>
Date:   Wed Sep 8 17:21:41 2021 +0800

    bash scripts: fix variable quoting issue

    Fixed quoting issues found by shellcheck, no feature
    change. This should fix many errors when there is space
    in any shell variables, eg. dump target's name/path/id.

    False positives are marked with "# shellcheck disable=SCXXXX", for
    example, args are expected to split so it should not be quoted.

    And replaced some `cut -d ' ' -fX` with `awk '{print $X}'` since cut
    is fragile, and doesn't work well with any quoted strings that have
    redundant space.

    Following quoting related issues are fixed (check the link
    for example code and what could go wrong):

    https://github.com/koalaman/shellcheck/wiki/SC2046
    https://github.com/koalaman/shellcheck/wiki/SC2053
    https://github.com/koalaman/shellcheck/wiki/SC2068
    https://github.com/koalaman/shellcheck/wiki/SC2086
    https://github.com/koalaman/shellcheck/wiki/SC2206

    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:27:55 +08:00
Tao Liu
dcb59c30d5 bash scripts: replace '[ ]' with '[[ ]]' for bash scripts
upstream: fedora
resolves: bz2003832
conflict:
    function load_kdump_kernel_key() not presented in rhel9,
    so related patch hunk are removed.

commit 70978c00e5
Author: Kairui Song <kasong@redhat.com>
Date:   Wed Sep 8 17:20:51 2021 +0800

    bash scripts: replace '[ ]' with '[[ ]]' for bash scripts

    kdumpctl, mkdumprd, *-module-setup.sh only target bash, since they
    only run in first kernel and depend on dracut, and dracut depends
    on bash. So use '[[ ]]' to replace '[ ]'.

    This is a batch update done with following command:
    `sed -i -e 's/\(\s\)\[\s\([^]]*\)\s\]/\1\[\[\ \2 \]\]/g' kdumpctl, mkdumprd, *-module-setup.sh`
    and replaced [ ... -a ... ] with [[ ... ]] && [[ ... ]] manually.

    See https://tldp.org/LDP/abs/html/testconstructs.html for more details
    on '[[ ]]', it's more versatile, safer, and slightly faster than '[ ]'.

    This will also help shfmt to clean up the code in later commits.

    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:13:59 +08:00
Tao Liu
16c2821171 bash scripts: use $(...) notation instead of legacy ...
upstream: fedora
resolves: bz2003832
conflict: none

commit 54cc5c44be
Author: Kairui Song <kasong@redhat.com>
Date:   Wed Sep 8 01:48:52 2021 +0800

    bash scripts: use $(...) notation instead of legacy `...`

    This is a batch update done with following command:

    `sed -i -e 's/`\([^`]*\)`/\$(\1)/g' mkfadumprd mkdumprd \
     kdumpctl dracut-module-setup.sh dracut-fadump-module-setup.sh \
     dracut-early-kdump-module-setup.sh`

    And manually converted some corner cases. This fixes
    all related issues detected by shellcheck.
    Make it easier to do clean up in later commits.

    Check following link for reasons to switch to the new syntax:
    https://github.com/koalaman/shellcheck/wiki/SC2006

    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 20:39:50 +08:00
Tao Liu
67611bba2a bash scripts: always use "read -r"
upstream: fedora
resolves: bz2003832
conflict: none

commit a416930706
Author: Kairui Song <kasong@redhat.com>
Date:   Wed Aug 4 15:50:30 2021 +0800

    bash scripts: always use "read -r"

    This helps to strip spaces and avoid mangling backslashes:

    https://github.com/koalaman/shellcheck/wiki/SC2162

    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 20:39:17 +08:00
Tao Liu
480de7c63d bash scripts: get rid of expr and let
upstream: fedora
resolves: bz2003832
conflict: none

commit c4d85142be
Author: Kairui Song <kasong@redhat.com>
Date:   Wed Aug 4 15:18:59 2021 +0800

    bash scripts: get rid of expr and let

    As suggested by:
    https://github.com/koalaman/shellcheck/wiki/SC2219

    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 20:39:02 +08:00
Tao Liu
e07098aa14 bash scripts: remove useless cat
upstream: fedora
resolves: bz2003832
conflict:
    load_kdump_kernel_key() didn't present in rhel9,
    so removed the patch for it.

commit 6d45257cc1
Author: Kairui Song <kasong@redhat.com>
Date:   Wed Aug 4 15:14:00 2021 +0800

    bash scripts: remove useless cat

    Some `cat` calls are useless, remove them to make it cleaner.
    See: https://github.com/koalaman/shellcheck/wiki/SC2002

    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 20:38:55 +08:00
Tao Liu
e35e4054ca kdumpctl: refine grep usage
upstream: fedora
resolves: bz2003832
conflict: none

commit 80525aface
Author: Kairui Song <kasong@redhat.com>
Date:   Wed Aug 4 15:44:02 2021 +0800

    kdumpctl: refine grep usage

    Use `grep -q` instead of redirect to /dev/null.

    Use `grep -c` instead, as suggested in:
    https://github.com/koalaman/shellcheck/wiki/SC2126

    Use `grep -E` instead of `egrep`.
    https://github.com/koalaman/shellcheck/wiki/SC2196

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

Signed-off-by: Tao Liu <ltao@redhat.com>
2021-11-03 16:10:36 +08:00
Tao Liu
6c43817d23 kdumpctl: fix fragile loops over find output
upstream: fedora
resolves: bz2003832
conflict: none

commit dfb76467c9
Author: Kairui Song <kasong@redhat.com>
Date:   Wed Aug 4 16:22:17 2021 +0800

    kdumpctl: fix fragile loops over find output

    For loops over find output are fragile, use a while read loop:
    https://github.com/koalaman/shellcheck/wiki/SC2044

    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-03 16:10:13 +08:00
Tao Liu
6afe4ea23f kdumpctl: use kdump_get_conf_val to read config values
upstream: fedora
resolves: bz2003832
conflict: none

commit 01613b7211
Author: Kairui Song <kasong@redhat.com>
Date:   Tue Aug 3 22:50:02 2021 +0800

    kdumpctl: use kdump_get_conf_val to read config values

    Also fixed kdumpctl, use `awk` instead of `cut` to read
    core_collector's executable name correctly when its arguments
    are not seperated by space.

    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-03 16:09:49 +08:00
Tao Liu
14205c1d6f kdump-lib.sh: add a config value retrive helper
upstream: fedora
resolves: bz2003832
conflict: none

commit 09ccf88405
Author: Kairui Song <kasong@redhat.com>
Date:   Mon Aug 16 23:25:14 2021 +0800

    kdump-lib.sh: add a config value retrive helper
    Add a helper kdump_get_conf_val to replace get_option_value.

    It can help cover more corner cases in the code, like when there are
    multiple spaces in config file, config value separated by a tab,
    heading spaces, or trailing comments.

    And this uses "sed group command" and "sed hold buffer", make it much
    faster than previous `grep <config> | tail -1`.

    This helper is supposed to provide a universal way for kexec-tools
    scripts to read in config value. Currently, different scripts are
    reading the config in many different fragile ways.

    For example, following codes are found in kexec-tools script code base:
      1. grep ^force_rebuild $KDUMP_CONFIG_FILE
	 echo $_force_rebuild | cut -d' '  -f2

      2. grep ^kdump_post $KDUMP_CONFIG_FILE | cut -d\  -f2

      3. awk '/^sshkey/ {print $2}' $conf_file

      4. grep ^path $KDUMP_CONFIG_FILE | cut -d' '  -f2-

    1, 2, and 4 will fail if the space is replaced by, e.g. a tab

    1 and 2 might fail if there are multiple spaces between config name
    and config value:
    "kdump_post  /var/crash/scripts/kdump-post.sh"
    A space will be read instead of config value.

    1, 2, 3 will fail if there are space in file path, like:
    "kdump_post /var/crash/scripts dir/kdump-post.sh"

    4 will fail if there are trailing comments:
    "path /var/crash # some comment here"

    And all will fail if there are heading space,
    " path /var/crash"

    And all will most likely cause problems if the config file contains
    the same option more than once.

    And all of them are slower than the new sed call. Old get_option_value
    is also very slow and doesn't handle heading space.

    Although we never claim to support heading space or tailing comments
    before, it's harmless to be more robust on config reading, and many
    conf files in /etc support heading spaces. And have a faster and
    safer config reading helper makes it easier to clean up the code.

    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-03 16:08:50 +08:00
Tao Liu
67b8dd1cb8 kdump-lib.sh: add a config format and read helper
upstream: fedora
resolves: bz2003832
conflict: none

commit a0282ab22c
Author: Kairui Song <kasong@redhat.com>
Date:   Tue Aug 3 19:49:51 2021 +0800

    kdump-lib.sh: add a config format and read helper

    Add a helper `kdump_read_conf` to replace read_strip_comments.
    `kdump_read_conf` does a few more things:

      - remove trailing spaces.
      - format the content, remove duplicated spaces between name and value.
      - read from KDUMP_CONFIG_FILE (/etc/kdump.conf) directly, avoid pasting
	"/etc/kdump.conf" path everywhere in the code.
      - check if config file exists, just in case.

    Also unify the environmental variable, now KDUMP_CONFIG_FILE stands for
    the default config location.

    This helps avoid some shell pitfalls about spaces when reading config.

    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-03 16:08:22 +08:00
Kairui Song
f3db4acbcf Clear old crashkernl=auto in comment and doc
Resolves: bz1986250
Upstream: Fedora

commit 097059dedc
Author: Kairui Song <kasong@redhat.com>
Date:   Fri Jul 30 14:40:45 2021 +0800

    Clear old crashkernl=auto in comment and doc

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

Signed-off-by: Kairui Song <kasong@redhat.com>
2021-08-06 01:33:34 +00:00
Kairui Song
6cc04b5313 kdumpctl: fix a typo
Resolves: bz1981684
Conflict: Minor conflict resolved easily
Upstream: Fedora

commit bcd8d6a47b
Author: Kairui Song <kasong@redhat.com>
Date:   Thu Jul 15 03:08:28 2021 +0800

    kdumpctl: fix a typo

    Recommanded -> Recommended

    Signed-off-by: Kairui Song <kasong@redhat.com>
    Acked-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Kairui Song <kasong@redhat.com>
2021-07-30 09:21:21 +00:00
Kairui Song
8e51ebe6fb fadump: kdumpctl should check the modules used by the fadump initramfs
Resolves: bz1924115
Conflict: None
Upstream: Fedora

commit bf6671b60d
Author: Kairui Song <kasong@redhat.com>
Date:   Fri Jun 25 14:44:45 2021 +0800

    fadump: kdumpctl should check the modules used by the fadump initramfs

    After fadump embedded the fadump initramfs in the normal initramfs,
    kdumpctl will mistakenly rebuild the initramfs everytime.

    kdumpctl checks the hostonly-kernel-modules.txt file in initramfs
    to check if required drivers are included, but the normal initramfs
    is built in non-hostonly mode, so it doesn't have a
    hostonly-kernel-modules.txt file. The check will always fail.

    So let mkfadumprd make a copy of the hostonly-kernel-modules.txt in the
    fadump initramfs and let kdumpctl check that file instead.

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

Signed-off-by: Kairui Song <kasong@redhat.com>
2021-07-20 15:43:26 +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
Kairui Song
a0fe51b32e kdumpctl: Add kdumpctl reset-crashkernel
Resolves: bz1974638
Upstream: Fedora
Conflict: None

commit 86130ec10f
Author: Kairui Song <kasong@redhat.com>
Date:   Thu Jun 10 13:06:22 2021 +0800

    kdumpctl: Add kdumpctl reset-crashkernel

    In newer kernel, crashkernel.default will contain the default
    crashkernel value of a kernel build. So introduce a new sub command
    to help user reset kernel crashkernel size to the default value.

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