On Wed, Sep 23, 2020 at 2:49 PM Zdenek Kabelac <zkabelac@xxxxxxxxxx> wrote: > > Dne 23. 09. 20 v 20:13 Duncan Townsend napsal(a): > > On Tue, Sep 22, 2020, 5:02 PM Zdenek Kabelac <zkabelac@xxxxxxxxxx > > > > dmeventd does write its PID file into the correct directory in the > > post-initramfs root, so whatever's happening is some weird hybrid. I'll debug > > this further with my distro. > > > > So I think to prevent repeated occurrence of this problem - you'll need > > to ensure your system-booting will follow the pattern from distros > > like Fedora. > > > > > > I think for now, the easiest solution may be to try to stop dmeventd from > > being started by dracut. > > Basically all you need to do for dracut (with reagards to dmeventd) is to > setup inside dracut environemnt 'monitoring=0' in /etc/lvm/lvm.conf there. > (so when it's copied system's lvm.conf there - replace with sed/awk...) > > Also there is 'metadata_read_only=1' setting that can be useful for > dracut environment. Thanks for the advice! > Dracut needs some bigger fixing on its own - but ATM we simply can't > provide set of features we would like to have. > > > I have encountered a further problem in the process of restoring my thin pool > > to a working state. After using vgcfgrestore to fix the mismatching metadata > > using the file Zdenek kindly provided privately, when I try to activate my > > thin LVs, I'm now getting the error message: > > > > Thin pool <THIN POOL LONG NAME>-tpool transaction_id (MAJOR:MINOR) > > transaction_id is XXX, while expected YYY. > Set the transaction_id to the right number in the ASCII lvm2 metadata file. I apologize, but I am back with a related, similar problem. After editing the metadata file and replacing the transaction number, my system became serviceable again. After making absolutely sure that dmeventd was running correctly, my next order of business was to finish backing up before any other tragedy happens. Unfortunately, taking a snapshot as part of the backup process has once again brought my system to its knees. The first error message I saw was: WARNING: Sum of all thin volume sizes (XXX TiB) exceeds the size of thin pool <VG>/<THIN POOL LV> and the size of whole volume group (YYY TiB). device-mapper: message ioctl on (MAJOR:MINOR) failed: File exists Failed to process thin pool message "create_snap 11 4". Failed to suspend thin snapshot origin <VG>/<THIN LV>. Internal error: Writing metadata in critical section. Releasing activation in critical section. libdevmapper exiting with 1 device(s) still suspended. There were further error messages as further snapshots were attempted, but I was unable to capture them as my system went down. Upon reboot, the "transaction_id" message that I referred to in my previous message was repeated (but with increased transaction IDs). I will reply privately with my lvm metadata archive and with my header. My profuse thanks, again, for assisting me getting my system back up and running. --Duncan Townsend _______________________________________________ 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/
