On Tue, Sep 22, 2020, 5:02 PM Zdenek Kabelac <zkabelac@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 <zkabelac@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.

>