Commit Graph

1085 Commits

Author SHA1 Message Date
Kairui Song
75297d6f20 dracut-module-setup: fix bond ifcfg processing
Bond options in ifcfg is space separated, dracut expected it to be comma
separated, so it have to be parsed and converted during initramfs
building.

The currently parsing and convert pattern is flawed, for example:
" downdelay=0 miimon=100 mode=802.3ad updelay=0 "

is converted to :
":,downdelay=0 miimon=100 mode=802.3ad updelay=0 "

should be:
":downdelay=0,miimon=100,mode=802.3ad,updelay=0"

So fix this issue by using more simple but robust method for processing
the options.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-09-02 17:05:43 +08:00
Pingfan Liu
a5ea190af2 dracut-module-setup: filter out localhost for generic_fence_kdump
The localhost is filtered out in case of is_pcs_fence_kdump, do it too in
case of is_generic_fence_kdump.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2019-08-28 14:19:17 +08:00
Pingfan Liu
f0b5493b2e dracut-module-setup: get localhost alias by manual
'hostname -A' can not get the alias, meanwhile 'hostname -a' is deprecated.
So we should do it by ourselves.

The parsing is based on the format of /etc/hosts, i.e.
  IP_address canonical_hostname [aliases...]

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2019-08-28 14:19:01 +08:00
Kairui Song
d9c0c2f68f Release 2.0.20-3
Signed-off-by: Kairui Song <kasong@redhat.com>
2019-08-12 18:08:37 +08:00
Pingfan Liu
c1a06343df kdumpctl: wait a while for network ready if dump target is ssh
If dump target is ipv6 address, a host should have ipv6 address ready
before starting kdump service. Otherwise, kdump service fails to start due
to the failure "ssh dump_server_ip mkdir -p $SAVE_PATH".
And user can see message like:
 "Could not create root@2620:52:0:10da:46a8:42ff:fe23:3272/var/crash"

I observe a long period (about 30s) on some machine before they got ipv6
address dynamiclly, which is never seen on ipv4 host.

Hence kdump service has a dependency on ipv6 address. But there is no good
way to resolve it. One way is asking user to run the cmd "nmcli connection
modify eth0 ipv6.may-fail false". But this will block systemd until ipv6
address is ready. Despite doing so, kdump can try its best (wait 1 minutes
after it starts up) before failure.

How to implement the wait is arguable. It will involve too many technique
details if explicitly waiting on ipv6 address, instead, just lean on 'ssh'
return value to see the availability of network.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2019-08-12 16:13:08 +08:00
Kazuhito Hagio
15f6d2627f makedumpfile: Increase SECTION_MAP_LAST_BIT to 4
Backport from the makedumpfile devel branch in upstream.

