>So run "kpartx -a /dev/mapper/<yourmultipathdevice>" on each multipath >device and then run LVM scan. >If LVM still uses paths and complains about duplicate PVs, then you may >need create a right filter in /etc/lvm/lvm.conf to use intended devices. >I hope this is not necessary. This works and is a huge improvement. At least I can get my devices back into multipath manually. Thanks so much for this. I still need to get to the bottom of why these specific volumes are getting grabbed before multipath can get them, but this is a big step. >Did you enable multipathd service (I thought it should call kpartx or maybe a udev rule)? Yes, it's chkconfig'ed on, and I bumped forward its start order to start up prior to lvm2-monitor, thinking lvm2-monitor (which does vgscan) might be part of the problem. >> [root@testfs foo]# find . -print | grep -i multi >> ./lib/modules/2.6.33.8-149.fc13.x86_64/kernel/drivers/md/dm-multipath.ko >The dm-multipath.ko kernel module is present. It needs multipath command >calling from an initrd script (/init ???) I'm not positive that I'm sure what you're asking. Do you mean the init.d script I reference above, or is there some other configuration change to call mulitpath from initrd? I feel much better knowing that I can get back to a proper configuration manually, but any ideas about why this is happening on bootup? FYI, I played around with filtering in lvm.conf in my first night of troubleshooting and tried filtering out all /dev/sd.* drives other than /dev/sda, but it seems like dracut was ignoring the lvm filters, despite the lvm.conf. With the filter in place a pvscan would find no duplicates (and no sd.* devices) but on reboot dracut would find them all and report the dupes. Thanks for your help so far Malahal. -Brian -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
