On Mon, Nov 21 2016, Andy Smith wrote:
> Hi Neil,
>
> On Mon, Nov 21, 2016 at 03:32:42PM +1100, NeilBrown wrote:
>> If you still want to get to the bottom of this, you might need to revert
>> your work-around, the try the "udevadm monitor" and "udevadm info" and "udevadm
>> trigger" while the array is not assembled.
>
> I have reverted my addition of "mpt3sas" from
> /etc/initramfs-tools/modules and rebooted, so that md5 is again not
> assembled.
Thanks. Sorry this is taking a lot of back-and-forth...
Still getting
> E: ID_FS_TYPE=linux_raid_member
which is good. Not getting and MD_*, which is bad.
I would:
- check that md5 definitely isn't running (mdadm -S /dev/md5)
- run mdadm -I just like udev does.
/sbin/mdadm --incremental --export /dev/sdc --offroot /dev/disk/by-id/ata-SAMSUNG_MZ7KM1T9HAJM-00005_S2HNNAAH200633 /dev/disk/by-id/wwn-0x5002538c0007e7a8 /dev/disk/by-path/pci-0000:01:00.0-sas-0x4433221100000000-lun-0
(the string of paths is from the "DEVLINKS" field).
That *should* produce several lines like "MD_NAME=tbd:5" etc.
My guess is that it is producing an error. Knowing that error message
would help.
If it doesn't produce an error, but does produce some MD_* lines, then
the problem must be that udev isn't doing quite the same thing.
So stop md5 again (mdadm -S /dev/md5), enable udev debugging
udevadm control -l debug
and re-issue the 'change'
echo change > /sys/block/sdc/uevent
That should puts lots of stuff in the journal. If you could extract
that and post it I might be able to find something of interest.
Thanks,
NeilBrown
Attachment:
signature.asc
Description: PGP signature
