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.
