kpartx udev rule is broken

[Phillip Susi]

Binary package hint: multipath-tools

The kpartx udev rule looks like this:

ENV{DM_STATE}=="ACTIVE", ENV{DM_UUID}=="dmraid-*", \
        RUN+="/sbin/kpartx -a -p -part /dev/$kernel"

This kpartx command should not be run because dmraid already creates the partition device, but it isn't run anyhow because the rule matches on "dmraid-*" but dmraid devices have an id of the form "DMRAID-*". Note the difference in case.

[Phillip Susi (psusi)]

Checked Debian sid and they seem to have dropped the modprobe rule. Created branch to drop both rules, and fix the other rule that tries to match on "dmraid=*" to "DMRAID-*".

[Serge Hallyn (serge-hallyn)]

Thanks for reporting this bug and helping to make Ubuntu better.

Debian has actually never had this rule. It was added in Ubuntu to avoid the need for the multipath-tools-boot script.

The '-Q' option has been fixed some time ago. What release are you on?

[Phillip Susi (psusi)]

The modprobe was added in Ubuntu, but the dmraid- is also there in debian. It looks like it has been changed to a lower case -q in Natty, but I'm still running Maverick.

[Serge Hallyn (serge-hallyn)]

Ah, I see. We didn't SRU because it did not seem to cause any regression. Is this really preventing it from working for you? If so, we should SRU bug 644481. I will mark this bug a dup of that one. Please comment there if you find it needs to be SRUd to maverick and lucid.

Please open a separate bug for the DMRAID issue you raised, explaining why and how it breaks.

Thanks again.

[Phillip Susi (psusi)]

I'll just drop the part about the -Q then, rather than file a new bug about the other parts, especially since I already have it linked to the debian bug about the rest.

Still the rules trying to match multipath and dmraid and run kpartx are broken. The one for dmraid should not be there at all, and the one for kpartx I bet also has the wrong case, and as I mentioned in bug #712840, should not be using -p anyhow.

[Serge Hallyn (serge-hallyn)]

Quoting Phillip Susi (<email address hidden>):
> I'll just drop the part about the -Q then, rather than file a new bug
> about the other parts, especially since I already have it linked to the
> debian bug about the rest.

That works :)

> Still the rules trying to match multipath and dmraid and run kpartx are
> broken. The one for dmraid should not be there at all, and the one for
> kpartx I bet also has the wrong case, and as I mentioned in bug #712840,
> should not be using -p anyhow.

In /lib/activate/devmapper.c? Definately looks true.

So one or the other should change. Let's see which way Debian goes.

Thanks again. I really do appreciate what you're doing with trying
to commonize the conventions.

[Jesse Johnson (holocronweaver)]

I believe Philip may be incorrect about the dmraid rule not belonging. I have a RAID 5 disk with a GPT partition table. When only dmraid runs, my drive is listed in /dev/mapper/drive but not its partitions. If I then run 'kpartx -a /dev/mapper/drive' then my two partitions appear as /dev/mapper/drive1 and /dev/mapper/drive2 which can both be mounted. Therefore kpartx must run even after dmraid already added the tables since dmraid cannot handle GPT partition tables. Note that you are right that this is not needed for standard MBR tables.

When I changed the case in the dmraid rule from 'dmraid-*' to 'DMRAID-*' I can now mount my partitions via /etc/fstab using UUID as per usual. However, this causes a duplication of mappings for my disks with MBR. Is there a way to make this rule only fire for disks with GPT?

[Jesse Johnson (holocronweaver)]

After additional testing, I have determined that the UUID for MBR disks are duplicated across two mappings and that the regular mapping is dysfunctional. Thus for MBR disks I must point to /dev/mapper rather than use UUID. Again, this could be fixed if we could only fire the rule for GPT disks.

[Phillip Susi (psusi)]

Either kpartx should create the partitions or dmraid should, not both. You are right that dmraid does not understand GPT, so for that to work, kpartx should be run instead, but then dmraid needs to be asked not to create the partitions and let kpartx handle it for both types of partition table. There is a switch to tell dmraid not to create the partitions, so if the case of the DMRAID-* rule is fixed, that switch needs added to the dmraid-activate script.

[Serge Hallyn (serge-hallyn)]

@Phillip,

Do you mind attaching a bzr tree for dmraid doing what you suggest here, and updating the tree already linked? I'll create test packages so people can make sure everything works as expected.

[Jesse Johnson (holocronweaver)]

I am willing to test any changes that might help resolve this problem. Just point me to the code.

[John Center (john-center)]

Has there been any additional work done on this? This bug has affected me also, because of the point raised in comment #9 about using dmraid with GPT partitions. Will this be resolved for 11.10? Thanks. -John

[Jesse Johnson (holocronweaver)]

Yes, I am also wondering whether or not this will be resolved for 11.10. I can upload the patch, but I first need to know the "switch to tell dmraid not to create the partitions" that Phillip mentioned in comment #9. I could not find such a switch in the dmraid man file.

[John Center (john-center)]

While there is no explanation, the man page for dmraid has this:

dmraid {-a|--activate} {y|n|yes|no}
[-d|--debug]... [-v|--verbose]... [-i|--ignorelocking]
[-f|--format FORMAT[,FORMAT...]]
[{-P|--partchar} CHAR]
[-p|--no_partitions]
[--separator SEPARATOR]
[-t|--test]
[RAID-set...]

I think you would want to use -p or --no_partitions.

[Jesse Johnson (holocronweaver)]

Ok, so to fix this problem follow these steps (assuming you are using Ubuntu 11.04):

