rpms/kexec-tools
5
0
Fork 0
Code Issues Pull Requests Releases Activity
398 Commits 9 Branches 67 Tags 3.4 MiB
fc66e25f7b
Commit Graph

9 Commits

Author SHA1 Message Date
Tao Liu
fc66e25f7b Re-introduce vmcore creation notification to kdump 
Upstream: fedora
Resolves: RHEL-70214
Conflict: Yes, the conflict is the same as the original c9s commit
	  c5aa4609 ("Introduce vmcore creation notification to kdump")
	  9ec61f6c ("Return the correct exit code of rebuild initrd")
          Also this patch cherry-picked the ipv6 fixed in [1].

[1]: https://github.com/rhkdump/kdump-utils/pull/60/files

commit 24e76222c740def1d03a506652400fe55959e024
Author: Tao Liu <ltao@redhat.com>
Date:   Fri Nov 29 16:15:18 2024 +1300

    Re-introduce vmcore creation notification to kdump

    Motivation
    ==========

    People may forget to recheck to ensure kdump works, which as a result, a
    possibility of no vmcores generated after a real system crash. It is
    unexpected for kdump.

    It is highly recommended people to test kdump after any system modification,
    such as:

    a. after kernel patching or whole yum update, as it might break something
       on which kdump is dependent, maybe due to introduction of any new bug etc.
    b. after any change at hardware level, maybe storage, networking,
       firmware upgrading etc.
    c. after implementing any new application, like which involves 3rd party modules
       etc.

    Though these exceed the range of kdump, however a simple vmcore creation
    status notification is good to have for now.

    Design
    ======

    Kdump currently will check any relating files/fs/drivers modified before
    determine if initrd should rebuild when (re)start. A rebuild is an
    indicator of such modification, and kdump need to be tested. This will
    clear the vmcore creation status specified in $VMCORE_CREATION_STATUS,
    and as a result, a notification of vmcore creation test will be
    outputted.

    To test kdump, there is an entry for doing that by "kdumpctl test". It
    will generate a timestamp string as the ID of the current test, along
    with a "pending" status in $VMCORE_CREATION_STATUS, then a real crash &
    dump process will be triggered.

    After system reboot back to normal, a vmcore creation check will start at
    "kdumpctl (re)start/status", and will report the results as
    success/fail/manual status to users.

    To achieve that, program will first check the status in $VMCORE_CREATION_STATUS.
    If "pending" status if found, which means the test result is
    undetermined and need a retrive from remote/local dump folder. Then if test
    id is found in the dump folder and vmcore is complete, then "pending"
    would be overwritten by "success", which indicates a successful kdump
    test. If test id is found in the dump folder but vmcore is incomplete,
    then it is a "fail" kdump test. If no test id is found, then it is a "manual"
    status, which indicates users should check the test results manually.

    If $VMCORE_CREATION_STATUS is already success/fail/manual status, it indicates
    the test result has already been determined, so the program will not access
    the remote/local dump folder again. This can limite any unnecessary
    access to dump target, shorten the time consumption.

    User should check for the root cause of fail/manual status when get
    reports.

    $VMCORE_CREATION_STATUS is used for recording the vmcore creation status of
    the current env. The format is like:

       <status> kdump_test_id=<timestamp sec>-<timestamp nanosec>
    e.g:
       success kdump_test_id=1729823462-938751820

    Which means, there has been a successful kdump test at
    $(date -d "@1729823462") timestamp for the current env. Timestamp
    nanosec is only meaningful for uniquify id string.

    Difference
    ==========
    Previously there is one commit 88525ebf ("Introduce vmcore creation
    notification to kdump") merged and addressing the same issue, but
    implemented differently:

    The prev one:
    Save the $VMCORE_CREATION_STATUS to local drive during the 2nd kernel
    dumping. If vmcore dumping target is different from $VMCORE_CREATION_STATUS's
    drive, then the latter one need to be mounted in 2nd kernel.

    This one:
    Save the $VMCORE_CREATION_STATUS to local drive only in 1nd kernel, that
    is, the test result is retrived after 2nd kernel dumping. So it doesn't
    load or mount other drive in 2nd kernel.

    The advantage:
    Extra mounting in 2nd kernel will introduce higher risk of failure,
    as a result, lower the success of vmcore dumping, which is
    unaccepted. So keep the code for 2nd kernel as simple is preferred.

    Usage
    =====
    [root@localhost ~]# kdumpctl restart
    kdump: kexec: unloaded kdump kernel
    kdump: Stopping kdump: [OK]
    kdump: kexec: loaded kdump kernel
    kdump: Starting kdump: [OK]
    kdump: Notice: No vmcore creation test performed!

    [root@localhost ~]# kdumpctl status
    kdump: Kdump is operational
    kdump: Notice: No vmcore creation test performed!

    [root@localhost ~]# kdumpctl test

    [root@localhost ~]# cat /var/lib/kdump/vmcore-creation.status
    pending kdump_test_id=1729823462-938751820

    [root@localhost ~]# kdumpctl status
    kdump: Kdump is operational
    kdump: Notice: Last successful vmcore creation on Fri Oct 25 02:31:02 AM UTC 2024

    [root@localhost ~]# cat /var/lib/kdump/vmcore-creation.status
    success kdump_test_id=1729823462-938751820

    [root@localhost ~]# kdumpctl restart
    kdump: kexec: unloaded kdump kernel
    kdump: Stopping kdump: [OK]
    kdump: kexec: loaded kdump kernel
    kdump: Starting kdump: [OK]
    kdump: Notice: Last successful vmcore creation on Fri Oct 25 02:31:02 AM UTC 2024

    Note: the notification for kdumpctl (re)start/status can be disabled by
    setting VMCORE_CREATION_NOTIFICATION in /etc/sysconfig/kdump. And fadump
    is NOT supported for this feature.

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

Signed-off-by: Tao Liu <ltao@redhat.com>
 2024-12-06 15:27:20 +13:00
Tao Liu
79aec45f8c Revert "Introduce vmcore creation notification to kdump" 
Resolves: RHEL-70214
Upstream: fedora
Conflict: Yes, the conflict is the same as the original c9s commit
          c5aa4609 ("Introduce vmcore creation notification to kdump")
          9ec61f6c ("Return the correct exit code of rebuild initrd")

commit 96956928a66d9256cdf8bfed6a8963ddea35aac9
Author: Tao Liu <ltao@redhat.com>
Date:   Fri Nov 29 14:42:01 2024 +1300

    Revert "Introduce vmcore creation notification to kdump"

    This patch will revert the following 2 patches:

        88525ebf ("Introduce vmcore creation notification to kdump")
        35449537 ("Return the correct exit code of rebuild initrd")

    For the preparation of reimplementation of vmcore creation notification.

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

Signed-off-by: Tao Liu <ltao@redhat.com>
 2024-12-06 11:25:25 +13:00
Tao Liu
c5aa460992 Introduce vmcore creation notification to kdump 
Upstream: fedora
Resolves: RHEL-32060
Conflict: Yes, there are several conflicts. 1) Upstream have moved
          dracut-kdump.sh into kdump-utils/dracut/99kdumpbase/kdump.sh,
          so the targeting files are changed. 2) There are several
          patchsets([1] [2]) which not backported to rhel9, so some
          formating conflicts encountered. But there is no functional
          change been made for the patch backporting.

