Commit Graph

689 Commits

Author SHA1 Message Date
Coiby Xu
471c136481 Release 2.0.26-7
Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-06-14 17:39:41 +08:00
Timothée Ravier
eabbf9d6a0 Whitespace fixes 2023-06-02 13:11:01 +02:00
Timothée Ravier
4da1ffe730 Make binutils a recommend as it's only needed for UKI support
UKI are not supported on rpm-ostree based Fedora variants so let's use
recommend for binutils for now to let those not include the package
until needed.

See: https://github.com/coreos/fedora-coreos-tracker/issues/1496
See: https://github.com/ostreedev/ostree/issues/2753
See: ea7be0608e
2023-06-02 13:11:01 +02:00
Coiby Xu
4311534c85 Release 2.0.26-5
Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-05-29 17:42:49 +08:00
Coiby Xu
5b31b099ae Simplify the management of the kernel parameter crashkernel
Currently, kexec-tools only updates the crashkernel to a new default
value only when both two conditions are met,
 - auto_reset_crashkernel=yes in kdump.conf
 - existing kernels or current running kernel should use the old default
   value.

To address seen corner cases, the logic to tell if the second condition
is met becomes quite complex. Instead of making the logic more complex
to support aarch64-64k, this patch drops the second condition to
simplify the management of the crashkernel kernel parameter.

Another change brought by this simplification is kexec-tools will also
set up the kernel crashkernel parameter for a fresh install (previously
it's limited to osbuild).

Note
1. This patch also stop trying to update /etc/default/grub because
   a) it only affects the static file /boot/grub2/grub.cfg
   b) grubby is recommended to change the kernel command-line parameters
      for both Fedora [1] and RHEL9 [2][3]
   c) For the cases of aarch64 and POWER, different kernels could have
      different default crashkernel value.

2. Starting with Fedora 37,  posttrans rpm scriplet distinguish between
   package install and upgrade.

