[PATCH] Install nfsv4-related drivers when users specify nfs dumping via dracut_args
by Coiby Xu
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2140721
Currently, if users specify dumping to nfsv4 target via
dracut_args --mount "<NFS-server-ip>:/var/crash /mnt nfs defaults"
it fails with the following errors,
[ 5.159760] mount[446]: mount.nfs: Protocol not supported
[ 5.164502] systemd[1]: mnt.mount: Mount process exited, code=exited, status=32/n/a
[ 5.167616] systemd[1]: mnt.mount: Failed with result 'exit-code'.
[FAILED] Failed to mount /mnt.
This is because nfsv4-releted drivers are not installed to kdump initrd.
mkdumprd calls dracut with "--hostonly-mode strict". If nfsv4-related
drivers aren't loaded before calling dracut, they won't be installed.
When users specify nfs dumping via dracut_args, kexec-tools won't mount
the nfs fs beforehand hence nfsv4-related drivers won't be installed.
Note dracut only installs the nfs driver i.e. nfsv3 driver for "--mount
... nfs". So also install nfsv4-related drivers when users specify nfs
dumping via dracut_args. Since nfs_layout_nfsv41_files depends on nfsv4,
the nfsv4 driver will be installed automatically.
As for the reason why we support nfs dumping via dracut_args instead of
asking user to use the nfs directive, please refer to commit 74c6f464
("Support special mount information via 'dracut_args'").
Fixes: 4eedcae5 ("dracut-module-setup.sh: don't include multipath-hostonly")
Reported-by: rcheerla(a)redhat.com
Signed-off-by: Coiby Xu <coxu(a)redhat.com>
---
mkdumprd | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/mkdumprd b/mkdumprd
index 3e250e02..51ca4f01 100644
--- a/mkdumprd
+++ b/mkdumprd
@@ -420,6 +420,15 @@ while read -r config_opt config_val; do
verify_core_collector "$config_val"
;;
dracut_args)
+
+ # When users specify nfs dumping via dracut_args, kexec-tools won't
+ # mount nfs fs beforehand thus nfsv4-related drivers won't be installed
+ # because we call dracut with --hostonly-mode strict. So manually install
+ # nfsv4-related drivers.
+ if [[ $(get_dracut_args_fstype "$config_val") == nfs* ]]; then
+ add_dracut_arg "--add-drivers" nfs_layout_nfsv41_files
+ fi
+
while read -r dracut_arg; do
add_dracut_arg "$dracut_arg"
done <<< "$(echo "$config_val" | xargs -n 1 echo)"
--
2.38.1
2 days, 2 hours
kdumpctl depends on grubby
by Michael Lipp
Hi,
I hope, this is the right place. "rpm -qf 92-crashkernel.install" led to
"kexec-tools", google led to
https://github.com/jesa7955/kexec-tools-fedora which led to this
mailinglist.
I've moved to systemd-boot. The instructions that I've used included
removing grubby. This might be excessive, but from the description
("grubby - command line tool for configuring grub, lilo, and elilo")
it's quite logical to do so.
However, the kernel-install plugin referenced above invokes "kdumpctl"
which depends on grubby (without an explicit package dependency).
From what I can see in kdumpctl, grubby seems to be used to obtain
information which is available in the loader directory of the
boot-partition. This information is generated on a system that boots
with grub2 as well. So maybe this should be changed from invoking grubby
to reading the information from the boot partition (/efi or /boot).
- Michael
4 weeks, 1 day
[PATCH] Use the correct command to get architecture
by Coiby Xu
`uname -m` was used by mistake. As a result, kexec-tools failed to
update crashkernel=auto during in-place upgrade from RHEL8 to RHEL9.
`uname -m` should be used to get architecture instead.
Fixes: 5951b5e2 ("Don't try to update crashkernel when bootloader is not installed")
Signed-off-by: Coiby Xu <coxu(a)redhat.com>
---
kdumpctl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kdumpctl b/kdumpctl
index 553c3924..2bec4281 100755
--- a/kdumpctl
+++ b/kdumpctl
@@ -1525,7 +1525,7 @@ reset_crashkernel()
_is_bootloader_installed()
{
- if [[ $(uname -r) == s390x ]]; then
+ if [[ $(uname -m) == s390x ]]; then
test -f /etc/zipl.conf
else
test -f /boot/grub2/grub.cfg
--
2.39.1
1 month
[PATCH 1/2] kdump-lib.sh: add support for 64K aarch64
by Pingfan Liu
On aarch64, both 4K and 64K kernel can be installed, while they demand
different size reserved memory for kdump kernel.
'get_conf PAGE_SIZE' can not work if installing a 64K kernel when
running a 4K kernel. Hence resorting to the kernel release naming rules.
At present, the 64K kernel has the keyword '64k' in its suffix.
Signed-off-by: Pingfan Liu <piliu(a)redhat.com>
---
kdump-lib.sh | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh
index 6b0a83d..d5d13bc 100755
--- a/kdump-lib.sh
+++ b/kdump-lib.sh
@@ -908,6 +908,7 @@ get_recommend_size()
# get default crashkernel
# $1 dump mode, if not specified, dump_mode will be judged by is_fadump_capable
+# $2 kernel-release, if not specified, got by 'uname -r'
kdump_get_arch_recommend_crashkernel()
{
local _arch _ck_cmdline _dump_mode
@@ -927,8 +928,21 @@ kdump_get_arch_recommend_crashkernel()
if [[ $_arch == "x86_64" ]] || [[ $_arch == "s390x" ]]; then
_ck_cmdline="1G-4G:192M,4G-64G:256M,64G-:512M"
elif [[ $_arch == "aarch64" ]]; then
- # For 4KB page size, the formula is based on x86 plus extra = 64M
- _ck_cmdline="1G-4G:256M,4G-64G:320M,64G-:576M"
+ local _running_kernel
+
+ if [[ -z "$2" ]]; then
+ _running_kernel=$(uname -r)
+ else
+ _running_kernel=$2
+ fi
+
+ if echo "$_running_kernel" | grep 64k; then
+ # For 64KB page size
+ _ck_cmdline="2G-:480M"
+ else
+ # For 4KB page size, the formula is based on x86 plus extra = 64M
+ _ck_cmdline="1G-4G:256M,4G-64G:320M,64G-:576M"
+ fi
elif [[ $_arch == "ppc64le" ]]; then
if [[ $_dump_mode == "fadump" ]]; then
_ck_cmdline="4G-16G:768M,16G-64G:1G,64G-128G:2G,128G-1T:4G,1T-2T:6G,2T-4T:12G,4T-8T:20G,8T-16T:36G,16T-32T:64G,32T-64T:128G,64T-:180G"
--
2.31.1
1 month
