Check Whether vgconvert Still Converts LVM1

Someone finds an ancient LVM1 volume group and reaches for vgconvert to bring it up to date. On current LVM2 tools the command still exists, but the conversion code behind it does not: this guide gets you proof of that, fast, before you waste an afternoon on flags that cannot work.

This guide describes LVM tools 2.03.16(2), dated 2022-05-18, from the installed lvm2 package version 2.03.16-3ubuntu3.2. Allow about ten minutes. You need a shell and, for inspection of real storage, an account that can read the host's LVM devices. The checks below do not change volume groups or physical volumes.

1. Confirm which tool you have

Start with ordinary, read-only identity checks. These do not need elevated privileges, although LVM may print a warning when it cannot access device-mapper as an unprivileged user:

$ command -v vgconvert
/usr/sbin/vgconvert
$ vgconvert --version
  LVM version:     2.03.16(2) (2022-05-18)
  Library version: 1.02.185 (2022-05-18)
$ dpkg-query -W -f='${Package} ${Version}\n' lvm2
lvm2 2.03.16-3ubuntu3.2

Your package revision may differ. Record it before following advice copied from an older system, because historical vgconvert behaviour is not the behaviour of this installed release.

2. Read the command's current contract

Ask for help without naming a volume group:

$ vgconvert --help
  vgconvert - Change volume group metadata format

  vgconvert VG ...
        [ -f|--force ]
        [ -M|--metadatatype lvm2 ]
        [    --labelsector Number ]
        [    --bootloaderareasize Size[m|UNIT] ]
        [    --pvmetadatacopies 0|1|2 ]
        [    --metadatasize Size[m|UNIT] ]
        [    --reportformat basic|json ]

The synopsis is a trap for anyone reading only the option list. It still advertises a volume group argument and an lvm2 metadata type, but the description in the installed manual says that vgconvert is no longer part of LVM and that LVM1 support was removed. The listed -f, -y and metadata-area options do not restore that capability.

Checkpoint: If your task is specifically to convert LVM1 metadata to LVM2, stop here on this release. Do not add --force or --yes in the hope of bypassing the removal.

3. Demonstrate the result without changing metadata

Test mode disables metadata writing. Use a deliberately nonexistent group name so that you do not accidentally select a real group. This command is still a diagnostic only:

$ vgconvert --test definitely-not-a-vg
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
  The vgconvert command has been removed along with the lvm1 format.
  Use a previous version of lvm to convert the lvm1 format to lvm2.

On this machine the command exits with status 5. The exact warning prefix can vary with privilege and configuration, but the removal message is the meaningful result. Test mode is not a preview of a future successful conversion: the manual says it suppresses metadata writing and can report unusual errors in multi-stage operations. It is useful here only because the command emits its removal notice without any state change.

4. Inspect the host before choosing a recovery path

If you are unsure whether the volume group is LVM1, use read-only inventory commands as root or with sudo. Do not run a write command while trying to identify the format:

$ sudo pvs
$ sudo vgs
$ sudo pvscan

These commands can show the physical volumes and volume groups that the current LVM2 tools can discover. They do not convert metadata. If the old group is not visible, that absence is not proof that it is safe to initialise the disks. Stop before using pvcreate, pvremove, vgcreate or a recovery command on those devices.

Do not guess a device from /dev/sdX lettering. Confirm stable identities with lsblk -o NAME,PATH,SERIAL,UUID,FSTYPE and check mounts and backups before any recovery work. Elevated privileges are required for the inventory commands on many systems, but sudo does not make an unavailable converter appear.

5. Choose the migration boundary

The installed manual's supported answer is to use an older LVM version that still contains LVM1 conversion support. Treat that as a controlled recovery project, not as a command to paste into a production host. A suitable environment should be isolated, matched to the old data, and backed by a tested copy or image of every affected physical volume.

Keep the old system's binaries and libraries separate from the running host's normal /usr. Booting trusted rescue media or working from a clone can reduce the chance of mixing incompatible tools.

Before writing anything, capture the device list, make a verified backup, record the exact LVM version, and confirm that the copy can be restored. If the data matters, involve whoever owns the storage and schedule downtime: metadata conversion can make a volume group unavailable if the wrong device, format or recovery procedure is chosen.

There is no undo command for a failed conversion. Recovery means restoring the original metadata or disk image, then repeating the work with a verified procedure. Do not treat vgcfgbackup as a replacement for a block-level backup of an old or unreadable format; it can only help after the tools can successfully read the group.

6. Avoid common false starts

Adding -M lvm2: this is the historical-looking spelling, but the current program rejects the underlying operation because LVM1 support is gone.
Adding --force --yes: these override checks and prompts. They do not provide conversion code and can remove a useful safety boundary in other LVM commands.
Using --nolocking: the manual warns that concurrent commands can produce incorrect results. It is not a migration workaround.
Running pvcreate on an old disk: this is destructive to existing PV metadata. Never use it as a discovery step.
Assuming a zero exit from test mode proves success: test mode can return success without writing metadata. Always inspect the actual diagnostic and verify the resulting state separately.

Done means

You recorded the installed vgconvert and lvm2 versions.
You read the local manual's removal notice instead of relying on an old LVM1 example.
You reproduced the removal message with --test and a non-existent group name.
You have not used pvcreate, pvremove, force flags or a guessed device.
Any remaining conversion work has a verified backup, an isolated older-LVM environment and a recovery plan.