Repair LVM Device Nodes Safely with vgmknodes

Use vgmknodes when an active LVM logical volume should have a device node under /dev, but that node is missing or stale. The command checks the nodes needed by active logical volumes, creates missing ones, and removes unused ones. It does not create a logical volume, activate an inactive volume, or repair damaged LVM metadata.

This guide takes about 10 minutes if the volume group is already healthy. The examples use LVM 2.03.16(2), from Ubuntu package lvm2 2.03.16-3ubuntu3.2. Run inspection commands as an ordinary user where possible. The repair command normally needs root because it works with device-mapper and /dev.

Checkpoint: confirm the problem first

Do not start by forcing a node into existence. First check whether the logical volume is active and whether LVM can see it. Replace example-vg and data with values from your host.

sudo lvs -o vg_name,lv_name,lv_attr,lv_path
ls -l /dev/example-vg/data /dev/mapper/example--vg-data

An active LV normally has an LV path and a corresponding device-mapper path. If lvs cannot see the LV, or its attributes show that it is inactive, vgmknodes is not the first repair. Investigate activation, locking, device visibility, or metadata instead. Creating a node for an inactive or unavailable LV would only make the symptom harder to read.

1. Check the installed command

Confirm which binary is being used and record its version when troubleshooting. This matters because LVM options and device-discovery defaults can differ between releases.

command -v vgmknodes
sudo vgmknodes --version

On the version covered here, the version report identifies LVM as 2.03.16(2) (2022-05-18) and the device-mapper library as 1.02.185. The command also accepts --help and --longhelp if you need to compare a different installation.

2. Preview without changing metadata

Use test mode before a repair if you are working on a production host or are unsure which configuration LVM will read. It disables metadata writing and reports success to the calling function, but it can still produce unusual messages when a multi-stage operation expects a change that test mode did not make.

sudo vgmknodes --test --verbose

Test mode does not guarantee that the host can talk to device-mapper. A permission error for /dev/mapper/control, a missing kernel driver, or a locking failure is a separate problem. Treat those messages as a checkpoint: fix access or LVM infrastructure before interpreting the preview as a complete health check.

3. Repair the nodes

When the LV is active and the preview is sensible, run the command without test mode. This is the state-changing step and should be done with elevated privileges.

sudo vgmknodes

With no positional argument, vgmknodes considers the LVM device nodes needed by active LVs. It creates missing nodes and removes nodes that are no longer used. That removal is deliberate, so do not run it while another process is manually creating or consuming device nodes.

The normal command may produce little or no output. Ask for verbose output when you need an audit trail:

sudo vgmknodes --verbose

Afterwards, repeat the inspection from the first checkpoint:

sudo lvs -o vg_name,lv_name,lv_attr,lv_path
ls -l /dev/example-vg/data /dev/mapper/example--vg-data

Do not use --yes reflexively. It answers prompts yes and is intended for automation with care. Likewise, avoid --nolocking unless you understand the concurrency consequences: the manpage warns that concurrent commands can produce incorrect results.

4. Limit the scope when necessary

A volume group, logical volume, or tag can be supplied as a positional argument. Start with the volume group when you want a narrower repair:

sudo vgmknodes example-vg

An LV positional argument generally uses the form VG/LV:

sudo vgmknodes example-vg/data

Use a tag only when your host already uses a known LVM tag convention:

sudo vgmknodes @repair-candidates

These arguments select LVM objects; they are not paths under /dev. A path such as /dev/example-vg/data is not a substitute for the documented VG/LV form.

When repair does not fix access

If the node appears but opening the LV still fails, stop repeating vgmknodes. Check whether the LV is active, whether the kernel device-mapper interface is available, and whether LVM can see the physical devices it needs. On a shared or locked volume group, investigate the locking service rather than adding --ignorelockingfailure blindly. That option permits read-only metadata operations after a locking failure; it does not make concurrent writes safe.

If you ran the command against the wrong group, the command has no general undo switch. Its normal effect is to reconcile nodes with active LVs. Re-activate the intended LVs through the usual LVM workflow, then run vgmknodes again. Do not recreate device nodes by hand as a permanent fix: udev and device-mapper should own the normal lifecycle.

Done means

• lvs shows the intended LV as active and gives its expected LV path.
• The expected /dev node and mapper path exist and can be inspected.
• vgmknodes --test --verbose produced no unexplained infrastructure error.
• sudo vgmknodes completed with the intended scope.
• You have not used --nolocking or --yes merely to silence a problem.