Description of problem:
kdump.conf supports dracut_args for passing additional dracut options. It may be especially useful if we want to customize the dump target more than it is normally possible, then we can add the --mount option directly to dracut_args.
However, when doing something like 'dracut_args --mount "device mountpoint filesystem opts"', then restarting kdump service, inspecting lsinitrd shows that the --mount option is added incorrectly with the space character at the beginning of actual --mount argument. That seems to break parsing of the mount option that does not expect it to begin with a space.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. open /etc/kdump.conf
2. remove all standard target device lines
3. add 'dracut_args --mount "device mountpoint filesystem opts"' where device, mountpoint, etc are configuration of the dump target. You could instead add any other dracut command line option where it's argument requires spaces and must be quoted.
4. save the file and restart the kdump service
5. Inspect image via appropriate lsinitrd call.
The image shows dracut command with --mount option that has a quoted argument containing space at the beginning, also kdump itself does not work
The output of lsinitrd shouldn't indicate that there is any space at the beginning of quoted argument to --mount, and dumping should save vmcore to correct location.
I do not have direct console access and didn't really see the output of kdump initrd, however I know that it does not produce any vmcores in /var/crash, even though everything should be correct. I've also read the code especially of /bin/mkdumprd, and it seems that the current logic in add_dracut_arg will really add space at the beginning of quoted arguments. That breaks parsing because when the kdump-lib.sh splits the --mount option argument to get device or other mountpoint info, it uses cut and cut does not trim leading spaces. So I assume it causes the problem.
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 29 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
FEDORA-2020-2627d3ed28 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2627d3ed28
kexec-tools-2.0.20-9.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2627d3ed28
kexec-tools-2.0.20-9.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.