Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#37346 - [lvm2] lvmetad segfaults in initial ramdisk

Attached to Project: Arch Linux
Opened by Daniel Mendler (minad) - Tuesday, 15 October 2013, 12:18 GMT
Last edited by Doug Newgard (Scimmia) - Thursday, 27 September 2018, 14:29 GMT
Task Type Bug Report
Category Upstream Bugs
Status Assigned
Assigned To Christian Hesse (eworm)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 3
Private No



I use a setup with software raid 5 and lvm on top of it for the root fs. In the lvm2 early hook lvmetad segfaults which prevents the system from disconvering the root partition and continuing with the boot process. However if I don't start lvmetad and instead use "vgchange -ay" root is found.

My hooks:

HOOKS="base udev autodetect modconf block mdadm_udev lvm2 filesystems keyboard fsck"

Maybe this should be fixed upstream. But I also want to notify you here of the problems.
This task depends upon

Comment by Dave Reisner (falconindy) - Tuesday, 15 October 2013, 12:52 GMT
> Maybe this should be fixed upstream.
Have you reported it upstream?
Comment by Daniel Mendler (minad) - Tuesday, 15 October 2013, 14:02 GMT
Not yet. Later I will recompile lvmetad with -g and try to get a coredump.
Comment by Thomas Bächler (brain0) - Friday, 22 November 2013, 09:31 GMT
LVM2 has received an update since. Is this still an issue?
Comment by Gerardo Exequiel Pozzi (djgera) - Wednesday, 12 February 2014, 01:50 GMT
  • Field changed: Status (Assigned → Waiting on Response)
  • Field changed: Category (Packages: Core → Upstream Bugs)
  • Field changed: Severity (Critical → High)
any status? No response in 4 months.
Comment by Daniel Mendler (minad) - Wednesday, 12 February 2014, 11:19 GMT
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.
Comment by Eric Belanger (Snowman) - Monday, 04 August 2014, 02:58 GMT
Is this still an issue with lvm2 2.02.108-1?
Comment by Daniel Mendler (minad) - Monday, 04 August 2014, 11:30 GMT
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 ;)
Comment by Ronald (BobDay) - Saturday, 16 August 2014, 20:17 GMT
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:

But it must be:

Next after a `# mkinitcpio -p linux` my server boots up normal again....I hope it helps.
Comment by Eric Belanger (Snowman) - Saturday, 16 August 2014, 21:42 GMT
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.
Comment by Thomas Bächler (brain0) - Sunday, 17 August 2014, 00:08 GMT
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.
Comment by héctor (hacosta) - Tuesday, 09 June 2015, 04:34 GMT
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.
Comment by Alexander Blinne (Sunday) - Wednesday, 16 December 2015, 11:05 GMT
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...