broken vg after vgconvert -M1

broken vg after vgconvert -M1

[Stas Sergeev]

Hello.

I tried to convert my VG to LVM1 format.
I use lvm2-2.02.33, and vgconvert segfaults.
Not knowing that the problem is alreay
fixed in CVS, I made the attached patch.
The conversion then succeeded, according
to the vgconvert message, but now I get
---
  Invalid LV in extent map (PV /dev/sdb3, PE 0, LV 0, LE 0)
  Couldn't fill logical volume maps.
  Volume group "fedora_vg" not found
---
from any lvm tool.
Oddly enough, vgck says the same.
I am a bit confused about that. Are there
any ways to recover the vg now? And what
could lead to the corruption? Could my patch
be guilty, or are there other bugs in vgconvert?

I also wonder how the lvnum_from_lvid()
supposed to ever work at all. It iterates
32 times in a loop, multiplying the int32
variable by 64 every iter. But only 5
iterations are safe, the rest may (and does)
overflow.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lvnum.diff
URL: <http://listman.redhat.com/archives/lvm-devel/attachments/20081205/229b3406/attachment.ksh>

broken vg after vgconvert -M1

[Alasdair G Kergon]

On Fri, Dec 05, 2008 at 02:44:36PM +0300, Stas Sergeev wrote:
> I tried to convert my VG to LVM1 format.
> I use lvm2-2.02.33, and vgconvert segfaults.
> Not knowing that the problem is alreay
> fixed in CVS, I made the attached patch.
> The conversion then succeeded, according
> to the vgconvert message, but now I get
> ---
>  Invalid LV in extent map (PV /dev/sdb3, PE 0, LV 0, LE 0)
>  Couldn't fill logical volume maps.
>  Volume group "fedora_vg" not found
> ---
> from any lvm tool.

The error you should have got was:
  Logical volume lvol0 lvid format is incompatible with requested metadata format.
and it should have refused to let you run the vgconvert unless you changed
the UUIDs manually first.

(This is a pretty rare requirement, downgrading the metadata format.)

To recover, you should: update to a newer version such as 2.02.42 or 2.02.43,
find a suitable metadata backup file, edit it to ensure the LV UUIDs are
compatible with LVM1 (ie small consecutive numbers with leading zeroes)
then use vgcfgrestore.

> could lead to the corruption? Could my patch
> be guilty

Yes - in that your metadata was incompatible with LVM1
and the tool previously stopped you from doing the conversion,
albeit by crashing instead of giving you a nice error.
 
Alasdair
-- 
agk at redhat.com

broken vg after vgconvert -M1

[Stas Sergeev]

Alasdair G Kergon wrote:
> To recover, you should: update to a newer version such as 2.02.42 or 2.02.43,
> find a suitable metadata backup file, edit it to ensure the LV UUIDs are
> compatible with LVM1 (ie small consecutive numbers with leading zeroes)
> then use vgcfgrestore.
Thanks. The backup is hopefully still there
on that broken lvm partition. I'll try to
extract it from the raw partition dump.

> Yes - in that your metadata was incompatible with LVM1
> and the tool previously stopped you from doing the conversion,
> albeit by crashing instead of giving you a nice error.
I think this is just a coincidence. It
crashed not after the first invocation
of lvnum_from_lvid(). Most calls to it
used to return the large positive numbers.
Only one uuid was giving the negative,
hence the crash. Without that uuid, it
would convert even without the patch, I
think.
The patch only prevents the negative
values, but gives the huge positive
values instead - why it didn't complain
and let it to convert then? All the other
instances of lvnum are of uint32_t too.
Also, I think there can be the uuids that
will give the small positive numbers after
overflow, so expecting the large values
is probably unreliable.
So is this really an expected behaveour
to allow the conversion when lvnum is a
huge positive value? That's just what
happened in my case, and I am trying to
make sure there is no bug elsewhere and
that it was really just my patch.

broken vg after vgconvert -M1, trying to recover

[Stas Sergeev]

Hello.

Alasdair G Kergon wrote:
> To recover, you should: update to a newer version such as 2.02.42 or 2.02.43,
> find a suitable metadata backup file, edit it to ensure the LV UUIDs are
> compatible with LVM1 (ie small consecutive numbers with leading zeroes)
> then use vgcfgrestore.
OK, I recovered the backup from the
partition dump and upgraded lvm2 to
2.0.43. I changed the LV IDs, and
vgcfgrestore says this:
---
  PV /dev/sdb3 is a different format (seqno lvm1)
  Restore failed.
---

And if I also change the pv0 id,
I get this:
---
  Couldn't find device with uuid '000000-0000-0000-0000-0000-0000-000009'.
Segmentation fault
---

The segfault comes from archiver.c:296 -
pv->dev is NULL here, but the check is
missing.
Attached is my restored metadata backup.
Please let me know how can I recover from
that.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bb
URL: <http://listman.redhat.com/archives/lvm-devel/attachments/20081208/c0172d49/attachment.ksh>

broken vg after vgconvert -M1, trying to recover

[Stas Sergeev]

Stas Sergeev wrote:
> OK, I recovered the backup from the
> partition dump and upgraded lvm2 to
> 2.0.43.
Should be read as 2.02.43