Re: [PATCH 1/1] add --partuuid to probe

[Andrei Borzenkov <arvidjaar@gmail.com>]

27.02.2017 21:20, Vladimir 'phcoder' Serbinenko пишет:
> On Mon, Feb 27, 2017, 09:55 Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> 
>> 27.02.2017 03:37, Vladimir 'phcoder' Serbinenko пишет:
>> ...
>>>>>>> This is not NT-style. NT uses partition offset. Who uses this format?
>>>> Are
>>>>>>
>>>>>> This is used by util-linux and Linux kernel.
>>>>>>
>>>>>>
>>>>>>  *      6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing
>>>> the
>>>>>>  *         unique id of a partition if the partition table provides
>> it.
>>>>>>  *         The UUID may be either an EFI/GPT UUID, or refer to an
>> MSDOS
>>>>>>  *         partition using the format SSSSSSSS-PP, where SSSSSSSS is a
>>>>>> zero-
>>>>>>  *         filled hex representation of the 32-bit "NT disk
>> signature",
>>>>>> and PP
>>>>>>  *         is a zero-filled hex representation of the 1-based
>> partition
>>>>>> number.
>>>>>>
>>>>>>> you sure that partition numbers are synced with user? Even in
>> presence
>>>> of
>>>>>>> Solaris and bsd partitions.
>>>>>>>
>>>>>>
>>>>>> It is not clear what we should return for nested partition. I'm not
>> sure
>>>>>> whether linux kernel scans nested partitions at all in which case we
>>>>>> probably should follow the suite and assign PARTUUID to top-level
>>>>>> partitions only.
>>>>>>
>>>>> Linux scans nested partitions and it uses though numeration in
>> dev/sdaX,
>>>> in
>>>>> some cases shifting numbering of normal partitions. In those cases grub
>>>> and
>>>>> Linux numeration get out of sync
>>>>>
>>>>
>>>> Can you provide example?
>>>
>>> Bsd and Solaris partitions. I remember we had problem with numbering of
>>> those.
>>>
>>
>> Linux ignores nested BSD partitions (just tested). There are no special
>> files created. Of course someone needs to test what happens under
>> *BSD/Solaris in this case.
>>
> Kpartx or normal sdX? Is bsd-partition support enabled in kernel build?
> 

OK I see, kernel skips BSD partition marked as "unused".

So it appears that kernel always puts special nested partitions after
normal logical MSDOS partitions, so it will not skew MSDOS partition
numbers.

[    1.529752]  vda: vda1 vda2 vda3 < vda5 vda6 >
                vda2: <openbsd: vda7 >


        /*
         * Look for partitions in two passes:
         * First find the primary and DOS-type extended partitions.
         * On the second pass look inside *BSD, Unixware and Solaris
partitions.
         */

For such partition (vda7) PARTUUID is empty.

P.S. I wonder whether we correctly map such partition ... no, we do not.

10:~ # cat /tmp/foo
(hd0) /dev/vda
10:~ # grub2-probe -m /tmp/foo -t compatibility_hint -d /dev/vda2
hd0,msdos2
10:~ # grub2-probe -m /tmp/foo -t compatibility_hint -d /dev/vda5
hd0,msdos5
10:~ # grub2-probe -m /tmp/foo -t compatibility_hint -d /dev/vda7
hd0,msdos2


>>
>> I never liked idea of artificial partition GUIDs for MBR, but as long as
>> only Linux is using them and we are consistent with its usage - so be it.
>>
>>>> I tried to create nested partition table, but
>>>> Linux will not display it (actually attempt to "blockdev --rereadpt
>>>> /dev/vda5" fails with "Invalid argument").
>>>>
>>>>         if (!disk_part_scan_enabled(disk) || bdev != bdev->bd_contains)
>>>>                 return -EINVAL;
>>>>
>>>> Where bdev->bd_contains points to containing device for partition and to
>>>> itself for the whole disk.
>>>>
>>>> As util-linux does not scan partition table itself, it does show these
>>>> nested partitions either.