LVM2 is normally set to ignore block devices which contain md (software RAID) superblocks. It fails to detect version 1.x md RAID superblocks. This problem is present in all upstream versions including the latest 2.02.24 This problem can result in RAID arrays becoming inconsistent without the RAID driver knowing about it. (Data corruption) I am working on genkernel patches to allow MD-type arrays to be activated during early userspace. It is highly desirable to only activate the array that contains the root filesystem, and allow the rootfs to bring up other arrays. IF LVM2 support is enabled initramfs AND initrams (or the kernel) activates a software RAID array (type 1 superblock) AND other arrays exist, but are not activated before LVM starts AND those arrays contain LVM data THEN data corruption is likely I've been searching for other ways around this problem, and it appears that the best approach is to simply extend the lvm2 md superblock detection to work on the new array types. Reproducible: Always Steps to Reproduce: 1. Create mdadm array with type 1 superblock 2. Start array 3. Create physical volume & volume group on the array 4. Make sure md_component_detection is enabled in lvm.comf 5. Stop array 6. Run 'pvscan' & 'vgchange -a y' Actual Results: Two identical PVs are detected. The volume group is activated on one of the devices. If a system is allowed to continue booting and running, underlying partitions will be mounded and the RAID will become inconsitent (if it isn't already) Expected Results: Block devices with MD superblocks should be filtered/ignored. I hate to consider this a bug in LVM. However, the default behavior of LVM is to run out and activate everything it can find (for better or worse.) Another workaround might involve using mdadm to detect md devices in early userspace and auto-generating an lvm.conf file to ignore detected devices. However, the genkernel maintainer wants to keep mdadm out of early userspace due to its size. The alternative, mdassemble, doesn't provide the necessary functionality to achieve this workaround. I'm hopeful that one of the gentoo maintainers can pressure upstream developers to fix lvm instead.
upstream lvm looks to be fixed already.
