Description of problem: The latest rawhide bash errors out for `bad substitution` for /lib/kdump/kdump-lib.sh file in ${_src#${_src_nofsroot}[} when we try to enable kdump.service It fails for bash-5.2.0-2.fc38.x86_64 and bash-5.2.2-1.fc38.x86_64 It works for bash-5.1.16-4.fc38 Error: ``` Oct 06 21:37:11 cosa-devsh kdumpctl[1291]: grep: warning: stray \ before - Oct 06 21:37:11 cosa-devsh kdumpctl[1322]: /lib/kdump/kdump-lib.sh: line 192: bad substitution: no closing `}' in ${_src#${_src_nofsroot}[} Oct 06 21:37:11 cosa-devsh kdumpctl[1170]: kdump: mkdumprd: failed to make kdump initrd Oct 06 21:37:11 cosa-devsh kdumpctl[1170]: kdump: Starting kdump: [FAILED] Oct 06 21:37:11 cosa-devsh systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE Oct 06 21:37:11 cosa-devsh systemd[1]: kdump.service: Failed with result 'exit-code'. Oct 06 21:37:11 cosa-devsh systemd[1]: Failed to start kdump.service - Crash recovery kernel arming. ``` Version-Release number of selected component (if applicable): bash-5.2.0-2.fc38.x86_64 How reproducible: Every time Steps to Reproduce: 1. Get up a machine with the latest rawhide bash rpm packages 2. Enable kdump service with `systemctl enable kdump.service` Actual results: Enabling the service results in error for bad substitution as shown in the description above Expected results: The kdump.service should be enabled with no errors. Additional info: Filing under the bash component because it appears to be a backwards compatibility break, but if it was intentional, please re-assign to kdump.
Thanks for the report! Upstream discussion: https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00022.html Related patch: https://git.savannah.gnu.org/cgit/bash.git/diff/subst.c?h=devel&id=22f21b760ed90eb77c3756e6ccf39b73c84f532a Minimal reproducer: #!/bin/bash foo="foobar" string_to_remove="foo" bar=${foo#${string_to_remove}[} echo $bar
Review https://src.fedoraproject.org/rpms/bash/pull-request/36?
Looks good.
FEDORA-2022-6d7a87b3aa has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-6d7a87b3aa
FEDORA-2022-1551c099fc has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-1551c099fc
FEDORA-2022-1551c099fc has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-1551c099fc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-1551c099fc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-6d7a87b3aa has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-6d7a87b3aa` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6d7a87b3aa See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I am investigating what may be a related failure that popped up after upgrading F36 5.1.16-3 to 5.2.2-1, and still seems to be present in 5.2.2-2 (will report later.) Meanwhile, something that hinders testing is that neither $BASH_VERSION nor 'bash --verbose' report the release number (e.g. -1 or -2). Can that be fixed?
(In reply to Bruce Jerrick from comment #8) > I am investigating what may be a related failure ... I have filed 2134307: 'sh' fails to recognize an eval'd alias inside $() command substitution The circumstances are similar but seem sufficiently different to warrant a separate report. (I included a link to this report in that new one, but don't see a way to add the opposite link from here to there.)
FEDORA-2022-6d7a87b3aa has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-1551c099fc has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.