Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
kdump path points to lvm thinpool
When executing kdumpctl (i.e. when rebuilding the kdump ramdisk) it displays the following error
/lib/kdump/kdump-lib.sh: eval: line 925: syntax error near unexpected token `;'
Version-Release number of selected component (if applicable):
kexec-tools-2.0.20-57.el8.x86_64
How reproducible:
Always but only on RHEL8.5, earlier versions of kexec-tools are not impacted.
Steps to Reproduce:
Create lvm thinpool
# vgcreate vg00 /dev/vdb
# lvcreate -L 9G -T vg00/thinpool
# lvcreate -V 5G -T vg00/thinpool -n crashvol
# mkfs.xfs /dev/vg00/crashvol
Mount /dev/vg00/crashvol
- Configure kdump:
# sed -i 's/^path.*/path \//g' /etc/kdump.conf
# sed -i '/^path/a xfs /dev/mapper/vg00-crashvol' /etc/kdump.conf
- Rebuild crash kernel initramfs and observe errors:
# kdumpctl rebuild
kdump: Rebuilding /boot/initramfs-4.18.0-348.2.1.el8_5.x86_64kdump.img
/lib/kdump/kdump-lib.sh: eval: line 925: syntax error near unexpected token `;'
/lib/kdump/kdump-lib.sh: eval: line 925: `; echo $TYPE'
/lib/kdump/kdump-lib.sh: eval: line 925: syntax error near unexpected token `;'
/lib/kdump/kdump-lib.sh: eval: line 925: `; echo $TYPE'
/lib/kdump/kdump-lib.sh: eval: line 925: syntax error near unexpected token `;'
/lib/kdump/kdump-lib.sh: eval: line 925: `; echo $TYPE'
Actual results:
executing kdumpctl it displays the following error
/lib/kdump/kdump-lib.sh: eval: line 925: syntax error near unexpected token `;'
Expected results:
executing kdumpctl does not display syntax error
Additional info:
In kdump-lib.sh get_luks_crypt_dev() is passed device, in our case "/dev/mapper/vg00-crashvol", which is a block device so passes initial test. This device is then passed to loop to check slave devices to see if they are ontop of crypt device. It is the slave devices that trigger the syntax error as "blkid -u filesystem,crypto -o export -- /dev/block/$1" returns nothing.
e.g.
By adding 'echo $1' to line 925 in /lib/kdump/kdump-lib.sh, then sourcing the script and calling 'get_luks_crypt_dev' , we can see which block device is causing the error:
~~~
# udevadm info /dev/vg00/crashvol | grep -A1 MAJOR
E: MAJOR=253
E: MINOR=6
# source /lib/kdump/kdump-lib.sh
# get_luks_crypt_dev 253\:6
253:6
253:4
-bash: eval: line 0: syntax error near unexpected token `;'
-bash: eval: line 0: `; echo $TYPE'
253:2
-bash: eval: line 0: syntax error near unexpected token `;'
-bash: eval: line 0: `; echo $TYPE'
252:16
253:3
-bash: eval: line 0: syntax error near unexpected token `;'
-bash: eval: line 0: `; echo $TYPE'
252:16
- Querying one of the slave block devices that returned an error, we see that blkid is unable to return any information. `udevadm` shows the device belongs to the thinpool.
# blkid -o list /dev/block/253\:4
device fs_type label mount point UUID
--------------------------------------------------------------------------------------------------
# udevadm info /dev/block/253\:4 | grep S\:
S: mapper/vg00-thinpool-tpool
~~~
get_luks_crypt_dev() works on a block device so we probably would need something earlier possibly a new test in check_crypt() in /sbin/mkdumprd to check if we are on a thinpool or not before calling get_luks_crypt_dev()
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (kexec-tools bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2022:7705