Data recovery -- thin provisioned LVM metadata (?) problem

[haaber]

Dear all,

I had a lethally bad hardware failure on computer.  Since I had to buy a
new machine this took a while, now I try to save some data: the old SSD
is attached to a brand-new qubes via usb adapter. I started

sudo pvscan    and   sudo vgscan --mknodes    and sudo vgchange -ay as
manual says.

unexpected output:

 PV /dev/mapper/OLDSSD   VG qubes_dom0      lvm2 [238.27 GiB / <15.79
GiB free]
  Total: 1 [238.27 GiB] / in use: 1 [238.27 GiB] / in no VG: 0 [0   ]
  Found volume group "qubes_dom0" using metadata type lvm2
  Check of pool qubes_dom0/pool00 failed (status:1). Manual repair
required!

  1 logical volume(s) in volume group "qubes_dom0" now active

then I consulted dr. google for help, and found little help. This one

https://mellowhost.com/billing/index.php?rp=/knowledgebase/65/How-to-Repair-a-lvm-thin-pool.html

suggested to deactivate volumed so that a repair can work. Only swap was
active, I deactivated it. But repair does not work:

lvconvert --repair qubes_dom0/pool00
terminate called after throwing an instance of 'std::runtime_error'
  what():  transaction_manager::new_block() couldn't allocate new block
  Child 21255 exited abnormally
  Repair of thin metadata volume of thin pool qubes_dom0/pool00 failed
(status:-1). Manual repair required!


So now I am struck and ask for help! This is not purely qubes-related, I
known, but I hope to find competent help within the community.


cheers, Bernhard

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I suggest asking on the LVM mailing list.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmRHzzMACgkQsoi1X/+c
IsGTQhAAyq6YJy49jm5Hdihcw76C2s+OvUm2yvb2mZbpuPymhpo/ZIX7V1Moqdc3
WJ8cRjrbN8lztlLCPmkL+jAqk5PAw556jYon++9Apt3fwvFGL35hJ0bU7rumRUxF
uGQPjCZAWVVxlD3Q0ejbE3pSAafUbbPgroIoCMHnDdIARkF/OliEDdf0/CdALtPL
2KpIAI10Zd9MSlNB5O7KHKhStemfw7huFN6i0TJc284lD/WtkLeIWxHf96RPzb//
LMNB1zCAMGDBukHV1+zBqSySo0wSVAIvNX1rQyce4l6vrNO7C8bkHcmKm/FKvvk8
CCNet5QAEEr5+U5mogN+S54mmHrtDT84uonw5QzDAR+SiUJaTwe3auLIez8jtI16
wlZsMv4J4klRM9PqJKXaXV+VTd11QT33Zo53kFrFbEjtKr41Bc/bmVH5U7CdxhkH
X2MHeq/ZAs/xzQgEAFhxgnlzcG5qGlNEpzEP4et21cBRNdI68iVmvw7W8VN0fDjx
vsTHz1hpAcpfG3XajX08Co75z+DVCmDxWFVTjfUED+ODKx1Z1KJCBtfMYZfSiHyN
G4ID0jopbxNYU90PX3HTCS1xRQsT1Gsy3UUc5AjWGXlcMmhkTZch96vXOTlphlu8
cEgQFzJBZ/vWBBMhNPadBY2Pv7MOeAQOaEEBbJKRlVglnclL0Hw=
=48UK
-----END PGP SIGNATURE-----

[unman]

On Tue, Apr 25, 2023 at 08:19:48AM +0200, haaber wrote:

Hi Bernhard
Havent seen you for a while. Nice to see you back.
I've been able to fix this in the past by deleting snapshots - I'm not
sure if this will work for you.
If I were you I would take a copy of the SSD with dd, and then start to
prune - what happens if you use lvremove against some of the larger
snapshots?
unman