kdump-utils 1.0.52-2.fc42.x86_64 dracut 105-2.fc42.x86_64 This is related to bug 2306035. The recent upgrade of dracut 103-3.fc42 to 105-2.fc42 in our CI images has broken kdump initrd generation with the default config when /var is on btrfs. Kdump itself didn't change, but it uses shell functions from dracut, which did change. Specifically, when /var is on btrfs, mkdumprd ends up calling get_persistent_dev from /usr/lib/dracut/dracut-functions.sh with a empty string. Older versions of get_persistent_dev would not fail when given the empty string. They would just return a bogus result, resulting in a initrd that wouldn't work (see bug 2306035). The newer versions will now fail. The result is the following unhelpful output from kdumpctl: # kdumpctl rebuild kdump: Rebuilding /boot/initramfs-6.14.0-63.fc42.x86_64kdump.img kdump: mkdumprd: failed to make kdump initrd Reproducible: Always
I just spent an hour investigating this in https://github.com/linux-system-roles/kdump/pull/233#issuecomment-2800567079 . This is hilariously hard to debug. Even KDUMP_STDLOGLVL=3 KDUMP_SYSLOGLVL=3 KDUMP_KMSGLOGLVL=3 sh -x kdumpctl start doesn't give something useful. Calling /sbin/mkdumprd -f /boot/initramfs-6.14.0-63.fc42.x86_64kdump.img 6.14.0-63.fc42.x86_64 fails completely silently, and running that with `sh -x` is inscrutable. Thanks Marius for investigating!
(In reply to Martin Pitt from comment #1) > I just spent an hour investigating this in > https://github.com/linux-system-roles/kdump/pull/233#issuecomment-2800567079 > . This is hilariously hard to debug. Even > > KDUMP_STDLOGLVL=3 KDUMP_SYSLOGLVL=3 KDUMP_KMSGLOGLVL=3 sh -x kdumpctl > start > > doesn't give something useful. Calling > > /sbin/mkdumprd -f /boot/initramfs-6.14.0-63.fc42.x86_64kdump.img > 6.14.0-63.fc42.x86_64 > > fails completely silently, and running that with `sh -x` is inscrutable. > Thanks Marius for investigating! Hi Martin, Debugging with `debug=1 kdumpctl rebuild`, I think this issue happens because kdump does not support btrfs subvol now.
(In reply to Lichen Liu from comment #2) > I think this issue happens because kdump does not support btrfs subvol now. If you don't want to support it, please make it fail with a clear error message. Don't send people on wild goose chases, please.
(In reply to Marius Vollmer from comment #3) > (In reply to Lichen Liu from comment #2) > > I think this issue happens because kdump does not support btrfs subvol now. > > If you don't want to support it, please make it fail with a clear error > message. Don't send people on wild goose chases, please. OK, I think we can keep this bug for improving the error messages. For btrfs support, I don't have a plan to support it now, but I have added it to the future feature list.
(In reply to Marius Vollmer from comment #3) > (In reply to Lichen Liu from comment #2) > > I think this issue happens because kdump does not support btrfs subvol now. > > If you don't want to support it, please make it fail with a clear error > message. Don't send people on wild goose chases, please. Hi Marius, we added basic btrfs support in kdump-uitls 1.0.59, it works on Fedora SilverBlue with the default configuration, can you help to test this issue? Thanks, Lichen
*** Bug 2306035 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora Linux 42 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13. 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 'version' of '42'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 42 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
/sbin/mkdumprd -f /boot/initramfs-6.19.13-300.fc44.x86_64.img 6.19.13-300.fc44.x86_64 This seems to work now, so closing. Thanks!