On Mon, Apr 25, 2016 at 1:58 PM, Zdenek Kabelac <zkabelac@xxxxxxxxxx> wrote:
Actually don't understand what's this table and what's wrong with that. There is no traces of DM_TABLE_STATE variable in lvm2 sources. Yet there is such variable in udev rules file that comes with multipath sources:
On 25.4.2016 12:52, Peter Volkov wrote:There is a problem: udev does not create partitions for multipath devices in
case I use kpartx.rules provided with multipath sources. I found that udev
always go to kpartx_end after following line of rules:
ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end"
Just curious - what would you want to do with inactive table???
Actually don't understand what's this table and what's wrong with that. There is no traces of DM_TABLE_STATE variable in lvm2 sources. Yet there is such variable in udev rules file that comes with multipath sources:
You cannot read/scan such device ?
The problem I have - multipath with udev's help creates /dev/mapper/mpatha block device but does not create devices for partitions, e.g. /dev/mapper/mpatha1. I found that this happens due to udev rule mentioned above. After execution rule on line 10 (ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end") udev goes directly to kpartx_end and rule on line 45 (..."/sbin/kpartx -u -p -part /dev/$name") is never executed.
There is 8 (!!!) years old thread that discusses this problem:
https://www.redhat.com/archives/dm-devel/2007-July/msg00095.html
So what is the current state? Should we fix udev rules for multipath or should
we create better patch for dmsetup.c? Meanwhile I've copied multipath.rules
from redhat and partitions are created as they should.
What is the exact problem you do have/see ?
Can you describe in some single repeatable steps a reproducer ?
Install udev rules file from mutlipath tools and see that partitions are not created.
Which distro are you talking about (Fedora ? Debian ??)
That's Gentoo. But I think any distro that uses whatever upstream prepares have this problem.
Have you opened any bugzilla anywhere ?
Not yet. I'd like to understand what needs to be done first.
--
Peter.
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
