Commit Graph

670 Commits

Author SHA1 Message Date
Coiby Xu
e218128e28 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>
2022-10-20 13:54:10 +08:00
Coiby Xu
a7ead187a4 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>
2022-10-20 13:54:10 +08:00
Tao Liu
fc1c79ffd2 Seperate dracut and dracut-squash compressor for zstd
Previously kexec-tools will pass "--compress zstd" to dracut. It
will make dracut to decide whether: a) call mksquashfs to make a
zstd format squash-root.img, b) call cmd zstd to make a initramfs.

Since dracut(>= 057) has decoupled the compressor for dracut and
dracut-squash, So in this patch, we will pass the compressor seperately.

Note:

The is_squash_available && !dracut_has_option --squash-compressor
&& !is_zsdt_command_available case is left unprocessed on purpose.

Actually, the situation when we want to call zstd compression is:
1) If squash function OK, we want dracut to invoke mksquashfs to make
a zstd format squash-root.img within initramfs.
2) If squash function is not OK, and cmd zstd presents, we want dracut
to invoke cmd zstd to make a zstd format initramfs.

is_zstd_command_available check can handle case 2 completely.

However, for the is_squash_available check, it cannot handle case 1
completely. It only checks if the kernel supports squashfs, it doesn't
check whether the squash module has been added by dracut when making
initramfs. In fact, in kexec-tools we are unable to do the check,
there are multiple ways to forbit dracut to load a module, such as
"dracut -o module" and "omit_dracutmodules in dracut.conf".

When squash dracut module is omitted, is_squash_available check will
still pass, so "--compress zstd" will be appended to dracut cmdline,
and it will call cmd zstd to do the compression. However cmd zstd may
not exist, so it fails.

The previous "--compress zstd" is ambiguous, after the intro of
"--squash-compressor", "--squash-compressor" only effect for
mksquashfs and "--compress" only effect for specific cmd.

So for the is_squash_available && !dracut_has_option
--squash-compressor && !is_zsdt_command_available case, we just leave
it to be handled the default way.

Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
2022-10-20 12:26:37 +08:00
Kairui Song
677da8a59b sysconfig: use a simple generator script to maintain
These kdump.sysconfig.* files are almost identical with a bit difference
in several parameters, just use a simple script to generate them upon
packaging. This should make it easier to maintain, updating a comment or
param for a certain arch can be done in one place.

There are only some comment or empty option differences with the generated
version because some arch's sysconfig is not up-to-dated, this actually
fixes the issue, I used the following script to check these differences:

 # for arch in aarch64 i386 ppc64 ppc64le s390x x86_64; do
   ./gen-kdump-sysconfig.sh $arch > kdump.sysconfig.$arch.new
   git checkout HEAD^ kdump.sysconfig.$arch &>/dev/null
   echo "$arch:"
   diff kdump.sysconfig.$arch kdump.sysconfig.$arch.new; echo ""
   done; git reset;

Signed-off-by: Kairui Song <kasong@tencent.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
2022-08-16 14:35:35 +08:00
Coiby Xu
aa84244346 Release 2.0.25-1
Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-08-03 20:14:23 +08:00
Coiby Xu
f6bcd819fc use /run/ostree-booted to tell if scriptlet is running on OSTree system
Resolves: bz2092012

According to the ostree team [1], the existence of /run/ostree-booted
> is the most stable way to signal/check that a system has been
> booted in ostree-style.  It is also used by rpm-ostree at
> compose/install time in the sandboxed environment where scriptlets run,
> in order to signal that the package is being installed/composed into
> an ostree commit (i.e. not directly on a live system).  See
> 8ddf5f40d9/src/libpriv/rpmostree-scripts.cxx (L350-L353)
> for reference.

By checking the existence of /run/ostree-booted, we could skip trying to
update kernel cmdline during OSTree compose time.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2092012#c3

