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.
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.
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/