[1]: https://github.com/rhkdump/kdump-utils/pull/18/commits
[2]: https://github.com/rhkdump/kdump-utils/pull/33/commits

commit 88525ebf5e43cc86aea66dc75ec83db58233883b
Author: Tao Liu <ltao@redhat.com>
Date:   Thu Sep 5 15:49:07 2024 +1200

    Introduce vmcore creation notification to kdump

    Motivation
    ==========

    People may forget to recheck to ensure kdump works, which as a result, a
    possibility of no vmcores generated after a real system crash. It is
    unexpected for kdump.

    It is highly recommended people to recheck kdump after any system
    modification, such as:

    a. after kernel patching or whole yum update, as it might break something
       on which kdump is dependent, maybe due to introduction of any new bug etc.
    b. after any change at hardware level, maybe storage, networking,
       firmware upgrading etc.
    c. after implementing any new application, like which involves 3rd party modules
       etc.

    Though these exceed the range of kdump, however a simple vmcore creation
    status notification is good to have for now.

    Design
    ======

    Kdump currently will check any relating files/fs/drivers modified before
    determine if initrd should rebuild when (re)start. A rebuild is an
    indicator of such modification, and kdump need to be rechecked. This will
    clear the vmcore creation status specified in $VMCORE_CREATION_STATUS.

    Vmcore creation check will happen at "kdumpctl (re)start/status", and will
    report the creation success/fail status to users. A "success" status indicates
    previously there has been a vmcore successfully generated based on the current
    env, so it is more likely a vmcore will be generated later when real crash
    happens; A "fail" status indicates previously there was no vmcore
    generated, or has been a vmcore creation failed based on current env. User
    should check the 2nd kernel log or the kexec-dmesg.log for the failing reason.

    $VMCORE_CREATION_STATUS is used for recording the vmcore creation status of
    the current env. The format will be like:

       success 1718682002

    Which means, there has been a vmcore generated successfully at this
    timestamp for the current env.

    Usage
    =====

    [root@localhost ~]# kdumpctl restart
    kdump: kexec: unloaded kdump kernel
    kdump: Stopping kdump: [OK]
    kdump: kexec: loaded kdump kernel
    kdump: Starting kdump: [OK]
    kdump: Notice: No vmcore creation test performed!

    [root@localhost ~]# kdumpctl test

    [root@localhost ~]# kdumpctl status
    kdump: Kdump is operational
    kdump: Notice: Last successful vmcore creation on Tue Jun 18 16:39:10 CST 2024

    [root@localhost ~]# kdumpctl restart
    kdump: kexec: unloaded kdump kernel
    kdump: Stopping kdump: [OK]
    kdump: kexec: loaded kdump kernel
    kdump: Starting kdump: [OK]
    kdump: Notice: Last successful vmcore creation on Tue Jun 18 16:39:10 CST 2024

    The notification for kdumpctl (re)start/status can be disabled by
    setting VMCORE_CREATION_NOTIFICATION in /etc/sysconfig/kdump

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