Reported-by: Luca BRUNO <lucab@redhat.com>
Suggested-by: Luca BRUNO <lucab@redhat.com>
Fixes: 0adb0f4 ("try to reset kernel crashkernel when kexec-tools updates the default crashkernel value")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Acked-by: Timothée Ravier <siosm@fedoraproject.org>
2022-08-03 11:07:47 +08:00
Coiby Xu
da0ca0d205 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>
2022-08-02 18:36:34 +08:00
Coiby Xu
c735539b35 Release 2.0.24-4
Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-07-21 16:42:43 +08:00
Coiby Xu
6f9653b918 Release 2.0.24-3
Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-05-23 18:26:42 +08:00
Coiby Xu
8f7ffb1a00 Update makedumpfile to 1.7.1
Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-05-23 18:26:42 +08:00
Coiby Xu
1facd0c118 fix incorrect date format in changelog
Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-04-24 11:38:48 +08:00
Coiby Xu
d5b01d7ef0 Release 2.0.24-2
A issue of bogus date in %changelog is fixed as well.

Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-04-24 10:38:04 +08:00
Coiby Xu
11140c28a2 Release 2.0.24-1 2022-04-11 10:56:46 +08:00
Coiby Xu
311b5b100b update kernel crashkernel in posttrans RPM scriptlet when updating kexec-tools
When doing in-place upgrading using leapp on x86_64, kdumpcl can't
acquire instance lock when running in %post RPM scriplet on x86_64,
  localhost upgrade[1306]: /bin/kdumpctl: line 49: /var/lock/kdump: No such file or directory
  localhost upgrade[1306]: kdump: Create file lock failed

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

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

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

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

Reported-by: Jie Li <jieli@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
2022-02-18 08:56:59 +08:00
Coiby Xu
59fcb8ae5b Release 2.0.23-5
Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-02-14 12:07:08 +08:00
Coiby Xu
d6298a1dec Release 2.0.23-4 2022-01-26 15:10:50 +08:00
Philipp Rudo
ca5a33855f s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()
Resolves: bz2025860
Upstream: git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git

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

    s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()

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

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

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

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

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

    $ readelf -r purgatory/purgatory.o

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

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

    $ readelf -r purgatory/purgatory.o

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

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

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

v2:
   - Moved patch 601 -> 401

Signed-off-by: Philipp Rudo <prudo@redhat.com>
Acked-by: Coiby Xu <coxu@redhat.com>
2022-01-26 08:25:43 +08:00
Kairui Song
748eb3a2a6 spec: only install mkfadumprd for ppc
fadump is a ppc only feature, mkfadumprd is only needed for fadump, drop
it for other arch.

Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Kairui Song <kasong@tencent.com>
2022-01-24 13:00:14 +08:00
Fedora Release Engineering
bb380a92fa - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
Signed-off-by: Fedora Release Engineering <releng@fedoraproject.org>
2022-01-20 14:26:44 +00:00
Pingfan Liu
c480be7ccf spec: add hostname.rpm into Recommends list
kexec-tools runs hostname binary in the case of fence_kdump. Since this
is a trival dependency and should not block the kexec-tools installation
if non-existent, using weak-dependency to resolve it.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Acked-by: Tao Liu <ltao@redhat.com>
2022-01-18 14:29:09 +08:00
Coiby Xu
1e569fd8a8 Release 2.0.23-2 2022-01-13 15:00:59 +08:00
Tao Liu
7de4a0d6c8 Set zstd as recommented for kexec-tools
This patch will make zstd as recommended instead of required for
kexec-tools. If zstd command/package is unavaliable, it can failback to invoke
gzip when making kdump initramfs.

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

Signed-off-by: Tao Liu <ltao@redhat.com>
Acked-by: Coiby Xu <coxu@redhat.com>
2022-01-11 10:11:21 +08:00
Coiby Xu
d5c31605f3 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>
2022-01-07 12:20:21 +08:00
Tao Liu
0311f6e25b Set zstd as the default compression method for kdump initrd
zstd has better compression ratio and time consumption balance.
When no customized compression method specified in kdump.conf,
we will use zstd as the default compression method.

