kdump-utils-1.0.44-2.fc41.x86_64 Running "kdump rebuild" on a standard Fedora 41 cloud image produces a initrd that wont boot when the kernel crashes. It hangs waiting for a disk that will never appear: [ **] Job dev-disk-by\x2dpath-pci\x2d0000…ice/start running (29s / no limit) I think this happens because the kdump initrd has these arguments: # lsinitrd /boot/initramfs-6.11.0-0.rc3.30.fc41.x86_64kdump.img Image: /boot/initramfs-6.11.0-0.rc3.30.fc41.x86_64kdump.img: 34M ======================================================================== Version: dracut-102-3.fc41 Arguments: --add 'kdumpbase' --quiet --hostonly --hostonly-cmdline --hostonly-i18n --hostonly-mode 'strict' --hostonly-nics '' --aggressive-strip -o 'plymouth resume ifcfg earlykdump' --mount '/dev/disk/by-path/pci-0000:00:04.0-part /kdumproot defaults' --squash-compressor 'zstd' --no-hostonly-default-device -f Note the "--mount '/dev/disk/by-path/pci-0000:00:04.0-part /kdumproot defaults'" part. /dev/disk/by-path/pci-0000:00:04.0-part is a directory, not a device node. I think these arguments are wrong because /var is a btrfs subvolume: # findmnt /var TARGET SOURCE FSTYPE OPTIONS /var /dev/vda4[/var] btrfs rw,relatime,seclabel,compress=zstd:1,discard=async,space_cache=v2,subvolid=258,subvol=/var Changing the "path" in kdump.conf to "/crash" (without "/var") produces a working initrd. It has these arguments: # lsinitrd /boot/initramfs-6.11.0-0.rc3.30.fc41.x86_64kdump.img Image: /boot/initramfs-6.11.0-0.rc3.30.fc41.x86_64kdump.img: 35M ======================================================================== Version: dracut-102-3.fc41 Arguments: --add 'kdumpbase' --quiet --hostonly --hostonly-cmdline --hostonly-i18n --hostonly-mode 'strict' --hostonly-nics '' --aggressive-strip -o 'plymouth resume ifcfg earlykdump' --mount '/dev/disk/by-uuid/98723e31-b94f-4b1f-a619-f08c352cf776 /sysroot btrfs rw,relatime,seclabel,compress=zstd:1,discard=async,space_cache=v2,subvolid=256,subvol=/root' --squash-compressor 'zstd' --no-hostonly-default-device -f Reproducible: Always
I think this bug is the same as https://bugzilla.redhat.com/show_bug.cgi?id=2270423. So let me reassign it to Lichen.
Hi Marius, this issue has the same root cause with 2357959, so let's track it in one ticket. Thanks, Lichen *** This bug has been marked as a duplicate of bug 2357959 ***