----- Original Message -----
From: "David Lehman" <dlehman(a)redhat.com>
To: anaconda-patches(a)lists.fedorahosted.org
Sent: Friday, August 1, 2014 6:46:19 PM
Subject: Re: [PATCH 3/3] Don't pass md array UUID as member format UUID.
On 08/01/2014 03:35 AM, Anne Mulhern wrote:
>
>
>
>
> ----- Original Message -----
>> From: "David Lehman" <dlehman(a)redhat.com>
>> To: anaconda-patches(a)lists.fedorahosted.org
>> Sent: Friday, August 1, 2014 12:16:04 AM
>> Subject: [PATCH 3/3] Don't pass md array UUID as member format UUID.
>>
>> Related: rhbz#1070095
>> ---
>> blivet/devicetree.py | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/blivet/devicetree.py b/blivet/devicetree.py
>> index 73558df..03da94f 100644
>> --- a/blivet/devicetree.py
>> +++ b/blivet/devicetree.py
>> @@ -1806,7 +1806,7 @@ class DeviceTree(object):
>>
>> # attempt to reset the uuid using mdexamine info
>> # will succeed only if metadata version > 0.90
>> - kwargs["uuid"] = udev.device_get_md_device_uuid(info) or
>> kwargs["uuid"]
>> + kwargs["uuid"] = udev.device_get_md_device_uuid(info)
>>
>> kwargs["biosraid"] =
udev.device_is_biosraid_member(info)
>> elif format_type == "LVM2_member":
>> --
>> 1.9.3
>>
>> _______________________________________________
>> anaconda-patches mailing list
>> anaconda-patches(a)lists.fedorahosted.org
>>
https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
>>
>
> If it's really true that the value obtained from device_get_uuid()
> is certain to be completely irrelevant here, so that we can
> override it unconditionally, then device_get_uuid() can probably
> be simplified to a 1-liner and maybe a comment added about the
> nature of ID_FS_UUID (it's not clear to me what might be expected
> to set it.)
If MD_UUID was ever in the udev info for md members, it isn't anymore.
It probably came from anaconda's udev rules.
I believe that I actually saw it pop up as a result of running the previous
pyudev code in the debugger. I can't for the life of me see any way that
mdadm could be setting it, but I do think I saw it.
> ID_FS_UUID is the UUID of the filesystem/data on the current
device. It
only becomes complicated with md and btrfs because, instead of using
ID_FS_UUID for the device-specific (and therefore unique, like a UUID
should be) value, they use it for the container/array/volume and
introduce ID_FS_UUID_SUB for the member-specific UUIDs. LVM (correctly)
has the PV UUID as ID_FS_UUID of the members and then you have to look
elsewhere for VG and/or LV UUIDs.
Anyway, I was able to reduce device_get_uuid to a single line and since
I just found out that ID_FS_UUID_SUB contains the md member-specific
UUID I changed device_get_md_device_uuid like this:
@@ -395,7 +387,9 @@ def device_get_md_device_uuid(info):
# Value for MD_UUID known to be obtained from:
# * pyudev/libudev
# * mdraid/mdadm (only 1.x metadata versions)
- return info.get('MD_DEV_UUID')
+ # Value for ID_FS_UUID_SUB known to be obtained from:
+ # * pyudev/libudev
+ return info.get('ID_FS_UUID_SUB') or info.get('MD_DEV_UUID')
I just realized that now that the infos are distinct that it works,
but wierdly. If you pass udev info you may get value for ID_FS_UUID_SUB,
but if md info then you may get value for MD_DEV_UUID. So, it might make
sense to pass both infos.
I'm not sure how to handle this exactly, but it does make an argument
for the notion of having a SuperCache of the kind I described in my
previous email.
>
> Also, the comment should be changed to something like:
>
> reset the device UUID using mdexamine info
> UUID is None if metadata version <= 0.90
>
> or something like that.
Done.
>
> - mulhern
>
>
> _______________________________________________
> anaconda-patches mailing list
> anaconda-patches(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
>
_______________________________________________
anaconda-patches mailing list
anaconda-patches(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches