On Jul 22, 2014, at 11:39 AM, Phil Turmel <philip@xxxxxxxxxx> wrote:
> Hi Chris,
>
> On 07/22/2014 12:57 PM, Chris Murphy wrote:
>>
>> On Jul 22, 2014, at 9:57 AM, Ron Leach <ronleach@xxxxxxxxx> wrote:
>>>
>>> D5s2:/# ./lsdrv
>> [snip]
>>> │ ├sda7 37.25g [8:7] MD raid1 (2) inactive {5bad4c7c:780696f4:e201a2f5:7bba85d7}
>> [snip]
>>> ├sdb7 37.25g [8:23] MD raid1 (2) inactive {5bad4c7c:780696f4:e201a2f5:7bba85d7}
>>
>>
>> They are in the lsdrv listing, but the raid is not activated. The problem is a RAID UUID mismatch between mdadm.conf and libblkid (I'm assuming the tree lsdrv is generating ultimately comes from libblkid, I could be wrong.)
>
> lsdrv calls out to udev's "vol_id" utility if present, otherwise calls
> out to "blkid" in "probe" mode. So yes, libblkid.
>
>> 5bad4c7c:780696f4:fbaacbb9:204d67b9 ## mdadm.conf
>> 5bad4c7c:780696f4:e201a2f5:7bba85d7 ## libblkid
>>
>> Therefore it's not being assembled.
>
> Good catch. UUIDs make my eyes cross.
>
> In this case, since the initramfs is auto-assembling everything, its
> getting a high minor number instead of the desired minor number.
>
> Ron, while md126 is assembled, you should get a report from blkid for
> that filesystem. Then your fstab can pick it up by UUID instead of
> device name.
Right. Once the raid is active, libblkid will become aware of the filesystem/volume UUID, and it's that UUID to put in fstab. So two different UUIDs: raid goes in mdadm.conf, and volume goes in fstab.
Chris Murphy--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
