[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] oblem with lvm and multipath on fedora 13



>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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]