If the containers started you dont need to delete them
That’s just in this test PV I quickly created. When I try to start the container with the production data, I’m getting the error message about an unexpected transaction_id.
By the way, I can confirm that I have no issues with regards to lvm tools interaction in the newly created PV. I can activate the thin volumes, resize them, inactivate the whole vg, activate it, in between start the container, stop it, I didn’t run into any other issues there.
1 Like
I suspect that is LVM corruption due to incompatibility between either the meta data cache or the LVM version on the host vs the snap. I don’t know how to recover that as have never done it myself. My approach would be to recreate and restore from backups (although if I understand correctly you don’t have backups right?).
This article may be of use:
https://blog.monotok.org/lvm-transaction-id-mismatch-and-metadata-resize-error/
That’s what I was working with all weekend. Unfortunately, it didn’t work because LXD all the time overwrote the meta data again. That’s what got me completely bonkers.
So, with the new flag, maybe it’s worth a try…
Finally, some good news. With the new flag active, I was able to restore the vg backup from a rescue system, having changed the transaction_id manually before. After rebooting the system, I can now play around with the volume using lvmtools, set it active, inactive, resize it, start the container, stop it, and so on, I don’t have problems anymore.
I really appreciate your help tonight @tomp and @stgraber. But please consider making a change in this LVM behavior.
1 Like
@tomp One last thing for today, you mentioned that I should remove the minimal image as well as any container connected to it. The container is now working fine. How would I go about removing it without making my life overly difficult? Is it fine if I use lxc export and later import it back using lxc import, does this “sever” the link to the faulty image?
No need to remove it if its working