I recently had to restore my system from a backup. Previously the filesystem resided in a logical volume in a luks container, by mistake I restored directly into/after the luks container.
Now, for all newer kernel installed the boot process gets stuck after reaching basic.target and eventually after a timeout dracut-initqueue reports repeatedly: dracut-initque: timeout, still waiting for following initqueue hooks: /lib/dracut/hooks/initqueue/finished/devexists-\x2dev\x2fmapper\x2fvgfedora-root.sh "if | grep -q After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup ..."
And eventually something like âdracut-initqueue: /dev/mapper/vgfedora-rootâ does not exist. Not all disks found. Regenerate initramfs.
Reading this it appears that for the initramfs for newer kernel, dracut somehow includes the reference to the old logical volume. However, I have been unable to locate and eliminate this reference in dracutâs configuration.
I would value any suggestions for a possible solution of this issue. Thank you,
Daniel
Is there an older kernel for which the boot works?
Each kernel has its own initramfs, in the sense: when kernel x is installed dracut builds an initram fs x with the relevant âconfigâ (which root fs etc) baked in. So, âinstallâ (i.e. initram creation) is the point in time where that config comes from, not âbootâ.
Thank you, @barryascott, for your suggestion. Indeed âșcreate a new initramfs that uses the new filesystem layoutâč is what I am trying to do. The problem is that some reference to the logical volume still gets included when I run sudo dracut -f /boot/initramfs-x.xx.xx-xxx.fc42.x86_64.img x.xx.xx-xxx.fc42.x86_64.
I am surprised to report that the regeneration of the grub config with grub2-mkconfig -o /boot/grub2/grub.cfg solved the problem as suggested in this forum post.