**The test method:

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

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

**The test result:

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

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

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

**discussion

zstd has a better compression ratio and time consumption balance.

v1 -> v2:
Use kdump_get_conf_val() to get dracut_args values of kdump.conf

v2 -> v3:
Attached testing benchmark

v3 -> v4:
Re-measured and re-attached the testing benchmark of x86_64 and ppc64le.
Changed regex '.*[[:space:]]' to '(^|[[:space:]])'

v4 -> v5:
Attacked lzo/xz/lz4 testing benchmark.

v5 -> v6:
Add zstd as required in kexec-tools.spec

Hello Coiby, you may use "RELEASE=34 make test-run", for
CONFIG_RD_ZSTD is enabled since fc-cloud-34

Acked-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
2022-01-06 08:16:27 +08:00
Coiby Xu
0adb0f4a8c 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>
2022-01-05 09:40:24 +08:00
Coiby Xu
f0892eeceb kdump/ppc64: suppress the error message "Could not find a registered notification tool" from servicelog_notify
When kexec-tools is newly installed, kdump migration action hasn't
registered and the following error could occur,
  INF dnf.rpm: Could not find a registered notification tool with the specified command ('/usr/lib/kdump/kdump-migrate-action.sh').

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

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

Acked-by: Tao Liu <ltao@redhat.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
2021-12-03 08:29:04 +08:00
Coiby Xu
c3c8df3745 add keytuils as a weak dependency for POWER
When secureboot is enabled, kdumpctl needs to use keyctl to add/remove
a key to/from the .ima keyring.

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

Signed-off-by: Coiby Xu <coxu@redhat.com>
2021-11-18 15:10:40 +08:00
Tao Liu
9ffda5bc1c Enable zstd compression for makedumpfile in kexec-tools.spec
The Zstandard (zstd) compression method is not enabled:

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

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

Signed-off-by: Tao Liu <ltao@redhat.com>
Acked-by: Coiby Xu <coxu@redhat.com>
2021-11-11 16:36:13 +08:00
Coiby Xu
267a088b2a Release 2.0.23-1
Signed-off-by: Coiby Xu <coxu@redhat.com>
2021-11-08 14:42:45 +08:00
Coiby Xu
8b9948df33 Update makedumpfile to 1.7.0
Signed-off-by: Coiby Xu <coxu@redhat.com>
2021-11-08 14:42:22 +08:00
Kairui Song
6ea954d518 Release 2.0.22-8
Signed-off-by: Kairui Song <kasong@redhat.com>
2021-09-16 23:46:42 +08:00
Kairui Song
e7118d1de8 Merge kdump-error-handler.sh into kdump.sh
kdump-error-handler.sh does nothing except calling three functions,
it can be easily merged into kdump.sh by using a parameter to run the
error handling routine.

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

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

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Philipp Rudo <prudo@redhat.com>
2021-09-14 03:25:54 +08:00
Adam Williamson
5270d40dd0 Don't exit 1 from 92-crashkernel.install if zipl is absent (#1993505)
At least, this is a plausible suspect for #1993505 - thanks to
@kevin for identifying it - and fixing it should be safe and
correct, so we may as well do it and see if it helps.
2021-08-31 16:07:51 -07:00
Kairui Song
6c390b70e8 Release 2.0.22-6
Also fix a format error in changelog.

