[PATCH] mkdumprd: allow spaces after 'path' config phrase when network dump
by Kazuhito Hagio
Without this patch, when there are two or more spaces after 'path'
configuration phrase with ssh or nfs setting, SAVE_PATH is set to
'/var/crash' in mkdumprd, and in most cases kdump service fails to
start.
ssh kdump(a)192.168.122.1
path /kdump
^^
This behavior would be too sensitive and different from the other
configurations. With this patch, mkdumprd allows such spaces.
Signed-off-by: Kazuhito Hagio <k-hagio(a)ab.jp.nec.com>
---
mkdumprd | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mkdumprd b/mkdumprd
index a6f7fe8..aa0abfd 100644
--- a/mkdumprd
+++ b/mkdumprd
@@ -13,7 +13,7 @@ export IN_KDUMP=1
conf_file="/etc/kdump.conf"
SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa"
-SAVE_PATH=$(grep ^path $conf_file| cut -d' ' -f2)
+SAVE_PATH=$(awk '/^path/ {print $2}' $conf_file)
[ -z "$SAVE_PATH" ] && SAVE_PATH=$DEFAULT_PATH
# strip the duplicated "/"
SAVE_PATH=$(echo $SAVE_PATH | tr -s /)
--
2.18.0
1 year, 6 months
Re: Bug in lib/kdump/kdump-lib.sh ... on LVM crypto volumes
by John Donnelly
Hi
bhe(a)redhat.com
Suggested I forward this fix to you. It exists in RH8 and RH9
Please confirm
>
>This is the mailing list where kexec-tools package is maintianed. You
>can subscribe, send your problem description and finding, our colleages
>may check it
>kexec(a)lists.fedoraproject.org
....
> Hi
>
> There is a bug in /lib/kdump/kdump-lib.sh when there are LVM crypto volumes
> on the system :
>
>
> Provisioning during the installation. In this case lvm pool is created:
> # lvdisplay
> --- Logical volume ---
> LV Name pool00
> VG Name ol
> LV UUID LARWgk-Fgdq-naoV-R2eN-ooWQ-mcIF-N34LbR
> LV Write Access read/write (activated read only)
> LV Creation host, time localhost, 2021-11-16 14:06:22 -0500
> LV Pool metadata pool00_tmeta
> LV Pool data pool00_tdata
> LV Status available
> # open 0
> LV Size <20.15 GiB
> Allocated pool data 27.26%
> Allocated metadata 21.96%
> Current LE 5158
> Segments 1
> Allocation inherit
> Read ahead sectors auto
> - currently set to 8192
> Block device 252:5
>
>
>
> # kdumpctl rebuild
> kdump: Rebuilding /boot/initramfs-86_64kdump.img
>
>
> /lib/kdump/kdump-lib.sh: eval: line 939: syntax error near unexpected token
> `;'
> /lib/kdump/kdump-lib.sh: eval: line 939: `; echo $TYPE'
> /lib/kdump/kdump-lib.sh: eval: line 939: syntax error near unexpected token
> `;'
> /lib/kdump/kdump-lib.sh: eval: line 939: `; echo $TYPE'
> /lib/kdump/kdump-lib.sh: eval: line 939: syntax error near unexpected token
> `;'
> /lib/kdump/kdump-lib.sh: eval: line 939: `; echo $TYPE'
>
>
>
>
> # blkid -u filesystem,crypto -o export -- /dev/block/253:0
> DEVNAME=/dev/block/253:0
> UUID=a5ff3f28-3a29-4353-9a12-2c39e2b6d399
> TYPE=ext4
>
> kexec-tools]# eval "$(blkid -u filesystem,crypto -o export
> -- /dev/block/253:0); echo \$TYPE"
> ext4
>
> [ kexec-tools]# blkid -u filesystem,crypto -o export --
> /dev/block/11:0
> [root@ca-ostest469 kexec-tools]# eval "$(blkid -u filesystem,crypto -o
> export
> -- /dev/block/11:0); echo \$TYPE"
>
> bash: syntax error near unexpected token `;'
>
> so the error is seen if blkid is not able to extract information from block
> device
>
>
> The fix :
>
>
>
> Applying this patch will avoid printing the error message.
>
> --- kdump-lib.sh.org 2022-02-03 17:23:48.654000000 -0600
> +++ kdump-lib.sh 2022-02-03 17:25:53.962000000 -0600
> @@ -936,6 +936,13 @@
> {
> [[ -b /dev/block/$1 ]] || return 1
>
> + # If the given device is LVM private, skip.
> + blkid -u filesystem,crypto -o export -- /dev/block/$1 > /dev/null
> + if [ $? -ne 0 ]
> + then
> + return 1
> + fi
> +
> local _type=$(eval "$(blkid -u filesystem,crypto -o export --
> /dev/block/$1); echo \$TYPE")
> [[ $_type == "crypto_LUKS" ]] && echo $1
>
>
>
>
> It is a non-fatal error. kdumpclt rebuild still works.
>
> Is there a upstream github for this ? Or a contact you can share ?
1 year, 6 months
[PATCH v2 0/4] Add lvm2 thin provision support for kdump
by Tao Liu
Thin provision is a mechanism that you can allocate a lvm volume which has
a large virtual size for file systems but actually in a small physical
size. The physical size can be autoextended in use if thin pool reached a
threshold specified in /etc/lvm/lvm.conf.
There are 3 works should be handled when enable lvm2 thinp for kdump:
1) Check if the dump target device or directory is thinp device.
2) Monitor the thin pool and autoextend its size when it reached the threshold
during kdump.
3) If thin pool size-autoextend fails, the user space program will not know due to
buffered IO. So "sync -f vmcore" is used during kdump in 2nd kernel,
to force sync vmcore data into disk.
According to my testing, the memory consumption procedure for lvm2 thinp is the thin pool
size-autoextend phase. For fedora and rhel9, the default crashkernel value is enough. But
for rhel8, the default crashkernel value 1G-4G:160M is not enough, so it should
be handled particularly.
v1 -> v2:
1) Modified the usage of lvs cmd when check if target is lvm2 thinp
device.
2) Removed the sync flag way of mounting for lvm2 thinp target
during kdump, use "sync -f vmcore" to force sync data, and handle
the error if fails.
Tao Liu (4):
Add lvm2 thin provision dump target checker
Add lvm2-monitor.service for kdump when lvm2 thinp enabled
lvm.conf should be check modified if lvm2 thinp enabled
Fix the sync issue for dump_fs
dracut-kdump.sh | 10 ++++++++--
dracut-lvm2-monitor.service | 15 +++++++++++++++
dracut-module-setup.sh | 16 ++++++++++++++++
kdump-lib-initramfs.sh | 20 ++++++++++++++++++++
kdumpctl | 1 +
kexec-tools.spec | 2 ++
6 files changed, 62 insertions(+), 2 deletions(-)
create mode 100644 dracut-lvm2-monitor.service
--
2.33.1
1 year, 6 months
[PATCH 0/3] selftest: Add lvm2 thin provision selftest
by Tao Liu
This patch set is the follow up of patch set "Add lvm2 thin provision
support for kdump", it indroduces a selftest for lvm2 thinp.
Tao Liu (3):
selftest: Add lvm2 thin provision for kdump test
selftest: Only iterate the .sh files for test execution
selftest: Add "-F qcow2" for qemu-img cmdline
tests/scripts/image-init-lib.sh | 2 +-
tests/scripts/run-test.sh | 4 +-
.../lvm2-thinp-kdump/0-local-lvm2-thinp.sh | 59 +
.../testcases/lvm2-thinp-kdump/lvm.conf | 2455 +++++++++++++++++
4 files changed, 2517 insertions(+), 3 deletions(-)
create mode 100755 tests/scripts/testcases/lvm2-thinp-kdump/0-local-lvm2-thinp.sh
create mode 100644 tests/scripts/testcases/lvm2-thinp-kdump/lvm.conf
--
2.33.1
1 year, 6 months
[PATCH] kdump-lib: use non-debug kernels first
by Lichen Liu
Kdump uses currently running kernel as default, but when currently
running kernel is a debug kernel, it will consume more memory,
which may cause out-of-memory and fail to collect vmcore.
Now we will try to use non-debug kernels first if possible.
You can still specify the kernel by setting the KDUMP_KERNELVER in
/etc/sysconfig/kdump.
This patch may only works for Fedora and RHEL, since we rely on the
"+debug" suffix to determine if the currently running kernel is a
debug version. For other distros, fallback to using the currently
running kernel.
Signed-off-by: Lichen Liu <lichliu(a)redhat.com>
---
kdump-lib.sh | 33 +++++++++++++++++++++++++++++++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh
index b137c89..bd4eeed 100755
--- a/kdump-lib.sh
+++ b/kdump-lib.sh
@@ -642,11 +642,21 @@ prepare_kexec_args()
#
prepare_kdump_bootinfo()
{
- local boot_img boot_imglist boot_dirlist boot_initrdlist
+ local boot_img boot_imglist boot_dirlist boot_initrdlist nondebug_kernelver debug_kernelver debug_imglist
local machine_id dir img default_initrd_base var_target_initrd_dir
if [[ -z $KDUMP_KERNELVER ]]; then
KDUMP_KERNELVER="$(uname -r)"
+ nondebug_kernelver="$(echo -n "$KDUMP_KERNELVER" | sed -n -e 's/\(.*\)+debug$/\1/p')"
+ fi
+
+
+ # Use nondebug kernel if possible, because debug kernel will consume more memory and may oom.
+ if [[ -n $nondebug_kernelver ]]; then
+ dinfo "Trying to use $nondebug_kernelver."
+ debug_kernelver="$KDUMP_KERNELVER"
+ debug_imglist="$KDUMP_IMG-$debug_kernelver$KDUMP_IMG_EXT $machine_id/$debug_kernelver/$KDUMP_IMG"
+ KDUMP_KERNELVER="$nondebug_kernelver"
fi
read -r machine_id < /etc/machine-id
@@ -656,7 +666,11 @@ prepare_kdump_bootinfo()
# Use BOOT_IMAGE as reference if possible, strip the GRUB root device prefix in (hd0,gpt1) format
boot_img="$(sed "s/^BOOT_IMAGE=\((\S*)\)\?\(\S*\) .*/\2/" /proc/cmdline)"
if [[ -n $boot_img ]]; then
- boot_imglist="$boot_img $boot_imglist"
+ if [[ "$boot_img" == *"+debug"* ]]; then
+ debug_imglist="$boot_img $debug_imglist"
+ else
+ boot_imglist="$boot_img $boot_imglist"
+ fi
fi
for dir in $boot_dirlist; do
@@ -668,6 +682,21 @@ prepare_kdump_bootinfo()
done
done
+ if ! [[ -e $KDUMP_KERNEL ]]; then
+ if [[ -n $debug_kernelver ]]; then
+ dinfo "Fallback to using debug kernel"
+ for dir in $boot_dirlist; do
+ for img in $debug_imglist; do
+ if [[ -f "$dir/$img" ]]; then
+ KDUMP_KERNEL=$(echo "$dir/$img" | tr -s '/')
+ KDUMP_KERNELVER="$debug_kernelver"
+ break 2
+ fi
+ done
+ done
+ fi
+ fi
+
if ! [[ -e $KDUMP_KERNEL ]]; then
derror "Failed to detect kdump kernel location"
return 1
--
2.27.0
1 year, 6 months
[PATCH 0/4] Add lvm2 thin provision support for kdump
by Tao Liu
Thin provision is a mechanism that you can allocate a lvm volume which has
a large virtual size for file systems but actually in a small physical
size. The physical size can be autoextended in use if thin pool reached a
threshold specified in /etc/lvm/lvm.conf.
There are 3 works should be handled when enable lvm2 thinp for kdump:
1) Check if the dump target device or directory is thinp device.
2) Monitor the thin pool and autoextend its size when it reached the threshold
during kdump.
3) If thin pool size-autoextend fails, the user space program will not know due to
buffered IO. So the lvm2 thinp dump target should be mounted with sync flag, making
user space program know immediately if write fails.
According to my testing, the memory consumption procedure for lvm2 thinp is the thin pool
size-autoextend phase. For fedora and rhel9, the default crashkernel value is enough. But
for rhel8, the default crashkernel value 1G-4G:160M is not enough, so it should
be handled particularly.
Please review.
Tao Liu (4):
Add lvm2 thin provision dump target checker
Add lvm2-monitor.service for kdump when lvm2 thinp enabled
lvm.conf should be check modified if lvm2 thinp enabled
Mount the lvm2 thinp target with sync option
dracut-lvm2-monitor.service | 15 +++++++++++++++
dracut-module-setup.sh | 16 ++++++++++++++++
kdump-lib-initramfs.sh | 25 +++++++++++++++++++++++++
kdumpctl | 1 +
kexec-tools.spec | 2 ++
mkdumprd | 5 +++++
6 files changed, 64 insertions(+)
create mode 100644 dracut-lvm2-monitor.service
--
2.33.1
1 year, 6 months
Adding entry to KDUMP_COMMANDLINE_REMOVE= for CoreOS systems
by Dusty Mabe
Hi team,
In Fedora CoreOS we're going through some motions to be able to set up kdump on the first boot of
our machines. Part of this requires is to add `ignition.firstboot` to the `KDUMP_COMMANDLINE_REMOVE=`
entry in /etc/sysconfig/kdump. Would this be accepted upstream if we created a patch for it?
Thanks!
Dusty
1 year, 6 months
[RFC] tests: enable Gitlab CI
by Coiby Xu
With this patch, three kinds of tests are triggered when there is a
merge request created in a Gitlab kexec-tools repo,
- static analysis using shellcheck
- ShellSpec unit tests (test cases spec/)
- integration tests ( tests cases in tests/)
The tests are run inside a docker image named
'localhost/kexec_tools_gitlab_ci:0.3_f35' on a Specific runner [1]. This
docker image has all the needed software installed including fedpkg,
shellspec and etc. This Docker image also provides
/usr/share/cloud_images/Fedora-Cloud-Base-35-1.2.x86_64.qcow2 to avoid
repeatedly downloading the Fedora 35 cloud base image each time the
tests are triggered.
[1] https://docs.gitlab.com/ee/ci/runners/runners_scope.html#specific-runners
Signed-off-by: Coiby Xu <coxu(a)redhat.com>
---
A testing Gitlab repo has been set up on [1] and example test jobs can
be found on [2]. Any feedback is welcome!
[1] https://gitlab.com/coxu/fedora-kexec-tools
[2] https://gitlab.com/coxu/fedora-kexec-tools/-/pipelines/537217045
---
.gitlab-ci.yml | 31 +++++++++++++++++++++++++++++++
tools/run-integration-tests.sh | 16 ++++++++++++++++
2 files changed, 47 insertions(+)
create mode 100644 .gitlab-ci.yml
create mode 100755 tools/run-integration-tests.sh
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index 0000000..f94c987
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,31 @@
+image: "localhost/kexec_tools_gitlab_ci:0.3_f35"
+
+static-analysis-job:
+ stage: test
+ timeout: 1h
+ tags:
+ - kdump
+ only:
+ - pushes
+ script:
+ - shellcheck *.sh spec/*.sh kdumpctl mk*dumprd
+
+unit-tests-job:
+ stage: test
+ timeout: 1h
+ tags:
+ - kdump
+ only:
+ - pushes
+ script:
+ - ~/.local/bin/shellspec
+
+integration-tests-job:
+ stage: test
+ timeout: 8h
+ tags:
+ - kdump
+ only:
+ - pushes
+ script:
+ - bash ./tools/run-integration-tests.sh
diff --git a/tools/run-integration-tests.sh b/tools/run-integration-tests.sh
new file mode 100755
index 0000000..3ffcdb0
--- /dev/null
+++ b/tools/run-integration-tests.sh
@@ -0,0 +1,16 @@
+#!/bin/bash
+set -ex
+
+[[ -d ${0%/*} ]] && cd "${0%/*}"/../
+
+source /etc/os-release
+
+cd tests
+
+# fedpkg fetch sources based on branch.f$VERSION_ID.remote
+if ! git remote show | grep -q fedora_src; then
+ git remote add fedora_src https://src.fedoraproject.org/rpms/kexec-tools.git
+ git config --add branch.f$VERSION_ID.remote fedora_src
+fi
+
+BASE_IMAGE=/usr/share/cloud_images/Fedora-Cloud-Base-35-1.2.x86_64.qcow2 RELEASE=$VERSION_ID make test-run
--
2.35.3
1 year, 6 months
[PATCH v2 1/3] fix a calculation error in get_system_size
by Coiby Xu
Recently, it's found 'kdumpctl estimate' returns 512M while the system
reserves 1024M kdump memory in a case. This happens because the ranges
in /proc/iomem are inclusively. For example, "0-1: System RAM" means 2
bytes of system memory other than 1 byte. Fix this error by adding one
more byte.
Note
1. the function has been simplified as well.
2. define PROC_IOMEM as /proc/iomem for the sake of unit tests
Reported-by: Ruowen Qin <ruqin(a)redhat.com>
Fixes: 1813189 ("kdump-lib.sh: introduce functions to return recommened mem size")
Suggested-by: Philipp Rudo <prudo(a)redhat.com>
Signed-off-by: Coiby Xu <coxu(a)redhat.com>
---
kdump-lib.sh | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh
index 557eff6..ed28df3 100755
--- a/kdump-lib.sh
+++ b/kdump-lib.sh
@@ -788,17 +788,12 @@ prepare_cmdline()
echo "$cmdline"
}
-#get system memory size in the unit of GB
+PROC_IOMEM=/proc/iomem
+#get system memory size i.e. memblock.memory.total_size in the unit of GB
get_system_size()
{
- result=$(grep "System RAM" /proc/iomem | awk -F ":" '{ print $1 }' | tr "[:lower:]" "[:upper:]" | paste -sd+)
- result="+$result"
- # replace '-' with '+0x' and '+' with '-0x'
- sum=$(echo "$result" | sed -e 's/-/K0x/g' -e 's/+/-0x/g' -e 's/K/+/g')
- size=$(printf "%d\n" $((sum)))
- size=$((size / 1024 / 1024 / 1024))
-
- echo "$size"
+ sum=$(sed -n "s/\s*\([0-9a-fA-F]\+\)-\([0-9a-fA-F]\+\) : System RAM$/+ 0x\2 - 0x\1 + 1/p" $PROC_IOMEM)
+ echo $(( (sum) / 1024 / 1024 / 1024))
}
get_recommend_size()
--
2.35.3
1 year, 6 months
support for config dropins/overrides
by Dusty Mabe
Hi Team,
Editing /etc/sysconfig/kdump via something like `sed` is error prone and also
means I'll no longer get RPM updates to that file in the future. It would be
nice if we could have some sort of dropin configuration directly to override
default behavior (think systemd dropins) like a /etc/kdump.d/ directory.
Has there been any considering for such a feature? Does it sound like a good
or bad idea?
Dusty
1 year, 6 months
