Open jbtrystram opened 2 days ago
I find downgrading systemd to systemd-stable-255.10 on F41 could make kdump work again. Note I built systemd-stable-255.10 from source as latest systemd on F41 is v256.
The other thing I find is that pci-0000:04:00.0-part
is only shown in f41, and it is a folder.
ls -lh /dev/disk/by-path/ |grep pci-0000:04:00.0-part$
drwxr-xr-x. 7 root root 140 Oct 25 03:18 pci-0000:04:00.0-part
On f40:
ls -lh /dev/disk/by-path/ |grep pci-0000:04:00.0-part$
echo $?
1
This symbol link is created by /usr/lib/udev/rules.d/60-persistent-storage.rules
. Those udev rules are introuced by this commit https://github.com/systemd/systemd/commit/3af66c089b930b7191c1964f2ea30448fe9688de
For unmounted nfs, dracut cannot determine it's fstype findmnt -e -v -n -o 'FSTYPE' --source "$_find_dev" and dracut will use 0:0 as its maj:min, unfortunately, the output of stat -L -c '%t:%T' /dev/disk/by-path/pci-0000:04:00.0-part/ is also 0:0, so dracut treats them as the same device and writes the latter as a persistent name to the dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-path\x2fpci-0000:04:00.0-part.sh
.
I think this bug consists of three parts:
These factors together cause the second kernel to wait for an impossible task - mounting /dev/disk/by-path/pci-0000:04:00.0-part/
Using the following config in fedora coreOS 41 :
The initramfs indefinitely wait after mounting
kdumproot.mount
:using kexec-tools-2.0.29-1 I tried to downgrade
nfs-utils-coreos
to the f40 rpm but it does not fix the issue.The same setup works fine in F40.