Signed-off-by: Kairui Song <kasong@redhat.com>
2021-08-20 20:14:27 +08:00
Kairui Song
7ddda7e6d0 Remove hard requirement on grubby
Downgrade to "Recommends:" as suggested by CoreOS team.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Tao Liu <ltao@redhat.com>
2021-08-20 16:13:25 +08:00
Hari Bathini
146f662622 kdump/ppc64: migration action registration clean up
While kdump migration action is registered for LPM event, ensure it is
cleared as appropriate to avoid duplicate/stale notification entries.

Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Acked-by: Kairui Song <kasong@redhat.com>
2021-07-31 19:40:14 +08:00
Fedora Release Engineering
152cf5e46c - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
Signed-off-by: Fedora Release Engineering <releng@fedoraproject.org>
2021-07-22 09:42:58 +00:00
Hari Bathini
71b7a2f47c kdump/ppc64: rebuild initramfs image after migration
Dump capture initramfs needs rebuild after partition migration (LPM).
Use servicelog notification mechanism to invoke kdump rebuild after
migration.

Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2021-07-21 10:53:59 +08:00
Zbigniew Jędrzejewski-Szmek
c894022e9b Remove references to systemd-sysv-convert
Packaging guidelines have been amended to not require systemd for scriptlets,
see https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_scriptlets.

The comment duplicates what the macro contains.

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

chkconfig binary is provided by the chkconfig package, which is not in
Requires. (And makes little sense to call nowadays anyway.)
2021-07-18 16:36:52 +00:00
Kairui Song
7dbbb4bb31 Add a crashkernel-howto.txt doc
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
2021-07-08 15:36:36 +08:00
Kairui Song
6463641935 Add a new hook: 92-crashkernel.install
To track and manage kernel's crashkernel usage by kernel version,
each kernel package will include a crashkernel.default containing the
default `crashkernel=` value of that kernel. So we can use a hook to
update the kernel cmdline of new installed kernel accordingly.

Put it after all other grub boot loader setup hooks, so it can simply
call grubby to modify the kernel cmdline.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
2021-07-08 15:36:32 +08:00
Hari Bathini
fa9201b240 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>
2021-06-29 21:35:58 +08:00
Kairui Song
c4749f9c57 Release 2.0.22-4
Signed-off-by: Kairui Song <kasong@redhat.com>
2021-06-29 21:24:19 +08:00
Tao Liu
50bb8b701f check for invalid physical address of /proc/kcore when making ELF dumpfile
Backport from upstream.

commit 9a6f589d99dcef114c89fde992157f5467028c8f
Author: Tao Liu <ltao@redhat.com>
Date:   Fri Jun 18 18:28:04 2021 +0800

    [PATCH] check for invalid physical address of /proc/kcore when making ELF dumpfile

    Previously when executing makedumpfile with -E option against
    /proc/kcore, makedumpfile will fail:

      # makedumpfile -E -d 31 /proc/kcore kcore.dump
      ...
      write_elf_load_segment: Can't convert physaddr(ffffffffffffffff) to an offset.

      makedumpfile Failed.

    It's because /proc/kcore contains PT_LOAD program headers which have
    physaddr (0xffffffffffffffff).  With -E option, makedumpfile will
    try to convert the physaddr to an offset and fails.

    Skip the PT_LOAD program headers which have such physaddr.

    Signed-off-by: Tao Liu <ltao@redhat.com>
    Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2021-06-28 15:52:21 +08:00
Tao Liu
0feb109818 check for invalid physical address of /proc/kcore when finding max_paddr
Backport from upstream.

