Bug 2357959

Summary:	kdump fails to generates initrd with default config
Product:	[Fedora] Fedora	Reporter:	Marius Vollmer <mvollmer>
Component:	kdump-utils	Assignee:	Lichen Liu <lichliu>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	42	CC:	coxu, lichliu, mpitt
Target Milestone:	---	Keywords:	Regression
Target Release:	---	Flags:	lichliu: mirror+
Hardware:	x86_64
OS:	Linux
Whiteboard:	CockpitTest
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2026-05-06 15:20:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Marius Vollmer 2025-04-07 15:32:33 UTC

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

Comment 1 Martin Pitt 2025-04-14 06:09:53 UTC

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!

Comment 2 Lichen Liu 2025-04-14 06:49:22 UTC

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

Comment 3 Marius Vollmer 2025-04-14 17:23:33 UTC

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

Comment 4 Lichen Liu 2025-04-15 12:17:33 UTC

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

Comment 5 Lichen Liu 2025-11-24 08:06:05 UTC

(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

Comment 6 Lichen Liu 2025-11-24 08:08:42 UTC

*** Bug 2306035 has been marked as a duplicate of this bug. ***

Comment 7 Fedora Release Engineering 2026-05-06 12:33:58 UTC

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.

Comment 8 Martin Pitt 2026-05-06 15:20:11 UTC

/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!