[1] https://fedoraproject.org/wiki/GRUB_2
[2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/configuring-kernel-command-line-parameters_managing-monitoring-and-updating-the-kernel#changing-kernel-command-line-parameters-for-all-boot-entries_configuring-kernel-command-line-parameters
[3] https://access.redhat.com/solutions/1136173

Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
2023-05-29 14:40:57 +08:00
Coiby Xu
5e3d629da7 Release 2.0.26-4
Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-05-16 09:44:56 +08:00
Kairui Song
c8643af270 mkdumprd: add --aggressive-strip as default dracut args
The new aggressive strip option was added in dracut 058, which tell
dracut to build the initramfs stripping more sections of the ELF
binaries (basically strip .symtab, .strtab).

These section are only useful for debugging runtime failures, but in
kdump kernel, neccessary tools for debug any runtime failure are
absent, there is no point keeping these sections.

Stripping these section can help save some memory with almost no side
effect. So let enable --aggressive-strip by default.

Comparison of unpacked initramfs before / after enabling aggressive strip:

du -hs image image.aggressive-strip
31M     image
29M     image.aggressive-strip

Signed-off-by: Kairui Song <kasong@tencent.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
2023-05-16 09:21:13 +08:00
Philipp Rudo
ea7be0608e kdumpctl: Add basic UKI support
A Unified Kernel Image (UKI) is a single EFI PE executable combining an
EFI stub, a kernel image, an initrd image, and the kernel command line.
They are defined in the Boot Loader Specification [1] as type #2
entries. UKIs have the advantage that all code as well as meta data that
is required to boot the system, not only the kernel image, is combined
in a single PE file and can be signed for EFI SecureBoot. This extends
the coverage of SecureBoot extensively.

For RHEL support for UKI were included into kernel-ark with 16c7e3ee836e
("redhat: Add sub-RPM with a EFI unified kernel image for virtual
machines").

There are two problems with UKIs from the kdump point of view at the
moment. First, they cannot be directly loaded via kexec_file_load and
second, the initrd included isn't suitable for kdump. In order to enable
kdump on systems with UKIs build the kdump initrd as usual and extract
the kernel image before loading the crash kernel.

[1] https://uapi-group.org/specifications/specs/boot_loader_specification/

Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
2023-05-16 09:21:13 +08:00
Philipp Rudo
0ff44ca6e8 kdumpctl: fix is_dracut_mod_omitted
The function is pretty broken right now. To start with the -o/--omit
option allows a quoted, space separated list of modules. But using 'set'
breaks quotation and thus only considers the first element in the list.
Furthermore dracut uses getopt internally. This means that it is also
possible to pass the list via --omit=.

Fix the function by making use of getopt for parsing the dracut_args.
While at it also add a test cases to cover the functions.

Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
2023-04-17 14:49:51 +08:00
Coiby Xu
b41cab7099 Release 2.0.26-3
Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-01-30 17:39:35 +08:00
Coiby Xu
f4c04c3d63 makedumpfile: Fix wrong exclusion of slab pages on Linux 6.2-rc1
Resolves: bz2155754
Upstream: https://github.com/makedumpfile/makedumpfile
Conflict: None

commit 5f17bdd2128998a3eeeb4521d136a192222fadb6
Author: Kazuhito Hagio <k-hagio-ab@nec.com>
Date:   Wed Dec 21 11:06:39 2022 +0900

    [PATCH] Fix wrong exclusion of slab pages on Linux 6.2-rc1

    * Required for kernel 6.2

    Kernel commit 130d4df57390 ("mm/sl[au]b: rearrange struct slab fields to
    allow larger rcu_head"), which is contained in Linux 6.2-rc1 and later,
    made the offset of slab.slabs equal to page.mapping's one.  As a result,
    "makedumpfile -d 8", which should exclude user data, excludes some slab
    pages wrongly because isAnon() returns true when slab.slabs is an odd
    number.  With such dumpfiles, crash can fail to start session with an
    error like this:

      # crash vmlinux dumpfile
      ...
      crash: page excluded: kernel virtual address: ffff8fa047ac2fe8 type: "xa_node shift"

    Make isAnon() check that the page is not slab to fix this.

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

Reported-by: Baoquan He <bhe@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-01-30 17:37:23 +08:00
Fedora Release Engineering
4ffc0113a6 Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
Signed-off-by: Fedora Release Engineering <releng@fedoraproject.org>
2023-01-19 14:23:04 +00:00
Coiby Xu
4895f2a2e9 Release 2.0.26-1
Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-12-22 12:55:14 +08:00
Coiby Xu
5951b5e268 Don't try to update crashkernel when bootloader is not installed
Currently when using anaconda to install the OS, the following errors
occur,

    INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-70.el9.x86_64 ...
    INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory
    grep: /boot/grub2/grubenv: No such file or directory
    grep: /boot/grub2/grubenv: No such file or directory
    grep: /boot/grub2/grubenv: No such file or directory
    ...
    INF packaging: Configuring (running scriptlet for): kexec-tools-2.0.23-9.el9.x86_64 ...
    INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory
    grep: /boot/grub2/grubenv: No such file or directory
    grep: /boot/grub2/grubenv: No such file or directory

Or for s390, the following errors occur,

    INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-71.el9.s390x ...
    03:37:51,232 INF dnf.rpm: grep: /etc/zipl.conf: No such file or directory
    grep: /etc/zipl.conf: No such file or directory
    grep: /etc/zipl.conf: No such file or directory

    INF packaging: Configuring (running scriptlet for): kexec-tools-2.0.23-9_1.el9_0.s390x ...
    INF dnf.rpm: grep: /etc/zipl.conf: No such file or directory

This is because when anaconda installs the packages, bootloader hasn't
been installed and /boot/grub2/grubenv or /etc/zipl.conf doesn't exist.
So don't try to update crashkernel when bootloader isn't ready to avoid
the above errors.

Note this is the second attempt to fix this issue. Previously a file
/tmp/kexec_tools_package_install was created to avoid running the
related code thus to avoid the above errors but unfortunately that
approach has two issues a) somehow osbuild doesn't delete it for RHEL b)
this file could still exist if users manually remove kexec-tools.

Fixes: e218128 ("Only try to reset crashkernel for osbuild during package install")
Reported-by: Jan Stodola <jstodola@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
2022-12-22 10:33:00 +08:00
Coiby Xu
bc4196afc1
Release 2.0.25-4
Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-12-07 17:47:58 +08:00
Hari Bathini
4a2dcab26a fadump: add a kernel install hook to clean up fadump initramfs
Kdump service will create fadump initramfs when needed, but it won't
clean up the fadump initramfs on kernel uninstall. So create a kernel
install hook to do the clean up job.

Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
2022-12-07 09:42:29 +08:00
Coiby Xu
e96e441b36 Release 2.0.25-3
Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-11-25 17:47:20 +08:00
Pingfan Liu
787b041aab kdump.conf: use a simple generator script to maintain
This commit has the same motivation as the commit 677da8a "sysconfig:
use a simple generator script to maintain".

At present, only the kdump.conf generated for s390x has a slight
difference from the other arches, where the core_collector asks the
makedumpfile to use "-c" option to compress dump data by each page using
zlib, which is more efficient than lzo on s390x.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
2022-11-25 17:16:09 +08:00
Coiby Xu
995ee24903 Release 2.0.25-2
Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-10-27 16:00:11 +08:00
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