System stuck during boot after reaching basic.target

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

From your description and the error I assume that your filesystems do not match the code in the initramfs.

You either need to fix your data restore error or create a new initramfs that uses the new filesystem layout.

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.

Sorry for the imprecise phrasing and thank you for your reply, @mjg .

Yes, I have one older initramfs-kernel-pair that works

Understood. The problem is that I am unable to find the config which references my old file system configuration.

1 Like

Do the UUID’s in /etc/fstab match your disk layout?

You can use lsblk -f to see the details of your disks.

They do.

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.

2 Likes