Windows overrode a LVM pv metadata

Question

Yesterday I used windows' disk partition tool just to read the disk layout (didn't touch a thing, simply opened it). It looks like part of a volume group is overriden, at least name-wise (both label and UUID); lv tools always prompt an error about a missing partition, "pNvsomething-something".

According to /etc/lvm/archive, /dev/sdb and /dev/sdd1 are both used in the volume group.

    physical_volumes {
            pv0 {
                    id = "pNv7bl-5uND-rHH1-B3kK-Jcud-rxCm-7nJcKb"
                    device = "/dev/sdb"     # Hint only

                    status = ["ALLOCATABLE"]
                    flags = []
                    dev_size = 1953525168   # 931,513 Gigabytes
                    pe_start = 2048
                    pe_count = 238467       # 931,512 Gigabytes
            }

            pv1 {
                    id = "983nT1-PMwL-21Fz-tGw4-1ynZ-4JP9-s5OmGv"
                    device = "/dev/sdd1"    # Hint only

                    status = ["ALLOCATABLE"]
                    flags = []
                    dev_size = 1562500000   # 745,058 Gigabytes
                    pe_start = 2048
                    pe_count = 190734       # 745,055 Gigabytes
            }
    }

This is the output of blkid /dev/sdb:

/dev/sdb: PTUUID="2539097c-4f75-41e4-86c2-7e60f1f561ee" PTTYPE="gpt"

And /dev/sdb1:

/dev/sdb1: PARTLABEL="Microsoft reserved partition" PARTUUID="ce5feefa-d5ab-4ae4-8147-d06a81fe32d3"

I don't know where those 130mb of "Microsoft reserved partition" came from but I guess it's fine because the size displayed in lvm archive is the same displayed by lsblk.

sdb has a different UUID and partition type but seems to be exactly the same. I guess the 130mb partition was stolen from unallocated space yielded by resizing the lv partition. What should I do? mkfs and then point lvm to the new UUID? There shouldn't be any data overriden.

---

UPDATE

I've been looking around for a while and the mkfs idea was a dumb one, since it seems I should be using lvm tooling.

I can restore /etc/lvm/backup/nameOfVG and point the uuid to the correct device.

pvcreate --restorefile /etc/lvm/backup/datavg/ --uuid pNv-something /dev/sdb

The issue now is that pvcreate and other tools can't access /dev/sdb:

Device /dev/sdX not found (or ignored by filtering).

Some links:

• redhat docs

• redhat archives

Google also threw me some links to redhat solutions describing a really similar problem but they are behind a paywall.

• https://access.redhat.com/solutions/41764

• https://access.redhat.com/solutions/1132333

Answer 1

First: Newer run fsck (or mkfs or anything writing to FS/partition) if you want to rescue data from incomplete LVs. You always need to get PVs to their original state first with as few modifications as possible!

And second First: If possible take a backup first - you may need some data rescue software, and in any case it is better to run it on a copy of data, and keep original intact.

1. And what is lsblk displaying? And blkid? And sgdisk -p /dev/sdb? And what are the LVs: lvs --segments -a -o+pe_ranges? It is likely those 130MB was taken from start of /dev/sdb, so it is likely the first 130MB are damaged, if it was formatted.

2. Now you could use wipefs to remove the GPT signature and then you should be able to run the above pvcreate command. Or if you want more control overwrite only first sector (not sure that will be enough) - dd if=/dev/zero of=/dev/sdb bs=4k count=1.

3. In any case, I would rather take an opportunity and move the data inside a partition. If there is any chance the disk will be used by windows machine, it is strongly recommended to use partition table, so the LVM unaware systems do not consider it an unused disk.