> Maybe this should be fixed upstream.
Have you reported it upstream?

Not yet. Later I will recompile lvmetad with -g and try to get a coredump.

LVM2 has received an update since. Is this still an issue?

any status? No response in 4 months.

Yes, this is still an issue. Every time I rebuild the initial ram disk it renders my sytem unbootable. Only by patching your initrd init script I can work around it.

Is this still an issue with lvm2 2.02.108-1?

I assume you are talking about the latest update from 2014-07-27? I don't exactly know of the segfault, but after upgrading the initial ram disk, my system was again not in a bootable state. So I assume - yes, this is still an issue. I applied the following hack in my "/var/lib/initcpio/init" script just before mounting root.

killall -9 lvmetad
lvm vgchange -ay

Maybe I am doing something stupid here, but at least it works. The initial ram disk worked before using vgchange -ay and after the upgrade to lvmetad a while ago it did not anymore. I observed the segfaults back then. It seems I am the only one having this problem? So I should definitely debug this further. However my debugging capabilities are a bit limited in the busy box and I am also not so happy working with a non-booting system ;)

I'm not sure I've been experiencing this same bug (or else I solved some other bug). But there is a typo in the file: /usr/lib/initcpio/hooks/lvm2

The first line reads:
#!/usr/bin/ash

But it must be:
#!/usr/bin/bash

Next after a `# mkinitcpio -p linux` my server boots up normal again....I hope it helps.

That's not a typo. Busybox use the ash shell. All hooks in /usr/lib/initcpio/hooks/ use that. I don't know why replacing it by bash works for you since ash works for most people I believe.

That shebang is only a placebo, mainly useful for making sure editors use the correct syntax highlighting. The hook script is never executed, but only sourced from the main init script. Whatever that line says is completely irrelevant.

I can reproduce this (or a highly similar) issue here. 100% of the time.

Booting results in being dropped in a shell. In my case however, it is lvm (not lvmetad) that crashes.

simply running lvm vgchange -a y; exit

is enough to continue the boot process.

I also see the behaviour @hacosta described. Sometimes I also run into #41833, so the vgchange -ay hangs and i have to reboot and try again. Not a nice situation to be unable to reboot my home server remotely to make kernel updates or something like that...

With lvm2 2.03.11-3 in [core] now lvmetad is gone.