Dne 08. 12. 19 v 21:47 Łukasz Czerpak napsal(a):
After googling a lot I figure out what to do and it worked - at least I can
access the most critical data.
I’ve followed instructions from this blog post:
https://blog.monotok.org/lvm-transaction-id-mismatch-and-metadata-resize-error/
However, I have no idea what was the root cause of this. I hope I can fully
recover the volumes w/o re-creating the whole VG.
In case I did something terribly wrong that looked like the solution now, but
may cause issues in future - I would appreciate any hints.
$ lvchange -ay vg1
WARNING: Not using lvmetad because a repair command was run.
Thin pool vg1-thinpool1-tpool (253:3) transaction_id is 549, while expected 505.
Hi
What's been you lvm2 & kernel version ?
This difference is too big for 'recent' versions - there should never be more
then one - unless you are using old kernel & old lvm2.
Regards
Zdenek
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