commit 38d921a2ef50ebd36258097553626443ffe27496
Author: Coiby Xu <coxu@redhat.com>
Date:   Tue Jun 15 18:26:31 2021 +0800

    [PATCH] check for invalid physical address of /proc/kcore when finding max_paddr

    Kernel commit 464920104bf7adac12722035bfefb3d772eb04d8 ("/proc/kcore:
    update physical address for kcore ram and text") sets an invalid paddr
    (0xffffffffffffffff = -1) for PT_LOAD segments of not direct mapped
    regions:

      $ readelf -l /proc/kcore
      ...
      Program Headers:
        Type           Offset             VirtAddr           PhysAddr
                       FileSiz            MemSiz              Flags  Align
        NOTE           0x0000000000000120 0x0000000000000000 0x0000000000000000
                       0x0000000000002320 0x0000000000000000         0x0
        LOAD           0x1000000000010000 0xd000000000000000 0xffffffffffffffff
                                                             ^^^^^^^^^^^^^^^^^^
                       0x0001f80000000000 0x0001f80000000000  RWE    0x10000

    makedumpfile uses max_paddr to calculate the number of sections for
    sparse memory model thus wrong number is obtained based on max_paddr
    (-1).  This error could lead to the failure of copying /proc/kcore
    for RHEL-8.5 on ppc64le machine [1]:

      $ makedumpfile /proc/kcore vmcore1
      get_mem_section: Could not validate mem_section.
      get_mm_sparsemem: Can't get the address of mem_section.

      makedumpfile Failed.

    Let's check if the phys_start of the segment is a valid physical
    address to fix this problem.

    [1] https://bugzilla.redhat.com/show_bug.cgi?id=1965267

    Reported-by: Xiaoying Yan <yiyan@redhat.com>
    Signed-off-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2021-06-28 15:52:16 +08:00
Tao Liu
18b9b763de Increase SECTION_MAP_LAST_BIT to 5
Backport from upstream.

commit 646456862df8926ba10dd7330abf3bf0f887e1b6
Author: Kazuhito Hagio <k-hagio-ab@nec.com>
Date:   Wed May 26 14:31:26 2021 +0900

    [PATCH] Increase SECTION_MAP_LAST_BIT to 5

    * Required for kernel 5.12

    Kernel commit 1f90a3477df3 ("mm: teach pfn_to_online_page() about
    ZONE_DEVICE section collisions") added a section flag
    (SECTION_TAINT_ZONE_DEVICE) and causes makedumpfile an error on
    some machines like this:

      __vtop4_x86_64: Can't get a valid pmd_pte.
      readmem: Can't convert a virtual address(ffffe2bdc2000000) to physical address.
      readmem: type_addr: 0, addr:ffffe2bdc2000000, size:32768
      __exclude_unnecessary_pages: Can't read the buffer of struct page.
      create_2nd_bitmap: Can't exclude unnecessary pages.

    Increase SECTION_MAP_LAST_BIT to 5 to fix this.  The bit had not
    been used until the change, so we can just increase the value.

    Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>

Signed-off-by: Tao Liu <ltao@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2021-06-28 15:52:02 +08:00
Kairui Song
302be5c34b Release 2.0.22-3
Signed-off-by: Kairui Song <kasong@redhat.com>
2021-06-20 02:38:04 +08:00
Kairui Song
a2306346bc Remove the kdump error handler isolation wrapper
The wrapper is introduced in commit 002337c, according to the commit
message, the only usage of the wrapper is when dracut-initqueue calls
"systemctl start emergency" directly. In that case, emergency
is started, but not in a isolation mode, which means dracut-initqueue
is still running. On the other hand, emergency will call
"systemctl start dracut-initqueue" again when default action is dump_to_rootfs.

systemd would block on the last dracut-initqueue, waiting for the first
instance to exit, which leaves us hang.

In previous commit we added initqueue status detect in dump_to_rootfs,
so now even without the wrapper, it will not hang.

And actually, previously, with the wrapper, emergency might still hang
for like 30s. When dracut called emergency service because initqueue
timed out, dump_to_rootfs will try start initqueue again and timeout
again. Now with the wrapper removed, we can avoid these two kinds of
hangs, bacause without the isolation we can detect initqueue service
status correctly in such case.

Also remove the invalid header comments in service file, the service
is not part of systemd code. And sync the service spec with dracut.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Coiby Xu <coxu@redhat.com>
2021-06-04 14:26:45 +08:00
Kairui Song
13796ca93a Release 2.0.22-2
Signed-off-by: Kairui Song <kasong@redhat.com>
2021-05-13 17:14:38 +08:00
Kairui Song
c05d8a16a0 Update makedumpfile to 1.6.9
Signed-off-by: Kairui Song <kasong@redhat.com>
2021-05-13 16:45:36 +08:00