Signed-off-by: Tao Liu <ltao@redhat.com>
 2024-10-08 18:23:12 +13:00
Philipp Rudo
66e9c9277c kdumpctl.8: Add description to reset-crashkernel --reboot 
Resolves: RHEL-42442
Resolves: RHEL-22171

commit 2c741555d9749e9a137378332e561382f9e25739
Author: Philipp Rudo <prudo@redhat.com>
Date:   Mon Jul 1 12:52:39 2024 +0200

    kdumpctl.8: Add description to reset-crashkernel --reboot

    There is no description for parameter --reboot for reset-crashkernel.
    Thus add one.

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

Signed-off-by: Philipp Rudo <prudo@redhat.com>
 2024-07-11 12:17:39 +02:00
Coiby Xu
0e3a77330e add man documentation for kdumpctl get-default-crashkernel 
Resolves: bz2073676
Upstream: Fedora
Conflict: None

commit a1c63fa644
Author: Coiby Xu <coxu@redhat.com>
Date:   Tue Mar 1 17:35:39 2022 +0800

    add man documentation for kdumpctl get-default-crashkernel

    A few typos and grammar issues are fixed as well.

    Philipp Rudo <prudo@redhat.com>

    Signed-off-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
 2022-05-17 09:23:10 +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
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
Kairui Song
a9fda5c885 kdumpctl: Add kdumpctl estimate 
Resolves: bz1951415
Upstream: fedora
Conflict: none

commit e9e6a2c745
Author: Kairui Song <kasong@redhat.com>
Date:   Thu Apr 22 03:27:10 2021 +0800

    kdumpctl: Add kdumpctl estimate

    Add a rough esitimation support, currently, following memory usage are
    checked by this sub command:

    - System RAM
    - Kdump Initramfs size
    - Kdump Kernel image size
    - Kdump Kernel module size
    - Kdump userspace user and other runtime allocated memory (currently
      simply using a fixed value: 64M)
    - LUKS encryption memory usage

    The output of kdumpctl estimate looks like this:
      # kdumpctl estimate
      Reserved crashkernel:    256M
      Recommanded crashkernel: 160M

      Kernel image size:   47M
      Kernel modules size: 12M
      Initramfs size:      19M
      Runtime reservation: 64M
      Large modules:
          xfs: 1892352
          nouveau: 2318336

    And if the kdump target is encrypted:
      # kdumpctl estimate
      Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement

      Reserved crashkernel:    256M
      Recommanded crashkernel: 655M

      Kernel image size:   47M
      Kernel modules size: 12M
      Initramfs size:      19M
      Runtime reservation: 64M
      LUKS required size:  512M
      Large modules:
          xfs: 1892352
          nouveau: 2318336
      WARNING: Current crashkernel size is lower than recommanded size 655M.

    The "Recommanded" value is calculated based on memory usages mentioned
    above, and will be adjusted accodingly to be no less than the value provided
    by kdump_get_arch_recommend_size.

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

Signed-off-by: Kairui Song <kasong@redhat.com>
 2021-05-20 16:08:16 +08:00
Petr Šabata
f5bf4978d8 RHEL 9.0.0 Alpha bootstrap 
The content of this branch was automatically imported from Fedora ELN
with the following as its source:
https://src.fedoraproject.org/rpms/kexec-tools#041ba89902961b5490a7143d9596dc00d732cba0
 2020-10-15 14:45:57 +02:00