Description of problem: A recent Fedora 32 update broke kdump. Version-Release number of selected component (if applicable): kexec-tools-2.0.20-10.fc32.x86_64 dracut-050-1.fc32.x86_64 kernel-5.6.0-0.rc4.git0.1.fc32.x86_64 How reproducible: Always Steps to Reproduce: 1. Enable kdump: grub2-editenv - set "$(grub2-editenv - list | grep ^kernelopts) crashkernel=256M" reboot 2. systemctl start kdump.service 3. Crash the kernel: echo 1 > /proc/sys/kernel/sysrq echo c > /proc/sysrq-trigger Actual results: Shutdown has several failed units, this causes the machine to hang forever: ] Reached target Switch Root. [ 3.769026] systemd[1]: Starting Cleanup squashfs mounts when switch root... Starting Cleanup squashfs mounts when switch root... [ 3.781939] systemd[1]: squash-root.mount: Succeeded. [ 3.785306] systemd[1]: usr.mount: Succeeded. [ 3.788211] systemd[1]: etc.mount: Succeeded. [ 3.791628] systemd[1]: squash-mnt-clear.service: Succeeded. [ OK [ 3.795701] systemd[1]: Started Cleanup squashfs mounts when switch root. ] Started Cleanup squashfs mounts when switch root. [ 3.801518] systemd[1]: Starting Switch Root... Starting Switch Root... [ 3.814946] systemctl[477]: Failed to switch root: Specified switch root path '/sysroot' does not seem to be an OS tree. os-release file is missing. [ 3.820649] systemd[1]: initrd-switch-root.service: Main process exited, code=exited, status=1/FAILURE [ 3.824335] systemd[1]: initrd-switch-root.service: Failed with result 'exit-code'. [ 3.827558] systemd[1]: Failed to start Switch Root. [FAILED] Failed to start Switch Root. See 'systemctl status initrd-switch-root.service' for details. [ 3.838288] systemd[1]: Startup finished in 1.131s (kernel) + 0 (initrd) + 2.706s (userspace) = 3.838s. [ 3.841750] systemd[1]: initrd-switch-root.service: Triggering OnFailure= dependencies. [ 3.846654] systemd[1]: Starting Kdump Emergency... [ 3.850571] systemd[1]: Starting Setup Virtual Console... [ 3.854645] systemd[479]: systemd-vconsole-setup.service: Failed to execute command: No such file or directory [ 3.858307] systemd[479]: systemd-vconsole-setup.service: Failed at step EXEC spawning /usr/lib/systemd/systemd-vconsole-setup: No such file or directory [ 3.863018] systemd[1]: systemd-vconsole-setup.service: Main process exited, code=exited, status=203/EXEC [ 3.866733] systemd[1]: systemd-vconsole-setup.service: Failed with result 'exit-code'. [ 3.870233] systemd[1]: Failed to start Setup Virtual Console. [ 3.882034] systemd[1]: kdump-error-handler.service: Failed to open /usr/lib/systemd/system/kdump-error-handler.service: No such file or directory Failed to start kdump-error-handler.service: Operation refused, unit may not be isolated. See system logs and 'systemctl status kdump-error-handler.service' for details. [ 3.892813] systemd[1]: emergency.service: Main process exited, code=exited, status=4/NOPERMISSION [ 3.896339] systemd[1]: emergency.service: Failed with result 'exit-code'. [ 3.899443] systemd[1]: Failed to start Kdump Emergency. [ 3.902066] systemd[1]: Dependency failed for Emergency Mode. [ 3.904716] systemd[1]: emergency.target: Job emergency.target/start failed with result 'dependency'. Expected results: System reboots (though kexec), and /var/crash/* has a vmcore and associated -dmesg.txt.
This is much more likely a regression in dracut. It is now broken in fedora 31 with updates-testing as well, but the kexec-tools update (https://bodhi.fedoraproject.org/updates/FEDORA-2020-599bdb7c34) already went in a month ago. dracut-050-25.git20200313.fc31 went in two days ago (https://bodhi.fedoraproject.org/updates/FEDORA-2020-b36b25de24), and that correlates with the breakage.
Hi, I can confirm the kdump issue this is a kexec-tools problem, I will fix it on kexec-tools side soon. *** This bug has been marked as a duplicate of bug 1812434 ***