Partitionable raid ignored by 65-mdadm-blkid.rules

Thank you for reporting this bug.
I opted the version that upstream uses, i.e.:

-KERNEL!="md[0-9]*", GOTO="mdadm_end"
+KERNEL!="md*", GOTO="mdadm_end"

Which works just as well. This will be uploaded to the archive soon.

This bug was fixed in the package mdadm - 3.2.3-2ubuntu2

---------------
mdadm (3.2.3-2ubuntu2) quantal; urgency=low

  * Minimizing the merge-diff from Debian:
    + debian/rules, debian/mdadm.udev, debian/mdadm.mdadm-blkid.udev:
      Drop our own udev rules in favour of upstream's. Debian did so in
      3.0~devel3-43-g2800528-1. Upstream's rules have everything we had.
      (LP: #1002357, LP: #968074)
    + debian/initramfs/hooks: Update to copy only the new/correct udev rules
      file.
    + debian/rules: Remove pointless diff against debian. And now mdmon
    installs itself (LP: #957494).

  * debian/patches/series: Remove `disable-udev-incr-assembly.diff' to
    enable incremental assembly, now that we are using upstream rules & we
    always had incremental assembly enabled.

  * Fixing lintian tags, that are introduced in Ubuntu:
    + debian/source_mdadm.py: fix executable-not-elf-or-script
    + debian/changelog: correct trailer formating of acient changelog entry
 -- Dmitrijs Ledkovs <email address hidden> Mon, 21 May 2012 20:48:10 +0100

Dmitrijs: What's the status of the SRU? are we still on target for the point release?

Dmitrijs, is there any (theoretical) risk of false positives here, with the partitionable raid rules becoming active and as a result *mis*assembling something which isn't meant to be a partitionable raid?

Hello Tuomas, or anyone else affected,

Accepted mdadm into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/mdadm/3.2.5-1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

@ Steve Langasek,

The incremental assembly is only triggered on [format]_raid_members.

SUBSYSTEM!="block", GOTO="md_end"
KERNEL!="md*", GOTO="md_end"

So something needs to be a block device and match a name md*. The current $ man 4 md , reserves:
       /dev/mdn
       /dev/md/n
       /dev/md/name
Or I would hope linux developers assume that /dev/md* is reserved for mdadm. So theoretically there is a possibility to *mis*assembly since there is no centralised linux kernel device namespace (that I know of). In practice such non-mdadm md* block devices are not known to exist yet.

Hello Tuomas, or anyone else affected,

Accepted mdadm into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/mdadm/3.2.5-1ubuntu0.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Everything below was done on precise:

I do agree that the standard partitionable mdadm raid devices (/dev/md_dNNpXX) were not supported in precise, but now are supported with the version from -proposed.

But please note that even though I created /dev/md_d1, /dev/md_d1p1 and /dev/md_d1p2 the device names have changed after the reboot to /dev/md127, /dev/md127p1, /dev/md127p2 which is interesting. As long as you use UUID to mount filesystems everything should be fine, or create the md device with stable names e.g. /dev/md/myraid with partitions /dev/mdmyraid1 /dev/mdmyraid2, as those names will stay stable.

Scrap last comment, with update package from -proposed the device names are correctly preserved across reboots as /dev/md_d1, /dev/md_d1p1 and /dev/md_d1p2. So everything is fine with respect to partitionable raids now.

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

This bug was fixed in the package mdadm - 3.2.5-1ubuntu0.2

---------------
mdadm (3.2.5-1ubuntu0.2) precise-proposed; urgency=low

  * Patch udev-md-raid.rules to not auto-start arrays based on detection
    of ddf or isw (imsm) signatures; this conflicts with dmraid usage in
    precise and requires more analysis before it can be enabled in SRU.
    LP: #1030292.

mdadm (3.2.5-1ubuntu0.1) precise-proposed; urgency=low

  * Stable Micro Point Bug Fix release:
    - SRU master bug (LP: #1009973)
    - Fixes segfault upon update-initramfs (LP: #969384)
    - Fixes does not allow internal bitmap on version 1.2 arrays (LP: #1022915)
  * Preserved previous behaviour, by reverting:
    - bitmap chunk size of 0 will continue to mean 512B
    - Modify the below fix, to accept previous syntax
      "b10c663 config: fix handing of 'homehost' in AUTO line."
  * Use upstream version of udev rules, instead of three slightly
    different ubuntu udev rules (LP: #968074) (LP: #1002357)
  * Add missing mdmon utility. This enables external metadata RAID
    formats: DDF and Intel Matrix Storage Management (IMSM). (LP: #957494)
  * Copy udev rule from /etc/udev/rules.d/ as well as the
    /lib/udev/rules.d/, to allow local administrator to override mdadm
    rules file (LP: #1017407)
  * debian/initramfs/local-premount: add call wait_for_udev to wait a
    little longer for RAID devices to appear. This improves
    boot reliability. (LP: #942106)

mdadm (3.2.5-1) unstable; urgency=low

  [ Michael Tokarev ]
  * new upstream (bugfix) release, fixing regression when --add'ing
    device to an array, introduced in 3.2.4, plus other minor fixes
    (Closes: #673104, #673344)
  * new patch: sha1-includes.diff to fix #include mess in new sha1.h
  * added a check into debian/checkarray to skip checking arrays created
    less than 2 weeks ago (Closes: #624273)

  [ Dmitrijs Ledkovs ]
  * Remove obsolete documentation dating back to ~etch release
  * Remove reference to obsolete documention from debconf templates
  * Update debconf templates translations
  * Remove compatability with acient initramfs-tools
  * Remove debian-specific mdadm-startall.8 in clean target

mdadm (3.2.4-1) unstable; urgency=low

  * new upstream (bugfix) release (Closes: #664088, #661552)
  * removed debian-run-udev.diff (applied upstream), and
    all RUNDIR handling from debian/rules (it is the default now)
  * add build-arch and build-indep targets to debian/rules, and
    bump Standards-Version to 3.9.3

mdadm (3.2.3-3) unstable; urgency=low

  * switch from topgit to plain 3.0 (quilt) layout, creating
    debian/patches. Don't build-depend on quilt as patching
    is done automatically by dpkg-source.
  * debian/patches/debian-run-udev.diff by Roger Leigh (Closes: #644319, #627774)
  * update debian/mdadm.logcheck.ignore.server to recognize "k" in
    addition of "blocks" in kernel messages. Thanks to Frédéric Brière
    for the patch (Closes: #656038)
 -- Steve Langasek <email address hidden> Fri, 03 Aug 2012 23:08:39 -0700