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

["Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4160 bytes --]

On Mon, Feb 27, 2017, 20:11 Andrei Borzenkov <arvidjaar@gmail.com> wrote:

> 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
>
WAI. In case when subpartition starts at the same sector as partition
itself.

>
>
> >>
> >> 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.
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 8077 bytes --]