Symptoms & scope
- The expected /dev/mapper/VG-LV root device never appears during early boot.
- An older image may boot while a newly generated host-only image cannot find root.
Relevant environment
Linux root on an LVM logical volume, possibly inside LUKS or over RAID, using a distribution initramfs.
Recognizable messages (synthetic examples)
dracut-initqueue[400]: Warning: /dev/mapper/vg0-root does not existCheck whether this mapping belongs to LVM or encryption before choosing activation steps; the path alone does not prove lost LVM metadata.
Possible causes
These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.
- LVM userspace or its activation rules may be absent from the initramfs.
- A restrictive rd.lvm.lv selector, devices filter or still-locked lower layer may hide required physical volumes; missing PV data needs separate storage recovery.
Diagnose safely
Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.
Check 1
Read volume metadata without changing it; administrator access to physical volumes is usually needed. In rescue, unlock known lower layers through the supported process first.
lvs --readonly -o vg_name,lv_name,devicesInterpret the result: Confirm the intended VG/LV and its physical devices. --readonly avoids activation changes and is not a test that the logical volume is currently mounted or active.
Check 2
Replace KERNEL and the path with the selected dracut image; lsinitrd reads image contents, not the live root. For other generators use their documented listing utility.
lsinitrd /boot/initramfs-KERNEL.imgInterpret the result: Look for LVM tools, configuration and required lower-layer modules. Their presence is necessary for the setup but does not prove activation selectors or device visibility are correct.
Evidence-guided next steps
Restore early LVM support
If the metadata is intact in rescue but the selected image lacks LVM support, rebuild that kernel’s initramfs with the distribution’s LVM module/hooks and required lower storage layers. Retain a general-purpose or older working image.
Precautions: Do not create a new PV/VG/LV over existing storage to make the expected name appear. Verify mounted /boot/ESP and image free space first.
Recovery / rollback: Boot the retained image and restore the prior LVM hook configuration if the rebuild still fails.
Did this solution help you?
Correct the verified LVM discovery selector
If the command line restricts activation to an old VG/LV name, update only that verified selector through the distribution’s boot configuration and regenerate its entries. Check encryption and devices-file rules when the lower PV is not visible.
Precautions: Keep the original metadata unchanged. A filter correction cannot recover a physically missing PV and should not bypass the intended storage visibility policy broadly.
Recovery / rollback: Restore saved boot/selective-discovery configuration and choose the previous image if the change selects the wrong root volume.
Did this solution help you?
References & review
This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.
- dracut LVM activation selectors and early modules (project or distribution documentation)
- LVM lvs read-only metadata reporting (project or distribution documentation)