On Sun, Apr 03, 2011 at 05:39:57PM +0200, Seblu wrote:
On Sun, Apr 3, 2011 at 5:04 PM, Dave Reisner <d@falconindy.com> wrote:
On Sun, Apr 03, 2011 at 04:55:14PM +0200, Sebastien Luttringer wrote:
This job is done by recent version of udev in /lib/udev/rules.d/64-md-raid.rules.
this comes from mdadm, not udev. Yes but upstream rules does not match with my current content. I'm searching why.
It's also only triggered if the partitions are of type linux_raid_member or isw_raid_member. partition not strictly. My raid is directly on disk (so without partition type from mbr) and detection is correct. Even after removing /etc/blkid* udev rules detect by /sbin/blkid -o udev -p $dev. As far i test, blkid is based on metadata.
blkid reads the same metadata that udev does. I misread the rule -- ID_FS_TYPE is a layer above the partition table itself. Thinking back, I recall hearing about this on systemd-devel...
If this were to go through, we'd have a lot of people banging on our doors, so to speak.. I don't see why. Udev, via blikid will detect and assemble.
About isw_raid, line is not in mdadm package upstream 3.1.2 and 3.1.5.
It's in testing (3.2.1): ENV{ID_FS_TYPE}=="isw_raid_member", ACTION=="remove", RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}" ENV{ID_FS_TYPE}=="isw_raid_member", ACTION=="add", RUN+="/sbin/mdadm --incremental $env{DEVNAME}"
Currently all people should come to us because they have an error when mdadm is automatically started at boot. cf bugreport closed by adding USE_MDADM. it does not seem to be the revolution :)
Indeed, that error's been there as long as I've been using Arch. dave