1. Modify this line in /lib/udev/rules.d/95-kpartx.rules

       ENV{DM_STATE}=="ACTIVE", ENV{DM_UUID}=="dmraid-*", \
        RUN+="/sbin/kpartx -p -part -a /dev/$kernel"

    by changing "dmraid-*" to "DMRAID-*" and remove the '-p -part' switch so that you get

       ENV{DM_STATE}=="ACTIVE", ENV{DM_UUID}=="DMRAID-*", \
        RUN+="/sbin/kpartx -a /dev/$kernel"

   As mentioned in the bug report, the switch to uppercase is required since id's for dmraid mapped devices follow that convention. The removal of the -p switch is meant to allow kpartx use its default partition map naming scheme rather than a distro specific one. Not sure if Debian ever changed this.

2. Modify this line in the script /sbin/dmraid-activate

       dmraid -i -ay -Z "$1"

    by inserting the -p switch as suggested John in comment #14 so you obtain

       dmraid -i -ay -p -Z "$1"

    Now dmraid will not map partitions, leaving that job to kpartx when it is called in its respective udev rule.

3. Done!

I am not sure how to convert my changes into an uploadable patch via Launchpad. Could someone please direct me to a tutorial or give a brief example?

It would be nice if kpartx was integrated into dmraid itself or else at least replace the partition mapping portion of dmraid with calls to kpartx and bundle the two together (as suggested in the dmraid TODO file). I assume such changes must be made upstream. If so, where should I go to make / suggest the changes?

[Serge Hallyn (serge-hallyn)]

Quoting Jesse Johnson (<email address hidden>):
> Ok, so to fix this problem follow these steps (assuming you are using
> Ubuntu 11.04):

Thanks very much Jess.

...
> I am not sure how to convert my changes into an uploadable patch via
> Launchpad. Could someone please direct me to a tutorial or give a brief
> example?

The easiest way is probably as a merge proposal. You can download the
bzr tree for the package,

bzr branch lp:ubuntu/natty-updates/multipath-tools

Or, for the current release (oneiric)

bzr branch lp:ubuntu/multipath-tools

Make your changes in the multipath-tools directory, commit them, push
them back to launchpad,

bzr push lp:~jessyjohnson/ubuntu/natty-updates/multipath-tools/fix-kpartx-rules

(Or whatever your lp username is in place of jessyjohnson)

and then do a merge proposal by opening up the web page

bzr lp-open

And choosing 'propose for merge' from that web page.

> It would be nice if kpartx was integrated into dmraid itself or else at
> least replace the partition mapping portion of dmraid with calls to
> kpartx and bundle the two together (as suggested in the dmraid TODO
> file). I assume such changes must be made upstream. If so, where should
> I go to make / suggest the changes?

The info for the multipath-tools upstream is at

http://christophe.varoqui.free.fr/

thanks,
-serge

[Phillip Susi (psusi)]

The '-part' is an argument to the '-p' switch, so it also needs removed from the kpartx command, and needs to follow the '-p' switch to dmraid, if that switch is added there, but I do not think it should be, for the same reason that it should be removed from kpartx.

The reason that dmraid handles the partitions itself instead of allowing kpartx to do it is because when it deactivates an array, it must remove the partitions first, therefore, it must parse the partition tables to figure out which partitions need removed. This needs resolved before the partition handling can be removed from dmraid and kpartx relied on to do it instead.

Unfortunately, the kernel currently lacks a mechanism to propagate a removal request or a surprise removal notice up the device stack, which dmraid would need to properly tear down the dmraid device. Without that, it can not properly handle device shutdown without its partition code ( and can't handle it properly even as it is now, if the partition is part of LVM ).

[John Center (john-center)]

What is the status of the proposed changes made by Jesse? I found that 11.10 did not include kpartx & the changes he proposed. Doing it by hand myself, it worked, but as soon as any change is made that would rebuild initrd.img, the kpartx files & the changes have to be redone. I'm trying to figure out how to modify the initranfs-tools configuration to do this automatically, but I'm a novice at this. Having kpartx handle the partitions instead of dmraid as Philip suggests seems to be the way to go. (I think Fedora includes kpartx in the initramfs, also.)

[Phillip Susi (psusi)]

The broken rules have been removed upstream and should be merged down into debian and ubuntu before long. dmraid will continue to handle the partitions itself because if it doesn't, it is unable to deactivate the array.

[John Center (john-center)]

But, dmraid can't activate the partitions on GPT disks, so how will this work? Also, could you send me a link to the changes?

Thanks.

    -John

[Phillip Susi (psusi)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It won't work, and no, I don't have a link.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7kIAEACgkQJ4UciIs+XuLfIwCeL7u3zq0IJJ4M97Z2k6opbBid
/1MAoIGYUQzTY49VG7/ctcMhjyMxtY4Q
=27ww
-----END PGP SIGNATURE-----

[John Center (john-center)]

Ok, I'll look & see if there is a ticket for the GPT disk problem, or I'll open a new ticket tomorrow. Thanks Philip.

[Jesse Johnson (holocronweaver)]

What is the status on this bug?

I recently clean installed Ubuntu 12.04 and had no problems mounting the disks, so the steps in Post #15 are no longer necessary, at least for Intel Matrix Raid. Looking at the kpartx udev rule in 12.04, the file appears unchanged, but the kpartx-activate script contains the fix I suggested.

[Phillip Susi (psusi)]

The broken/nonfunctional udev rule has not yet been removed in kpartx, but 12.04 uses kpartx to activate dmraid partitions and so supports GPT.

[Jesse Johnson (holocronweaver)]

How about this year? ;-) Has the broken udev rule been removed from kpartx yet? It would be nice to have this resolved for Ubuntu 13.04.