On Tue, Sep 22, 2020, 5:02 PM Zdenek Kabelac <zkabe...@redhat.com> wrote:
> Dne 21. 09. 20 v 15:47 Duncan Townsend napsal(a): > > On Mon, Sep 21, 2020 at 5:23 AM Zdenek Kabelac <zkabe...@redhat.com> > wrote: > >> > >> Dne 21. 09. 20 v 1:48 Duncan Townsend napsal(a): > >>> Hello! > > > > Ahh, thank you for the reminder. My apologies for not including this > > in my original message. I use Void Linux on aarch64-musl: > > > >>> I had a problem with a runit script that caused my dmeventd to be > >>> killed and restarted every 5 seconds. The script has been fixed, but > >> > >> Kill dmeventd is always BAD plan. > >> Either you do not want monitoring (set to 0 in lvm.conf) - or > >> leave it to it jobs - kill dmeventd in the middle of its work > >> isn't going to end well...) > > > > Thank you for reinforcing this. My runit script was fighting with > > dracut in my initramfs. My runit script saw that there was a dmeventd > > not under its control, and so tried to kill the one started by dracut. > > I've gone and disabled the runit script and replaced it with a stub > > that simply tried to kill the dracut-started dmeventd when it receives > > a signal. > > Ok - so from looking at the resulting 'mixture' of metadata you > have in your archive and what physically present on PV header are > and now noticing this is some 'not-so-standard' distro - I'm starting to > suspect the reason of all these troubles. > I'm running void linux, and I haven't messed with the initramfs at all from the defaults. I'll report this to the distro maintainers. Thanks! Withing 'dracut' you shouldn't be firering dmeventd at all - monitoring > should be enabled (by vgchange --monitor y) once you switch to your rootfs > so dmenventd is execute from your rootfs! > > By letting 'dmeventd' running in your 'dracut world' - it lives in its > own environment and likely its very own locking dir. > > That makes it very easy your dmeventd runs in parallel with your other > lvm2 > commands - and since this way it's completely unprotected > (as file-locking is what it is) - as the resize is operation for several > seconds it has happened your 'admins' command replaced whatever dmeventd > was > doing. > 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. 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. where XXX == YYY + 2. Is this indicative of a deeper problem? I'm hesitant to run any further operations on this volume without advice because I think I'm in fairly uncharted territory now. Thank you again for all your help! --Duncan Townsend P.S. This was typed on mobile. Please forgive any typos. >
_______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
