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. ***