commit 7bdb468c2c99dd780c9a5321f93c79cbfdce2527
Author: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
Date:   Tue Jul 23 12:24:47 2019 -0400

    [PATCH] Increase SECTION_MAP_LAST_BIT to 4

    kernel commit 326e1b8f83a4 ("mm/sparsemem: introduce a SECTION_IS_EARLY
    flag") added the flag to mem_section->section_mem_map value, and it caused
    makedumpfile an error like the following:

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

    To fix this, SECTION_MAP_LAST_BIT needs to be updated. The bit has not
    been used until the addition, so we can just increase the value.

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

Signed-off-by: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2019-08-06 11:15:14 +08:00
Kazuhito Hagio
076b839dd4 makedumpfile: Do not proceed when get_num_dumpable_cyclic() fails
Backport from the makedumpfile devel branch in upstream.

commit c1b834f80311706db2b5070cbccdcba3aacc90e5
Author: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
Date:   Tue Jul 23 11:50:52 2019 -0400

    [PATCH] Do not proceed when get_num_dumpable_cyclic() fails

    Currently, when get_num_dumpable_cyclic() fails and returns FALSE in
    create_dump_bitmap(), info->num_dumpable is set to 0 and makedumpfile
    proceeds to write a broken dumpfile slowly with incorrect progress
    indicator due to the value.

    It should not proceed when get_num_dumpable_cyclic() fails.

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

Signed-off-by: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2019-08-06 11:14:40 +08:00
Kairui Song
4a0f9763c0 Don't forward and drop journalctl logs for fadump
fadump will alter the normal boot initramfs and we don't want a normal
boot to foward and drop the journalctl logs.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-08-06 11:14:15 +08:00
Kairui Song
80de723566 Release 2.0.20-2
Signed-off-by: Kairui Song <kasong@redhat.com>
2019-08-02 14:51:21 +08:00
Kairui Song
cb1e5463b5 x86: Fix broken multiboot2 buliding for i386
When building for i386, an error occured:

kexec/arch/i386/kexec-x86.c:39:22: error: 'multiboot2_x86_probe'
undeclared here (not in a function); did you mean 'multiboot_x86_probe'?
39 |  { "multiboot2-x86", multiboot2_x86_probe, multiboot2_x86_load,
   |                      ^~~~~~~~~~~~~~~~~~~~
   |                      multiboot_x86_probe

kexec/arch/i386/kexec-x86.c:39:44: error: 'multiboot2_x86_load'
undeclared here (not in a function); did you mean 'multiboot_x86_load'?
39 |  { "multiboot2-x86", multiboot2_x86_probe, multiboot2_x86_load,
   |                                            ^~~~~~~~~~~~~~~~~~~
   |                                            multiboot_x86_load
kexec/arch/i386/kexec-x86.c:40:4: error: 'multiboot2_x86_usage'
 undeclared here (not in a function); did you mean 'multiboot_x86_usage'?
40 |    multiboot2_x86_usage },
   |    ^~~~~~~~~~~~~~~~~~~~
   |    multiboot_x86_usage

Fix this issue by putting the definition in the right header, also tidy
up Makefile.

Signed-off-by: Kairui Song <kasong@redhat.com>
2019-08-02 11:24:03 +08:00
Pingfan Liu
88bbab963f dracut-module-setup.sh: skip alias of localhost in get_pcs_fence_kdump_nodes()
The current code only exclude the hostname, while localhost can have alias in
/etc/hosts. All of the alias should be excluded from the fence dump node to
avoid deadlock issue.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2019-08-01 13:38:53 +08:00
Kairui Song
03fd19454b Release 2.0.20-1
Rebase to latest upstream and make a release

Signed-off-by: Kairui Song <kasong@redhat.com>
2019-07-31 15:54:46 +08:00
Kairui Song
4b7198f651 Update makedumpfile to 1.6.6
Signed-off-by: Kairui Song <kasong@redhat.com>
2019-07-31 15:54:42 +08:00
Kairui Song
17981c14ec kexec-tools.spec: Use a macro for makedumpfile version
Don't repeat it again and again and make it easier to maintain.

Signed-off-by: Kairui Song <kasong@redhat.com>
2019-07-31 15:53:26 +08:00
Fedora Release Engineering
603cd09b76 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
Signed-off-by: Fedora Release Engineering <releng@fedoraproject.org>
2019-07-25 11:23:07 +00:00
Kairui Song
cf5d362dca dracut-module-setup.sh: Don't use squash module for fadump
Squash module is used to save memory. For fadump this is not neccessary
and may slow down the build time, and make it more fragile.

fadump initramfs is used for normal boot as well, although squash module
is capable of being used for generic normal boot, but there are cases
where is doesn't work well. So disable it and make fadump more robust.

Signed-off-by: Kairui Song <kasong@redhat.com>
Tested-by: Hari Bathini <hbathini@linux.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-07-16 16:46:23 +08:00
Kairui Song
5b26c1f8b2 Forward logs in kdump kernel to console directly
Don't use any log storage and forward to console directly, this make
console output more useful, and also save more memory. On a fresh
installed Fedora 30 it saved ~5M of memory, and the amount of log being
printed to console is still accetable.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-07-16 14:11:16 +08:00
Kairui Song
b998b90197 kdump.sysconfig/x86_64: Disable HEST by default
Some firmware will provide a ACPI HEST table with massive amount of
entries, and the way how kernel handles these entries will consume a lot
of memory which will lead to OOM issue in kdump kernel. During testing
on certain machine, disable HEST saved ~60M of memory.

Kdump is only for emergency use in case of a kernel panic, so temporarily
disable hardware error report & recovery related feature is acceptable
in general. So disable HEST support in kdump kernel to save memory.

Currently such issue is only observed on x86_64, so limit this change to
x86_64 only.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-07-09 14:11:36 +08:00
Pingfan Liu
ace23737ab dracut-kdump-capture.service: Use OnFailureJobMode instead of deprecated OnFailureIsolate
systemd has the following message "OnFailureIsolate is deprecated. Please
use OnFailureJobMode= instead"

Changing the file to meet systemd's requirement

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2019-06-14 09:44:09 +08:00
Lianbo Jiang
b1250de389 makedumpfile: x86_64: Add support for AMD Secure Memory Encryption
Backport from the makedumpfile devel branch in upstream.

commit d222b01e516bba73ef9fefee4146734a5f260fa1 (HEAD -> devel)
Author: Lianbo Jiang <lijiang@redhat.com>
Date:   Wed Jan 30 10:48:53 2019 +0800

    [PATCH] x86_64: Add support for AMD Secure Memory Encryption

    On AMD machine with Secure Memory Encryption (SME) feature, if SME is
    enabled, page tables contain a specific attribute bit (C-bit) in their
    entries to indicate whether a page is encrypted or unencrypted.

    So get NUMBER(sme_mask) from vmcoreinfo, which stores the value of
    the C-bit position, and drop it to obtain the true physical address.

    Signed-off-by: Lianbo Jiang <lijiang@redhat.com>

Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2019-06-10 16:13:38 +08:00
Bhupesh Sharma
fd1eccf920 aarch64/kdump.sysconfig: Make config options similar to x86_64
Looking at the difference of the x86_64 and aarch64 kdump.sysconfig
options for Fedora, one can see the following options which are
different:

Present in kdump.sysconfig.x86_64 but not in kdump.sysconfig.aarch64:
---------------------------------------------------------------------
 cgroup_disable=memory
 mce=off
 numa=off
 udev.children-max=2
 panic=10
 acpi_no_memhotplug
 transparent_hugepage=never
 nokaslr

Present in kdump.sysconfig.aarch64 but not in kdump.sysconfig.x86_64:
---------------------------------------------------------------------
 swiotlb=noforce

After going through all the options, it makes sense to add the
following options added to kdump.sysconfig.aarch64:

  KDUMP_COMMANDLINE_APPEND="cgroup_disable=memory udev.children-max=2
                            panic=10 irqpoll nr_cpus=1
			    swiotlb=noforce reset_devices"

This has helped reduce the memory footprint of crashkernel on several
aarch64 machines available in the beaker lab. For e.g. I was seeing
OOM issues on large aws ec2 instances with the default crashkernel size
of 512M, and I had to use an increased crashkernel size of 786M on the
same to boot the crash dump kernel.

Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Pingfan Liu <piliu@redhat.com>
2019-05-29 17:04:27 +08:00
Bhupesh Sharma
3001788f4c Add aarch64 specific kdump.sysconfig and use 'nr_cpus' instead of 'maxcpus'
'maxcpus' setting normally don't work on several kdump enabled systems
due to a known udev issue.

Currently the fedora kdump configuration is set as the following on the
aarch64 systems:

 # cat /etc/sysconfig/kdump
<..snip..>
  # This variable lets us append arguments to the current kdump
  # commandline after processed by KDUMP_COMMANDLINE_REMOVE
  # KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1 reset_devices"
<..snip..>

Since the 'maxcpus' setting doesn't limit the number of SMP CPUs,
so the kdump kernel still boots with all CPUs available on the system.
For e.g on the qualcomm amberwing its 46 CPUs:

  # lscpu
Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              46
On-line CPU(s) list: 0-45
Thread(s) per core:  1
Core(s) per socket:  46
Socket(s):           1
NUMA node(s):        1
Vendor ID:           Qualcomm
Model:               1
Model name:          Falkor
Stepping:            0x0
CPU max MHz:         2600.0000
CPU min MHz:         600.0000
BogoMIPS:            40.00
L1d cache:           32K
L1i cache:           64K
L2 cache:            512K
L3 cache:            58880K
NUMA node0 CPU(s):   0-45
Flags:               fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm

This causes the memory consumption in the kdump kernel to swell up and
we can end up having OOM issues in the kdump kernel boot.

Whereas if we use 'nr_cpus=1' in the bootargs, the number of SMP CPUs in
the kdump kernel get limited to 1.

The 'swiotlb=noforce' setting in bootargs provide us extra guarding, to
ensure the crash kernel size requirements do not swell on systems
which support swiotlb.

With the above settings, crashkernel boots properly (without OOM) on all
the aarch64 boards I could test on - qualcomm amberwings, hp-moonshots
and hpe-apache (thunderx2) for crash dump saving on local disk.

Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Pingfan Liu <piliu@redhat.com>
2019-05-29 17:04:20 +08:00
Kairui Song
f0fa5c8e91 kdumpctl: check for ssh path availability when rebuild
Currently kdumpctl rebuild will simply rebuild the initramfs, and
only perform basic config syntax check. But it should also check if the
target path is available when using SSH target, else kdump may fail.
is second kernel. kdumpctl rebuild should cover this case, and create
the path if it doesn't exist.

This patch make rebuild and restart behaves the same, rebuild is
now equal to restart, except it won't check config change or reload
kdump resource.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-05-27 16:13:29 +08:00
Kairui Song
43c26b7312 kdumpctl: Check kdump.conf for error when rebuild is called
Although "kdumpctl rebuild" is introduced to help user rebuild the
initramfs without modifying the kdump.conf, if the kdump.conf is
modified and "kdumpctl rebuild" is called, a initramfs with a faulty
kdump.conf will be built.

Kdump will refuse to load the initramfs when restarted, but kdumpctl
reload may load the faulty initramfs. So need to make sure the faulty
build won't be generate in the first place.

Check for kdump.conf error before building the initramfs to ensure such
failure won't happen.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-05-27 13:57:55 +08:00
Kairui Song
8af28759ec Release 2.0.19-2
Signed-off-by: Kairui Song <kasong@redhat.com>
2019-05-20 17:08:28 +08:00
Kairui Song
2efc0f1854 kdumpctl: don't always rebuild when extra_modules is set
We don't necessarily have to always rebuild the initramfs when
extra_modules is set. Instead, just detect if any module is updated,
and only rebuild initramfs if found any updated kernel module.

Tested with in-tree kernel modules, out-of-tree kernel modules, weak
modules, all worked as expected.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-05-20 17:01:25 +08:00
Kairui Song
30913fd667 kdumpctl: follow symlink when checking for modified files
Previously only the symlink's timestamp is used for checking if file are
modified, this will not trigger a rebuild if the symlink target it
modified.

So check both symlink timestamp and symlink target timestamp, rebuild
the initramfs on both symlink changed and target changed.

Also give a proper error message if the file doesn't exist.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-05-20 16:56:31 +08:00
Kairui Song
75d9132417 Get rid of duplicated strip_comments when reading config
When reading kdump configs, a single parsing should be enough and this
saves a lot of duplicated striping call which speed up the total load
speed.

Speed up about 2 second when building and 0.1 second for reload in my
tests.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-05-20 16:56:28 +08:00
Lianbo Jiang
9529191d95 earlykdump: provide a prompt message after the rebuilding of kdump initramfs.
Early kdump inherits the settings of normal kdump, so any changes that
caused normal kdump rebuilding also require rebuilding the system initramfs
to make sure that the changes take effect for early kdump.

Therefore, when the early kdump is enabled, provide a prompt message after
the rebuilding of kdump initramfs is completed.

Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-05-20 16:56:19 +08:00
Kairui Song
8d4db658fd kexec-kdump-howto.txt: Add document about encrypted targets
Currently kdump is not working well with encrypted targets, add document
about this issue.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-05-20 13:41:44 +08:00
Kairui Song
f544a12e78 kexec-kdump-howto.txt: Add document about initramfs rebiuld
Add some note about the limitation of kdumpctl's auto detect and rebuild
feature, and suggest the user to rebuild the initramfs manually on
major system change, and don't include the initramfs in disk images.

Put the note about system change in front part of the document so user
will less likely to miss it.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-05-20 13:41:28 +08:00
Kairui Song
1c1159a586 kdumpctl: Detect block device driver change for initramfs rebuild
Previous we rebuild the initramfs when kenrel load module list changed,
but this is not very stable as some async services may load/unload
kernel modules, and cause unnecessary initramfs rebuild.

Instead, it's better to just check if the module required to dump to
the dump target is loaded or not, and rebuild if not loaded. This
avoids most false-positives, and ensure local target change is always
covered.

Currently only local fs dump target is covered, because this check
requires the dump target to be mounted when building the initramfs,
this guarantee that the module is in the loaded kernel module list,
else we may still get some false positive.

dracut-install could be leveraged to combine the modalias list with
kernel loaded module list as a more stable module list in the initramfs,
but upstream dracut change need to be done first.

Passed test on a KVM VM, changing the storage between SATA/USB/VirtIO
will trigger initramfs rebuild and didn't notice any false-positive.
Also passed test on my laptop with no false-positive.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-05-08 17:51:18 +08:00
Kairui Song
09f50350d9 Revert "kdumpctl: Rebuild initramfs if loaded kernel modules changed"
This reverts commit 6b479b6572.

Check initramfs rebuild by looking at if there is any change of load
kernel modules list is not very stable after all. Previously we are
counting on udev to settle before kdump is started to ensure all modules
is ready, but actually any service may cause a kernel module load, even
after udev is settled.

The previous commit is trying to workaround an issue that VM created
with disk snapshot may fail in the kdump initramfs. The better fix is to
not include the kdump initramfs in the disk snapshot at all, as the
kdump initramfs is not generated for a generic use. And With new added
"kdumpctl reload" command, admins could rebuild the image easily, and
should rebuild the initramfs on hardware change manually.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-05-06 17:54:26 +08:00
Pingfan Liu
a585f981bd kexec.rules: create dedicated udev rules for ppc64
On powerpc, after hot add cpu and trigger crash on the hot-added cpu, the
kdump kernel hangs after "I'm in purgatory".

The current udev rules expects the dtb to be rebuit on cpu add/remove event.
But since powerpc does not follow the standard cpu hot add framework, it
only ejects online/offline event to user space when cpu is hot
added/removed, instead of add/remove event.  Pingfan tried fixing that but
it didn't please the maintainer as it breaks some old userspace tools.

Due to the failure of dtb's rebuilding, KDump kernel fails to get the
'boot_cpuid' and eventually fails to boot [see early_init_dt_scan_cpus() in
arch/powerpc/kernel/prom.c file] if system crashes on hot-added CPU.

Work around it by changing udev rules on powerpc to onlne/offline.

As for offline message, it is even useless on powerpc, and can be dropped.
See the explain: On powerpc, /sys/devices/system/cpu/cpuX nodes are present
for all "possible", irrespective of whether a CPU is hot-added/removed.
crash_notes are already built for all /sys/devices/system/cpu/cpuX nodes and
these nodes are present for all "possible" CPUs
(online/offline/could-be-hot-removed/could-be-hot-added)

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2019-05-06 16:22:28 +08:00
Baoquan He
50aa6dea24 kexec-kdump-howto: Add note on setting correct value of kptr_restrict
kdumpctl fails to load a crash kernel if KASLR is enabled.

The incorrect configuration of the kptr_restrict parameter causes that
the kdumpctl fails to load a crash kernel. The problem occurs when the
Kernel Address Space Layout Randomization (KASLR) mechanism is enabled.
The value of kptr_restrict decides how to expose the content of /proc
files. Inappropriate setting will cause that the /proc/kallsyms file is
being printed as all zeros. This configuration will break the kdump
loading process since it needs access to the conntent of /proc/kallsyms
if KASLR is enabled.

Set kptr_restrict to 1 to avoid the problem described above.

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-04-25 08:33:29 -04:00
Kairui Song
a53be67929 Update man page for new kdumpctl command: reload / rebuild
These two command are not documented, update the man page to let user
know how to use them.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-04-05 02:02:58 +08:00
Kairui Song
594ac119c5 kdumpctl: add rebuild support
Use "kdumpctl rebuild" to rebuild the image directly. This could help
admins to rebuild kdump image directly.

Also merge fadump related initramfs backup/restore into setup_initrd,
and do permission only when actually trying to rebuild the image.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-04-05 02:02:43 +08:00
Kairui Song
289e16c881 mkdumprd: Improve the config reading logic
Seems some dead codes are left here for historical reason, just remove
them, read the config and strip comments only for once.

This improve the speed by a lot (2.6s -> 0.498s for reading a
simple config in my test case, on HDD) and make the code cleaner.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-03-29 10:52:39 +08:00
Kairui Song
24f9b31080 Release 2.0.19-1
Rebase to latest kexec-tools upstream and remove backport patch.

Signed-off-by: Kairui Song <kasong@redhat.com>
2019-03-22 17:06:27 +08:00
Kairui Song
ace66284ab Update eppic to latest snapshot
Also don't override LDFLAGS when building eppic lib, this ensure
hardening won't get overrided.

Signed-off-by: Kairui Song <kasong@redhat.com>
2019-03-21 11:19:41 +08:00
Hari Bathini
689fca5af3 fadump: leverage kernel support to re-regisgter FADump
With kernel commit 0823c68b054b ("powerpc/fadump: re-register firmware-
assisted dump if already registered") support is enabled to re-register
when FADump is alredy registered. Leverage that option in kdump scripts.

Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Acked-by: Kairui Song <kasong@redhat.com>
2019-03-07 13:33:17 +08:00
Hari Bathini
da6b75f59b fadump: use the original initrd to rebuild fadump initrdfrom
The idea behind adding support for dracut '--rebuild' option was to
ensure the initrd built for fadump takes into consideration all the
build parameters passed to original initrd. Pass original initrd
instead of current default initrd for rebuild as current initrd
might already have build parameters from original initrd along
with parameters from previous fadump intird build making the
build parameters look like this after a few iterations:

-H --persistent-policy 'by-uuid' -f --quiet --hostonly --hostonly-
cmdline --hostonly-i18n --hostonly-mode 'strict' -o 'plymouth dash
resume ifcfg' --mount '/dev/mapper/rhel_zzfp219--lp3-home /kdumproot
//home xfs defaults' -f --kver '4.18.0-60.el8.ppc64le' --quiet
--hostonly --hostonly-cmdline --hostonly-i18n --hostonly-mode 'strict'
-o 'plymouth dash resume ifcfg' --mount '/dev/mapper/rhel_zzfp219--lp3-home
/kdumproot//home xfs defaults' -f --kver '4.18.0-60.el8.ppc64le' --quiet
--hostonly --hostonly-cmdline --hostonly-i18n --hostonly-mode 'strict'
-o 'plymouth dash resume ifcfg' --mount '/dev/mapper/rhel_zzfp219--lp3-home
/kdumproot//home xfs defaults' -f --kver '4.18.0-60.el8.ppc64le' --include
'/tmp/fadump.initramfs' '/etc/fadump.initramfs' --include
'/tmp/fadump.initramfs' '/etc/fadump.initramfs' --include
'/tmp/fadump.initramfs' '/etc/fadump.initramfs'
--

Since it is not desirable to build initrd with stale and/or  duplicate
build parameters, use original initrd (backed up) to rebuild fadump
initrd, instead of current default initrd.

Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-03-07 13:32:47 +08:00
Kairui Song
be6200f044 Release 2.0.18-5
Signed-off-by: Kairui Song <kasong@redhat.com>
2019-02-22 17:11:27 +08:00
Kairui Song
97890ecbac Update eppic to latest upstream snapshot
eppic project have moved to github, update to latest upstream snapshot,
change source link and tar file naming style to fit github's URL format.

This fix the O0 warning reported by annocheck and passes all distro package
flag checking.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-02-22 17:09:07 +08:00
Kairui Song
2fc7312546 Enable building with hardening flags
Backport the patches required to make the hardening build flags work with
kexec-tools and makedumpfile, and enabld hardening flags in spec file.
This will make the pacakge pass all warnings for kexec and makedumpfile
reported by annocheck.

Didn't find any issue with basic tests with kexec and makedumpfile.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-02-22 17:09:07 +08:00
Kairui Song
159307d057 Remove unused patches
Signed-off-by: Kairui Song <kasong@redhat.com>
2019-02-22 17:09:07 +08:00
Fedora Release Engineering
b5736e4663 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
Signed-off-by: Fedora Release Engineering <releng@fedoraproject.org>
2019-02-01 05:20:38 +00:00
Igor Gnatenko
95e9a62674 Remove obsolete Group tag
References: https://fedoraproject.org/wiki/Changes/Remove_Group_Tag
2019-01-28 20:24:10 +01:00
Kairui Song
05cec1657f mkdumprd: refine regex on dropping mount options
Currently we use "\b" (word boundary) as the delimiter for ro option,
which is not correct. For mount options like
"defaults,errors=remount-ro" the ro on the tail will also be replaced
and result in an invalid mount option.

So we use a more strict logic on detecting ro mount option. It should
either starts with "," or "^" (begin of line) and ends with "," or "$"
(end of line), and keep the delimiter untouched. This should ensure
only valid mount option got detected and replaced.

This passed following tests:

defaults,ro,noauto,errors=remount-ro,nobootwait,nofail => defaults,rw,errors=remount-ro,
defaults,errors=remount-ro => defaults,errors=remount-ro
defaults,ro,relatime => defaults,rw,relatime
defaults,ro => defaults,rw

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-01-28 18:23:03 +08:00
Kairui Song
7f9dd45688 Release 2.0.18-3
Signed-off-by: Kairui Song <kasong@redhat.com>
2019-01-22 18:08:05 +08:00