Bugzilla Bug 58798

When booting the 2004.2 amd64 Universal LiveCD, then trying to create/activate
LVM volumes, the LVM tools will crash (segmentation fault) the first time you
run one (I have tried both vgscan and pvcreate), and then all subsequent
invocations of any LVM tool will hang, consuming 100% of CPU until killed.  If
the /dev/md devices are filtered out in /etc/lvm/lvm.conf with 'devices {
filter=["r/md/"] }', then everything works fine.  This is true whether I have
md devices activated or not.  (The problem is that I want to put LVM on an md
device, so I can't just filter out those devices and proceed).

I have tried this with the x86 (32-bit) LiveCD and it works fine.  I have also
used a Debian From Scratch boot CD with an amd64 kernel, and its LVM tools work
fine.  (DFS CD images available from http://people.debian.org/~jgoerzen/dfs/). 
Therefore, it seems apparent that this is a Gentoo-specific bug.  (Though I
suppose the DFS CD might be using 32-bit LVM binaries, whereas perhaps the
Gentoo CD has 64-bit binaries, but I'm not sure about that.)



Reproducible: Always
Steps to Reproduce:
1. Boot 2004.2 amd64 Universal LiveCD on amd64 platform
2. Execute 'vgscan' (or 'pvcreate').  It will segfault.
3. Execute 'vgscan' or any other LVM tool.  It will hang, consuming 100% of CPU
until it is killed.

Actual Results:  
See above -- first invocation segfaults, subsequent tries hang.

Expected Results:  
'vgscan' should have found no LVM volumes.  I should then be able to create
volumes with pvcreate, vgcreate, and lvcreate.


My hardware:

CPU: Athlon64 3000+
RAM: 2x512MB PC3200 ECC RAM (1GB total)
Mobo: MSI K8N Neo Platinum (nVidia nForce3 250Gb chipset, most recent BIOS from
MSI -- v1.1)
Disk: 2x120GB SATA (Samsung SpinPoint), attached to onboard SATA controller
(these show up as /dev/hde and /dev/hdg, but only after I've loaded the
ide-disk
module)
CDROM: Generic ATAPI drive on IDE0 (/dev/hda)

I can't paste 'emerge info' output, because I haven't gotten that far in the
installation yet.

I have built a version of lvm2 with debugging symbols, to track down where the
segfault is.  It occurs at line 71 of lib/filters/filter.c, which is:

[...]
  if (!(((int *) f->private)[MAJOR(dev->dev)])) {
[...]

I don't know what this means, but I might dive into the code a bit to find out,
if I have time.  I'll keep this report updated with any new information I
discover.

Looks like it dies when the scan of /dev gets to /dev/mdd128, and I think I
know why: they hardcode 255 as the highest device major number, and I think
that's not a valid assumption when devfs is in use.  (That explains why it
didn't happen on my Debian boot CD, since they don't use devfs.)  So this
appears to be an upstream bug, not a Gentoo bug.  I will go submit it to the
LVM maintainers and see what they make of it.  In the meantime, I may create a
patch of my own.

What does 'lvm version' return?

It was meant to be fixed in 2.00.20 / dm 1.00.19

Output of 'lvm version':

  LVM version:     2.00.08 (2003-11-14)
  Library version: 1.00.17-ioctl (2004-04-19)
  Driver version:  4.1.0

So it looks like the problem will be fixed if Gentoo updates to the newer version.  I'd be happy to test this on my system, once an ebuild is available.

Assigning to maintainer

fyi, this is happening to me on an AMD 32-bit CPU running the SMP kernel as
well...

fyi, this is happening to me on an AMD 32 bit CPU with an SMP kernel as well
(off the livecd)

FYI - I was having this issue under initrds - upgraded to LVM 2.00.24 - all good :)

If anyone stumbles on this problem before it is fixed upstream, the workaround
is:

/etc/lvm/lvm.conf

devices {
    filter=["r|cdrom|, "r|^/dev/md|"]
    }

BTW: I am having this problem with a clean install of 2004.3 on x86 following
the installation manual and the LVM2 documents from gentoo. Maybe it should be
mentioned there.

So people using .25 confirm all is good and we'll mark this as done and bump to
stable.  Better yet verify that .31 is happy (just copy .25 to .31 -- there's
no build changes, just some man page updates and some minor other fixes).

I am installing gentoo on an Athlon 64 using 2004.3 and used LVM on top of a
RAID partition and it went out without problems so far. (the installation is
not finished yet).

Success confirmation - using .08, I had segfaults; using .25 or .33 I do not
(.31 isn't available any more).
CFLAGS="-march=athlon -O3 -pipe -fomit-frame-pointer"

I couldn't filter out /dev/md because that's what I'm trying to LVM. :)

The required packages to have this fixed are marked stable (as per the user
comments). Closing. Re-open if it's still an issue.