Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[Steve Kenton]

As far as I can tell there is no search module that can be used to get 
the partuuid at boot time given a grub root device such as (hd0,gtp1). I 
think is would be a useful addition since the resulting partuuid could 
be passed directly to the kernel as root=PARTUUID=xxx and it does not 
seem like it should be hard to do. Am I missing something obvious? And, 
before I jump end the deep end of the pool and try to write it, is 
anyone else working on something similar?

Not subscribed, please cc me on reply.

Steve Kenton

Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[adrian15]

What's your use case?

adrian15

El 12/08/16 a las 16:11, Steve Kenton escribió:
> As far as I can tell there is no search module that can be used to get
> the partuuid at boot time given a grub root device such as (hd0,gtp1). I
> think is would be a useful addition since the resulting partuuid could
> be passed directly to the kernel as root=PARTUUID=xxx and it does not
> seem like it should be hard to do. Am I missing something obvious? And,
> before I jump end the deep end of the pool and try to write it, is
> anyone else working on something similar?
>
> Not subscribed, please cc me on reply.
>
> Steve Kenton
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[Andrei Borzenkov]

13.08.2016 20:30, adrian15 пишет:
> What's your use case?
> 

Well, this has been requested before and this is supported by Linux
kernel. So as long as this does not increase core modules size (i.e. is
done outside of partition probing core) I think it will be OK.

> adrian15
> 
> El 12/08/16 a las 16:11, Steve Kenton escribió:
>> As far as I can tell there is no search module that can be used to get
>> the partuuid at boot time given a grub root device such as (hd0,gtp1). I
>> think is would be a useful addition since the resulting partuuid could
>> be passed directly to the kernel as root=PARTUUID=xxx and it does not
>> seem like it should be hard to do. Am I missing something obvious? And,
>> before I jump end the deep end of the pool and try to write it, is
>> anyone else working on something similar?
>>

There was recent patch series that adds support for user-space
grub-probe. Would be good if implementation can be shared. I do not want
to add any special code to handle partitions UUID to core as this is
very special case of really one partition type only, used infrequently
and can be entirely handled by usual device iteration.

>> Not subscribed, please cc me on reply.
>>

Not sure why, but whatever reply I chose Thunderbird and Gmail only
reply to list.

Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[Steve Kenton]

My thought is to add a new command "partuuid" which takes a 
drive&partition string and sets an environment variable to the partition 
uuid (grub "partuuid" by default). Since grub always calls the load 
drive "hd0" this can then be passed directly to the kernel as a command 
line for the rootfs in many cases. Or search could be used to find the 
drive and partuuid could be used to make it palatable to the kernel. For 
example:

menuentry "Buildroot" {
     set root=(hd0,gpt1)
     partuuid $root partuuid
     linux /boot/bzImage root=PARTUUID=$partuuid rootfstype=ext4 
console=tty1 quiet splash=silent
}

Below is my first pass at a solution. It's really pseudo code since I 
have not even tried to compile it yet. I was just getting familiar with 
the grub environment since I've never tinkered with it before. Lot's of 
cut and paste but I think it's pretty close.

Steve Kenton


/*
GUIDs are usually stored as 128-bit BE values, and are commonly 
displayed as 32 hexadecimal digits
most commonly written in text as a sequence of hexadecimal digits 
separated into five groups, such as:

     3F2504E0-4F89-41D3-9A0C-0305E82C3301

This text notation contains the following fields, separated by hyphens:
Hex digits     Description
8     Data1
4     Data2
4     Data3
4     Initial two bytes from Data4
12     Remaining six bytes from Data4

For the first three fields, the most significant digit is on the left. 
The last two fields are treated as eight separate bytes, each having 
their most significant digit on the left, and they follow each other 
from left to right. Note that the digit order of the fourth field may be 
unexpected, since it is treated differently from the other fields in the 
structure. This is sometimes known as "registry format".
*/

int main(int argc, char **argv) // example usage: partuuid "hd0,gpt1" 
partuuid
{

     char *name, *partnum, *var;
     int number; // the partition # of interest
     grub_disk_t disk;
     grub_err_t err;

     auto int NESTED_FUNC_ATTR find_partuuid(grub_disk_t disk, const 
grub_partition_t p);
     int NESTED_FUNC_ATTR find_partuuid(grub_disk_t disk, const 
grub_partition_t p)
     {
         struct grub_gpt_partentry entry;
         int ret = true; // keep looking

         if (grub_disk_read(disk, p->offset, p->index, sizeof(entry), 
&entry))
             ret = false; // EOF
         else if (p->number == number) // number and var are in scope 
from the outer function
         {
             char partuuid[37]; // 32 hex digits, 4 dashes and a NUL

             partuuid = grub_xasprintf 
("%08X-%04X-%04X-%02X%02X-%02X%02X%02X%02X%02X%02X", // need to double 
check caps and endian-ness issues
             grub_be_to_cpu32 (*(grub_uint32_t *) &entry.guid[0]),
             grub_be_to_cpu16 (*(grub_uint16_t *) &entry.guid[4]),
             grub_be_to_cpu16 (*(grub_uint16_t *) &entry.guid[6]),
             entry.guid[7], entry.guid[8], // endian-ness does not 
matter for single bytes
             entry.guid[9], entry.guid[10], entry.guid[10], 
entry.guid[10], entry.guid[10], entry.guid[10], entry.guid[10]);
             err = grub_set_env(var, partuuid); // need to error check
             ret = false; // found it, all done
         }

         return ret;
     }

     // Split disk and partition from the name string and get 
environment variable name - need to error check
     name = argv[1];
     partnum = grub_strchr(name, ',') + 1;
     var = argv[2]; // should default to "partuuid" if not supplied
     while (*partnum && grub_isalpha(*partnum))
         partnum++;
     number = grub_strtoul(partnum, (char **) &partnum, 0) - 1; // need 
to look at this function
     if (disk = grub_disk_open(name)) // ignores partition if present in 
name string, NULL on failure
         err = grub_gpt_partition_map_iterate(disk, find_partuuid);

     return 0;
}


On 08/13/2016 06:40 PM, Andrei Borzenkov wrote:
> 13.08.2016 20:30, adrian15 пишет:
>> What's your use case?
>>
> Well, this has been requested before and this is supported by Linux
> kernel. So as long as this does not increase core modules size (i.e. is
> done outside of partition probing core) I think it will be OK.
>
>> adrian15
>>
>> El 12/08/16 a las 16:11, Steve Kenton escribió:
>>> As far as I can tell there is no search module that can be used to get
>>> the partuuid at boot time given a grub root device such as (hd0,gtp1). I
>>> think is would be a useful addition since the resulting partuuid could
>>> be passed directly to the kernel as root=PARTUUID=xxx and it does not
>>> seem like it should be hard to do. Am I missing something obvious? And,
>>> before I jump end the deep end of the pool and try to write it, is
>>> anyone else working on something similar?
>>>
> There was recent patch series that adds support for user-space
> grub-probe. Would be good if implementation can be shared. I do not want
> to add any special code to handle partitions UUID to core as this is
> very special case of really one partition type only, used infrequently
> and can be entirely handled by usual device iteration.
>
>>> Not subscribed, please cc me on reply.
>>>
> Not sure why, but whatever reply I chose Thunderbird and Gmail only
> reply to list.
>

Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[Andrei Borzenkov]

13.08.2016 23:25, Steve Kenton пишет:
> My thought is to add a new command "partuuid" which takes a

We have "probe" command and if implemented it should be integrated there.

> drive&partition string and sets an environment variable to the partition
> uuid (grub "partuuid" by default). Since grub always calls the load
> drive "hd0" 

That's wrong in general.

> this can then be passed directly to the kernel as a command
> line for the rootfs in many cases. Or search could be used to find the
> drive and partuuid could be used to make it palatable to the kernel. For
> example:
> 
> menuentry "Buildroot" {
>     set root=(hd0,gpt1)
>     partuuid $root partuuid
>     linux /boot/bzImage root=PARTUUID=$partuuid rootfstype=ext4
> console=tty1 quiet splash=silent
> }
> 
> Below is my first pass at a solution. It's really pseudo code since I
> have not even tried to compile it yet. I was just getting familiar with
> the grub environment since I've never tinkered with it before. Lot's of
> cut and paste but I think it's pretty close.
> 
> Steve Kenton
> 
> 
> /*
> GUIDs are usually stored as 128-bit BE values, and are commonly
> displayed as 32 hexadecimal digits
> most commonly written in text as a sequence of hexadecimal digits
> separated into five groups, such as:
> 
>     3F2504E0-4F89-41D3-9A0C-0305E82C3301
> 

Usually GUIDs are displayed in lower case

> This text notation contains the following fields, separated by hyphens:
> Hex digits     Description
> 8     Data1
> 4     Data2
> 4     Data3
> 4     Initial two bytes from Data4
> 12     Remaining six bytes from Data4
> 
> For the first three fields, the most significant digit is on the left.
> The last two fields are treated as eight separate bytes, each having
> their most significant digit on the left, and they follow each other
> from left to right. Note that the digit order of the fourth field may be
> unexpected, since it is treated differently from the other fields in the
> structure. This is sometimes known as "registry format".

Not sure what it has to do with registry. For GPT GUID are pretty well
defined by UEFI spec which in turn is based on RFC 4122.

> */
> 
> int main(int argc, char **argv) // example usage: partuuid "hd0,gpt1"
> partuuid
> {
> 
>     char *name, *partnum, *var;
>     int number; // the partition # of interest

Please avoid C++ comments.

>     grub_disk_t disk;
>     grub_err_t err;
> 
>     auto int NESTED_FUNC_ATTR find_partuuid(grub_disk_t disk, const
> grub_partition_t p);
>     int NESTED_FUNC_ATTR find_partuuid(grub_disk_t disk, const
> grub_partition_t p)

We got rid of nested functions years ago.

>     {
>         struct grub_gpt_partentry entry;
>         int ret = true; // keep looking
> 
>         if (grub_disk_read(disk, p->offset, p->index, sizeof(entry),
> &entry))
>             ret = false; // EOF
>         else if (p->number == number) // number and var are in scope
> from the outer function
>         {
>             char partuuid[37]; // 32 hex digits, 4 dashes and a NUL
> 
>             partuuid = grub_xasprintf
> ("%08X-%04X-%04X-%02X%02X-%02X%02X%02X%02X%02X%02X", // need to double

grub internal implementation does not include upper case version.

> check caps and endian-ness issues
>             grub_be_to_cpu32 (*(grub_uint32_t *) &entry.guid[0]),
>             grub_be_to_cpu16 (*(grub_uint16_t *) &entry.guid[4]),
>             grub_be_to_cpu16 (*(grub_uint16_t *) &entry.guid[6]),
>             entry.guid[7], entry.guid[8], // endian-ness does not matter
> for single bytes
>             entry.guid[9], entry.guid[10], entry.guid[10],
> entry.guid[10], entry.guid[10], entry.guid[10], entry.guid[10]);
>             err = grub_set_env(var, partuuid); // need to error check
>             ret = false; // found it, all done
>         }
> 
>         return ret;
>     }
> 
>     // Split disk and partition from the name string and get environment
> variable name - need to error check
>     name = argv[1];
>     partnum = grub_strchr(name, ',') + 1;
>     var = argv[2]; // should default to "partuuid" if not supplied
>     while (*partnum && grub_isalpha(*partnum))
>         partnum++;

You can simply read partition info directly from disk, no need to
iterate at all. grub_disk_open returns all needed information about
partition location.

>     number = grub_strtoul(partnum, (char **) &partnum, 0) - 1; // need
> to look at this function
>     if (disk = grub_disk_open(name)) // ignores partition if present in

You should return error if open fails, not silently ignore it. Not to
mention, that it won't even compile because of warning that is treated
as error.

> name string, NULL on failure
>         err = grub_gpt_partition_map_iterate(disk, find_partuuid);
> 

Linux supports synthetic "GUID" on MSDOS labels too. This should support
it as well (even though I am not sure how useful they are).

>     return 0;
> }
> 
> 
> On 08/13/2016 06:40 PM, Andrei Borzenkov wrote:
>> 13.08.2016 20:30, adrian15 пишет:
>>> What's your use case?
>>>
>> Well, this has been requested before and this is supported by Linux
>> kernel. So as long as this does not increase core modules size (i.e. is
>> done outside of partition probing core) I think it will be OK.
>>
>>> adrian15
>>>
>>> El 12/08/16 a las 16:11, Steve Kenton escribió:
>>>> As far as I can tell there is no search module that can be used to get
>>>> the partuuid at boot time given a grub root device such as
>>>> (hd0,gtp1). I
>>>> think is would be a useful addition since the resulting partuuid could
>>>> be passed directly to the kernel as root=PARTUUID=xxx and it does not
>>>> seem like it should be hard to do. Am I missing something obvious? And,
>>>> before I jump end the deep end of the pool and try to write it, is
>>>> anyone else working on something similar?
>>>>
>> There was recent patch series that adds support for user-space
>> grub-probe. Would be good if implementation can be shared. I do not want
>> to add any special code to handle partitions UUID to core as this is
>> very special case of really one partition type only, used infrequently
>> and can be entirely handled by usual device iteration.
>>
>>>> Not subscribed, please cc me on reply.
>>>>
>> Not sure why, but whatever reply I chose Thunderbird and Gmail only
>> reply to list.
>>
> 

Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[Thomas Schmitt]

Hi,

after having freshly re-read the specs of UEFI and RFC4122,
here is some nitpicking:

Steve Kenton wrote:
> >     3F2504E0-4F89-41D3-9A0C-0305E82C3301

Andrei Borzenkov wrote:
> Usually GUIDs are displayed in lower case

RFC4122 prescribes to read them independently of case, but to produce
them with lowercase letters.


> GPT GUID are pretty well defined by UEFI spec which in turn is
> based on RFC 4122.

UEFI 2.4 Appendix A claims to be in sync with RFC 4122. But that's
obviously not true.

They seem to have evolved in parallel. UEFI only documents the GUID variant
with MAC address and finely granulated timestamp, which imposes a privacy
problem. Other sources blame Microsoft for it.
RFC 4122 describes that variant with different endianness, a pseudo-random
variant (which about everybody is using), and a variant with crypto-grade
hash of user input. The abstract of RFC 4122 names Distributed Computing
Environment by Open Software Foundation as ancestor of its definition.

While trying to grok the conversion from text format to binary format
i could not reliably determine where to put the version nibble. RFC 4122
prescribes big-endian representation of 16 bit "time_hi_and_version",
whereas UEFI prescribes little-endian "TimeHighAndVersion".

uuidgen(1) obviously follows RFC 4122.
xorriso currently generates them UEFI style but in next release will
cowardly waste 4 bits of entropy by writing the nibble into both bytes.

It seems that nobody interprets the entrails of GUIDs but rather everybody
uses them as opaque byte strings.
Nevertheless one has to expect byte swapping to happen when converting
forth and back between text representation and binary representation
by using different conversion software.


Have a nice day :)

Thomas

Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[Andrei Borzenkov]

14.08.2016 12:09, Thomas Schmitt пишет:
> Hi,
> 
> after having freshly re-read the specs of UEFI and RFC4122,
> here is some nitpicking:
> 
> Steve Kenton wrote:
>>>     3F2504E0-4F89-41D3-9A0C-0305E82C3301
> 
> Andrei Borzenkov wrote:
>> Usually GUIDs are displayed in lower case
> 
> RFC4122 prescribes to read them independently of case, but to produce
> them with lowercase letters.
> 
> 
>> GPT GUID are pretty well defined by UEFI spec which in turn is
>> based on RFC 4122.
> 
> UEFI 2.4 Appendix A claims to be in sync with RFC 4122. But that's
> obviously not true.
> 
> They seem to have evolved in parallel. UEFI only documents the GUID variant
> with MAC address and finely granulated timestamp, which imposes a privacy
> problem. Other sources blame Microsoft for it.
> RFC 4122 describes that variant with different endianness, a pseudo-random
> variant (which about everybody is using), and a variant with crypto-grade
> hash of user input. The abstract of RFC 4122 names Distributed Computing
> Environment by Open Software Foundation as ancestor of its definition.
> 


Randomly checking well known EFI GUID gives Variant 10 (RFC 4122) and
Version 1 (time based) or 4 (randomly generated). Appendix A does not
really tell anything about how GUIDs are actually generated. Version 1
also allows random generated content of Node field instead of MAC. So in
general it looks compliant with RFC with single deviation being byte order.

> While trying to grok the conversion from text format to binary format
> i could not reliably determine where to put the version nibble. RFC 4122
> prescribes big-endian representation of 16 bit "time_hi_and_version",
> whereas UEFI prescribes little-endian "TimeHighAndVersion".
> 

According to UEFI Appendix A it goes into 7-th byte (starting with 0) of
binary representation of EFI GUID.

> uuidgen(1) obviously follows RFC 4122.
> xorriso currently generates them UEFI style but in next release will
> cowardly waste 4 bits of entropy by writing the nibble into both bytes.
> 
> It seems that nobody interprets the entrails of GUIDs but rather everybody
> uses them as opaque byte strings.

Still we need accurate representation (simply to be able to actually
compare/search for GUIDs) and proposed option for xorriso must have
defined semantic. Currently textual representation of UUID/GUID is

uint32-uint16-uint16-rest_as_individual_bytes

So it is pretty much possible to use uuidgen, except internal
representation will differ between RFC4122 and UEFI.

> Nevertheless one has to expect byte swapping to happen when converting
> forth and back between text representation and binary representation
> by using different conversion software.
> 

We have well defined semantic, other conversion software hardly matters
here.

Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[Thomas Schmitt]

Hi,

i wrote:
> > i could not reliably determine where to put the version nibble.

Andrei Borzenkov wrote:
> According to UEFI Appendix A it goes into 7-th byte (starting with 0) of
> binary representation of EFI GUID.

And RFC 4122 with its big-endian representation puts it into byte 6.


> Currently textual representation of UUID/GUID is
> uint32-uint16-uint16-rest_as_individual_bytes

I believe to understand that both specs prescribe the same text form
(big endian hex) but different binary form. It may well be that it
is meant twice swapped and thus identical ... but i know at least of
Matthew Garrett's GPT code in isohybrid.c which would then have gotten
it wrong.

In effect one simply cannot trust a GUID, which has undergone conversion
from text to binary and/or vice versa, to bear the same byte sex in
the first 8 bytes as the same GUID with a different conversion history.

One may trust that any reasonable converter applies the swapping in
a consistent way to uint32-uint16-uint16. So there should be only one
twin GUID resulting from conversion confusion.
   3cd0f966-2a50-444b-b6b4-2925fe82429a
   66f9d03c-502a-4b44-b6b4-2925fe82429a
Some programmer could come to the idea to swap the forth component, too.
   3cd0f966-2a50-444b-b4b6-2925fe82429a
   66f9d03c-502a-4b44-b4b6-2925fe82429a

This all is no problem if the GUIDs in question do not have a history
of different conversions before they get compared.
Straight uuidgen -> xorriso -> GRUB for all GUIDs in question should
yield an unambiguous situation.


> proposed option for xorriso must have defined semantic.

I decided for RFC 4122 because it matches with a plain byte string
where the first binary byte is printed as first two hex digits.

The upcomming man page says:

  --gpt_disk_guid value
      Control  whether  an emerging GPT shall get a randomly generated
      disk GUID or whether the GUID is supplied by  the  user.   Value
      "random"  is  default.  Value "modification-date" produces a low
      quality GUID from the value set by option --modification-date=.
      A string of 32 hex digits, or a RFC 4122 compliant  GUID  string
      may be used to set the disk GUID directly.
      E.g.  --gpt_disk_guid 2303cd2a-73c7-424a-a298-25632da7f446
      The  partition GUIDs get generated by minimally varying the disk
      GUID.

The upcomming libisofs API 1.4.6 clarifies on binary level:

  The partition GUIDs will be generated in a reproducible way by exoring a
  little-endian 32 bit counter with the disk GUID beginning at byte offset 9.


xorriso and libisofs do not participate in text format speculation.
libisofs API states about the report format of iso_image_report_system_area():

  GPT disk GUID      :      hex_digits
       32 hex digits giving the byte string of the disk's GUID

E.g.

  GPT disk GUID      :      dea3cb6ac9ad314481d46ecc024fdcf0

No '-' means no doubt. (Actually one can just insert '-' to get RFC 4122.)

man xorriso encourages the reader to get the API text from

  xorriso -report_system_area help | less

by saying:

  -report_system_area mode
       With  mode  plain  print a report about the information found in
       the System Area of the loaded ISO image. [...]
       With mode help print a text which explains the  meaning  of  the
       lines  put  out  by  "plain".
       [...]

Well, who reads the manual, anyways ...


Super nitpicking (nobody cares in practice, obviously):

Andrei Borzenkov wrote:
> Appendix A does not
> really tell anything about how GUIDs are actually generated.

My copy of UEFI 2.4 talks of "timestamp" and "IEEE 802 address obtained
from a network card".
  This appendix for GUID defines a 60-bit timestamp format that is used
  to generate the GUID. [...] This time value will not roll over until the
  year 3400 AD.

I think it is perky or simply a bug to state in one single paragraph:
  All EFI GUIDs (Globally Unique Identifiers) have the format described
  in RFC 4122 [...]. TimeLow, TimeMid, TimeHighAndVersion fields in the
  EFI are encoded as little endian.  


Have a nice day :)

Thomas

Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[Thomas Schmitt]

Hi,

... still trying to make sense of the specs.

Andrei Borzenkov wrote:
> According to UEFI Appendix A it goes into 7-th byte (starting with 0) of
> binary representation of EFI GUID.

Do you mean that one has to interpret the statement of UEFI 2.4

  "All EFI GUIDs (Globally Unique Identifiers) have the format described
   in RFC 4122 [...]
   It should also be noted that TimeLow, TimeMid, TimeHighAndVersion fields
   in the EFI are encoded as little endian."

as

  The text format of EFI GUIDs is the same as in RFC 4122, but the binary
  representation is byte-swapped at the first 4, 2, and 2 bytes.

If so, then i have to change the interpretation of the text form with the
new xorriso option.


Have a nice day :)

Thomas

Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[Andrei Borzenkov]

14.08.2016 18:44, Thomas Schmitt пишет:
> Hi,
> 
> ... still trying to make sense of the specs.
> 
> Andrei Borzenkov wrote:
>> According to UEFI Appendix A it goes into 7-th byte (starting with 0) of
>> binary representation of EFI GUID.
> 
> Do you mean that one has to interpret the statement of UEFI 2.4
> 
>   "All EFI GUIDs (Globally Unique Identifiers) have the format described
>    in RFC 4122 [...]
>    It should also be noted that TimeLow, TimeMid, TimeHighAndVersion fields
>    in the EFI are encoded as little endian."
> 
> as
> 
>   The text format of EFI GUIDs is the same as in RFC 4122, but the binary
>   representation is byte-swapped at the first 4, 2, and 2 bytes.
> 

Yes. See other mail I just sent :)

> If so, then i have to change the interpretation of the text form with the
> new xorriso option.
> 
> 
> Have a nice day :)
> 
> Thomas
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 

Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[Thomas Schmitt]

Hi,

i riddled over UEFI appendix A:
> > Do you mean that one has to interpret the statement of UEFI 2.4
> >   "All EFI GUIDs (Globally Unique Identifiers) have the format described
> >    in RFC 4122 [...]
> >    It should also be noted that TimeLow, TimeMid, TimeHighAndVersion fields
> >    in the EFI are encoded as little endian."
> > as
> >   The text format of EFI GUIDs is the same as in RFC 4122, but the binary
> >   representation is byte-swapped at the first 4, 2, and 2 bytes.

Andrei Borzenkov wrote:
> Yes. See other mail I just sent :)

I have to give in, since i am not in the position to raise protest against
Intel et.al. because of obfuscating english language. :))


> > Value "modification-date" produces a low
> > quality GUID from the value set by option --modification-date=.

> How? Time base UUID (Version 1) requires "node data" 

I am aware that the result is a poor fake of an UUID. Its time granularity
is below any standard. No site id. So i let it pose as random.
The reason for offering it is to reduce the number of parameters which
one has to remember for reproducibly producing an ISO.
(--modification-date= must be used in any case to override the automatic
 "now" timestamping of the ISO filesystem.)


> >  The partition GUIDs will be generated in a reproducible way by exoring a
> >  little-endian 32 bit counter with the disk GUID beginning at byte offset 9.

> Not sure I follow - what counter?

Partition number. I shall clarify this in the API.

In result the GUID byte strings of a grub-mkrescue GPT will look like

  GPT disk GUID      :      2303cd2a73c7424aa29825632da7f446
  GPT partition GUID :   1  2303cd2a73c7424aa29925632da7f446
  GPT partition GUID :   2  2303cd2a73c7424aa29a25632da7f446
  GPT partition GUID :   3  2303cd2a73c7424aa29b25632da7f446
  GPT partition GUID :   4  2303cd2a73c7424aa29c25632da7f446

In current xorriso, the first partition GUID is the original random
and disk GUID is derived from it as last one:

  GPT disk GUID      :      6d359a15f8763e47b9ee78207025c200
  GPT partition GUID :   1  6d359a15f8763e47b9ea78207025c200
  ...
  GPT partition GUID :   4  6d359a15f8763e47b9e978207025c200


> My copy of 2.4 RevC still does not mention IEEE 802

I have a PDF with title
  Unified Extensible Firmware Interface Specification
  Version 2.4 Errata B
  April, 2014
In appendix A, table 218, row "Node" i read:
  "Byte Offset: 10"
  "Byte Length: 6"
  "Description:
   The spatially unique node identifier. This can be based
   on any IEEE 802 address obtained from a network
   card. If no network card exists in the system, a
   cryptographic-quality random number can be used."


> Yes it could be more clear.

They should pay you a reward for compensating this flaw.


Have a nice day :)

Thomas

Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[Andrei Borzenkov]

14.08.2016 16:55, Thomas Schmitt пишет:
> Hi,
> 
> i wrote:
>>> i could not reliably determine where to put the version nibble.
> 
> Andrei Borzenkov wrote:
>> According to UEFI Appendix A it goes into 7-th byte (starting with 0) of
>> binary representation of EFI GUID.
> 
> And RFC 4122 with its big-endian representation puts it into byte 6.
> 

Yes, but EFI GUID is explicitly little-endian.

Here is how GRUB currently prints them (do not forget that both
platforms where EFI is currently supported are little-endian).

            grub_printf ("
%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x\n",
                         protocols[j]->data1,
                         protocols[j]->data2,
                         protocols[j]->data3,


> 
>> Currently textual representation of UUID/GUID is
>> uint32-uint16-uint16-rest_as_individual_bytes
> 
> I believe to understand that both specs prescribe the same text form
> (big endian hex) but different binary form. It may well be that it
> is meant twice swapped and thus identical ... but i know at least of
> Matthew Garrett's GPT code in isohybrid.c which would then have gotten
> it wrong.
> 

No it does not. It calls uuid_generate() from util-linux (which creates
RFC4122 big-endian binary representation) and then calls reverse_uuid()
which converts them to EFI little-endian. If you mean something
different, could you point to corresponding code please?

> In effect one simply cannot trust a GUID, which has undergone conversion
> from text to binary and/or vice versa, to bear the same byte sex in
> the first 8 bytes as the same GUID with a different conversion history.
> 

We can trust is as long as we know how it was produced and how it is
going to be used. uuidgen *command* spits out textual representation
that can be used both as RFC4122 UUID and EFI GUID and will result in
different binary content. Which is good because we can actually use
uuidgen to generate it and pass as argument to xorriso.

> One may trust that any reasonable converter applies the swapping in
> a consistent way to uint32-uint16-uint16. So there should be only one
> twin GUID resulting from conversion confusion.
>    3cd0f966-2a50-444b-b6b4-2925fe82429a
>    66f9d03c-502a-4b44-b6b4-2925fe82429a
> Some programmer could come to the idea to swap the forth component, too.
>    3cd0f966-2a50-444b-b4b6-2925fe82429a
>    66f9d03c-502a-4b44-b4b6-2925fe82429a
> 
> This all is no problem if the GUIDs in question do not have a history
> of different conversions before they get compared.
> Straight uuidgen -> xorriso -> GRUB for all GUIDs in question should
> yield an unambiguous situation.
> 

Yes; uuidgen -> xorriso -> GUID should convert textual representation to
EFI GUID. How to do *that* is exhaustively described in EFI spec. It is
responsibility of caller to ensure that passed string is valid (U|G)UID
(or may be it makes sense to do some basic sanity checks?)

> 
>> proposed option for xorriso must have defined semantic.
> 
> I decided for RFC 4122 because it matches with a plain byte string
> where the first binary byte is printed as first two hex digits.
> 
> The upcomming man page says:
> 
>   --gpt_disk_guid value
>       Control  whether  an emerging GPT shall get a randomly generated
>       disk GUID or whether the GUID is supplied by  the  user.   Value
>       "random"  is  default.  Value "modification-date" produces a low
>       quality GUID from the value set by option --modification-date=.

How? Time base UUID (Version 1) requires "node data" that is either MAC
or random bytes. You need to set those random bytes to something.

>       A string of 32 hex digits, or a RFC 4122 compliant  GUID  string
>       may be used to set the disk GUID directly.
>       E.g.  --gpt_disk_guid 2303cd2a-73c7-424a-a298-25632da7f446
>       The  partition GUIDs get generated by minimally varying the disk
>       GUID.
> 
> The upcomming libisofs API 1.4.6 clarifies on binary level:
> 
>   The partition GUIDs will be generated in a reproducible way by exoring a
>   little-endian 32 bit counter with the disk GUID beginning at byte offset 9.
> 

Not sure I follow - what counter?

> 
> xorriso and libisofs do not participate in text format speculation.
> libisofs API states about the report format of iso_image_report_system_area():
> 
>   GPT disk GUID      :      hex_digits
>        32 hex digits giving the byte string of the disk's GUID
> 
> E.g.
> 
>   GPT disk GUID      :      dea3cb6ac9ad314481d46ecc024fdcf0
> 
> No '-' means no doubt. (Actually one can just insert '-' to get RFC 4122.)
> 

No, one cannot. In the above case you /probably/ have Version 4 GUID,
but simply inserting '-' will suddenly make it Version 3. Not that it
really matters, but it will make everything even more confusing.
Explicitly showing raw binary GUID is OK.

> man xorriso encourages the reader to get the API text from
> 
>   xorriso -report_system_area help | less
> 
> by saying:
> 
>   -report_system_area mode
>        With  mode  plain  print a report about the information found in
>        the System Area of the loaded ISO image. [...]
>        With mode help print a text which explains the  meaning  of  the
>        lines  put  out  by  "plain".
>        [...]
> 
> Well, who reads the manual, anyways ...
> 
> 
> Super nitpicking (nobody cares in practice, obviously):
> 
> Andrei Borzenkov wrote:
>> Appendix A does not
>> really tell anything about how GUIDs are actually generated.
> 
> My copy of UEFI 2.4 talks of "timestamp" and "IEEE 802 address obtained
> from a network card".

My copy of 2.4 RevC still does not mention IEEE 802. Could you tell
which page (or chapter) in 2000 pages document tells this?

>   This appendix for GUID defines a 60-bit timestamp format that is used
>   to generate the GUID. [...] This time value will not roll over until the
>   year 3400 AD.
> 

This is almost direct quote from RFC4122 which also defines 60 bit
timestamp.

> I think it is perky or simply a bug to state in one single paragraph:
>   All EFI GUIDs (Globally Unique Identifiers) have the format described
>   in RFC 4122 [...]. TimeLow, TimeMid, TimeHighAndVersion fields in the
>   EFI are encoded as little endian.  
> 

Well ... one could also interpret this as "fields meaning is taken from
RFC but binary representation is different". Yes it could be more clear.

Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[Steve Kenton]

Thank you for the pointers and encouragement. I knew there had to be a 
better way and I will  do as you suggest using probe etc with current 
source. I was just experimenting with the source that was already 
available with my current Buildroot setup as a proof of concept.

Steve Kenton


On 08/14/2016 07:13 AM, Andrei Borzenkov wrote:
> 13.08.2016 23:25, Steve Kenton пишет:
>> My thought is to add a new command "partuuid" which takes a
> We have "probe" command and if implemented it should be integrated there.
>
>> drive&partition string and sets an environment variable to the partition
>> uuid (grub "partuuid" by default). Since grub always calls the load
>> drive "hd0"
> That's wrong in general.
>
>> this can then be passed directly to the kernel as a command
>> line for the rootfs in many cases. Or search could be used to find the
>> drive and partuuid could be used to make it palatable to the kernel. For
>> example:
>>
>> menuentry "Buildroot" {
>>      set root=(hd0,gpt1)
>>      partuuid $root partuuid
>>      linux /boot/bzImage root=PARTUUID=$partuuid rootfstype=ext4
>> console=tty1 quiet splash=silent
>> }
>>
>> Below is my first pass at a solution. It's really pseudo code since I
>> have not even tried to compile it yet. I was just getting familiar with
>> the grub environment since I've never tinkered with it before. Lot's of
>> cut and paste but I think it's pretty close.
>>
>> Steve Kenton
>>
>>
>> /*
>> GUIDs are usually stored as 128-bit BE values, and are commonly
>> displayed as 32 hexadecimal digits
>> most commonly written in text as a sequence of hexadecimal digits
>> separated into five groups, such as:
>>
>>      3F2504E0-4F89-41D3-9A0C-0305E82C3301
>>
> Usually GUIDs are displayed in lower case
>
>> This text notation contains the following fields, separated by hyphens:
>> Hex digits     Description
>> 8     Data1
>> 4     Data2
>> 4     Data3
>> 4     Initial two bytes from Data4
>> 12     Remaining six bytes from Data4
>>
>> For the first three fields, the most significant digit is on the left.
>> The last two fields are treated as eight separate bytes, each having
>> their most significant digit on the left, and they follow each other
>> from left to right. Note that the digit order of the fourth field may be
>> unexpected, since it is treated differently from the other fields in the
>> structure. This is sometimes known as "registry format".
> Not sure what it has to do with registry. For GPT GUID are pretty well
> defined by UEFI spec which in turn is based on RFC 4122.
>
>> */
>>
>> int main(int argc, char **argv) // example usage: partuuid "hd0,gpt1"
>> partuuid
>> {
>>
>>      char *name, *partnum, *var;
>>      int number; // the partition # of interest
> Please avoid C++ comments.
>
>>      grub_disk_t disk;
>>      grub_err_t err;
>>
>>      auto int NESTED_FUNC_ATTR find_partuuid(grub_disk_t disk, const
>> grub_partition_t p);
>>      int NESTED_FUNC_ATTR find_partuuid(grub_disk_t disk, const
>> grub_partition_t p)
> We got rid of nested functions years ago.
>
>>      {
>>          struct grub_gpt_partentry entry;
>>          int ret = true; // keep looking
>>
>>          if (grub_disk_read(disk, p->offset, p->index, sizeof(entry),
>> &entry))
>>              ret = false; // EOF
>>          else if (p->number == number) // number and var are in scope
>> from the outer function
>>          {
>>              char partuuid[37]; // 32 hex digits, 4 dashes and a NUL
>>
>>              partuuid = grub_xasprintf
>> ("%08X-%04X-%04X-%02X%02X-%02X%02X%02X%02X%02X%02X", // need to double
> grub internal implementation does not include upper case version.
>
>> check caps and endian-ness issues
>>              grub_be_to_cpu32 (*(grub_uint32_t *) &entry.guid[0]),
>>              grub_be_to_cpu16 (*(grub_uint16_t *) &entry.guid[4]),
>>              grub_be_to_cpu16 (*(grub_uint16_t *) &entry.guid[6]),
>>              entry.guid[7], entry.guid[8], // endian-ness does not matter
>> for single bytes
>>              entry.guid[9], entry.guid[10], entry.guid[10],
>> entry.guid[10], entry.guid[10], entry.guid[10], entry.guid[10]);
>>              err = grub_set_env(var, partuuid); // need to error check
>>              ret = false; // found it, all done
>>          }
>>
>>          return ret;
>>      }
>>
>>      // Split disk and partition from the name string and get environment
>> variable name - need to error check
>>      name = argv[1];
>>      partnum = grub_strchr(name, ',') + 1;
>>      var = argv[2]; // should default to "partuuid" if not supplied
>>      while (*partnum && grub_isalpha(*partnum))
>>          partnum++;
> You can simply read partition info directly from disk, no need to
> iterate at all. grub_disk_open returns all needed information about
> partition location.
>
>>      number = grub_strtoul(partnum, (char **) &partnum, 0) - 1; // need
>> to look at this function
>>      if (disk = grub_disk_open(name)) // ignores partition if present in
> You should return error if open fails, not silently ignore it. Not to
> mention, that it won't even compile because of warning that is treated
> as error.
>
>> name string, NULL on failure
>>          err = grub_gpt_partition_map_iterate(disk, find_partuuid);
>>
> Linux supports synthetic "GUID" on MSDOS labels too. This should support
> it as well (even though I am not sure how useful they are).
>
>>      return 0;
>> }
>>
>>
>> On 08/13/2016 06:40 PM, Andrei Borzenkov wrote:
>>> 13.08.2016 20:30, adrian15 пишет:
>>>> What's your use case?
>>>>
>>> Well, this has been requested before and this is supported by Linux
>>> kernel. So as long as this does not increase core modules size (i.e. is
>>> done outside of partition probing core) I think it will be OK.
>>>
>>>> adrian15
>>>>
>>>> El 12/08/16 a las 16:11, Steve Kenton escribió:
>>>>> As far as I can tell there is no search module that can be used to get
>>>>> the partuuid at boot time given a grub root device such as
>>>>> (hd0,gtp1). I
>>>>> think is would be a useful addition since the resulting partuuid could
>>>>> be passed directly to the kernel as root=PARTUUID=xxx and it does not
>>>>> seem like it should be hard to do. Am I missing something obvious? And,
>>>>> before I jump end the deep end of the pool and try to write it, is
>>>>> anyone else working on something similar?
>>>>>
>>> There was recent patch series that adds support for user-space
>>> grub-probe. Would be good if implementation can be shared. I do not want
>>> to add any special code to handle partitions UUID to core as this is
>>> very special case of really one partition type only, used infrequently
>>> and can be entirely handled by usual device iteration.
>>>
>>>>> Not subscribed, please cc me on reply.
>>>>>
>>> Not sure why, but whatever reply I chose Thunderbird and Gmail only
>>> reply to list.
>>>

Adding partition guid/uuid to the probe command for use with Linux kernel command line root=PARTUUID=$guid

[Steve Kenton]

I have not look at NTFS yet, but is this more what you were wanting? I'm 
not sure about the printing, should grub_gpt_partentry.guid[16] change 
to a UUID struct?

Steve Kenton

diff --git a/grub-core/commands/probe.c b/grub-core/commands/probe.c
index cf2793e..8ff4ff9 100644
--- a/grub-core/commands/probe.c
+++ b/grub-core/commands/probe.c
@@ -24,6 +24,7 @@
  #include <grub/device.h>
  #include <grub/disk.h>
  #include <grub/partition.h>
+#include <grub/gpt_partition.h>
  #include <grub/net.h>
  #include <grub/fs.h>
  #include <grub/file.h>
@@ -45,6 +46,7 @@ static const struct grub_arg_option options[] =
      {"fs",        'f', 0, N_("Determine filesystem type."), 0, 0},
      {"fs-uuid",        'u', 0, N_("Determine filesystem UUID."), 0, 0},
      {"label",        'l', 0, N_("Determine filesystem label."), 0, 0},
+    {"partguid",    'g', 0, N_("Determine partition guid."), 0, 0},
      {0, 0, 0, 0, 0, 0}
    };

@@ -154,6 +156,43 @@ grub_cmd_probe (grub_extcmd_context_t ctxt, int 
argc, char **args)
        grub_device_close (dev);
        return GRUB_ERR_NONE;
      }
+  if (state[6].set)
+    {
+      char *val;
+      struct grub_gpt_partentry entry;
+      if (dev->disk && dev->disk->partition)
+    {
+      if (grub_strcmp (dev->disk->partition->partmap->name, "gpt"))
+        return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET,
+               N_("partition map %s does not support partition GUIDs"), 
dev->disk->partition->partmap->name);
+      if (grub_disk_read (dev->disk, dev->disk->partition->offset, 
dev->disk->partition->index, sizeof(entry), &entry))
+        return grub_errno;
+#if 0
+      val = grub_xasprintf 
("%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x", /* should 
grub_gpt_partentry.guid[16] change to a UUID struct? */
+      grub_be_to_cpu32 (*(grub_uint32_t *) &entry.guid[0]),
+      grub_be_to_cpu16 (*(grub_uint16_t *) &entry.guid[4]),
+      grub_be_to_cpu16 (*(grub_uint16_t *) &entry.guid[6]),
+      entry.guid[8], entry.guid[9],
+      entry.guid[10], entry.guid[11], entry.guid[12], entry.guid[13], 
entry.guid[14], entry.guid[15]);
+#else
+      val = grub_xasprintf 
("%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x", 
/* guid is big-endian */
+      entry.guid[0], entry.guid[1], entry.guid[2], entry.guid[3],
+      entry.guid[4], entry.guid[5],
+      entry.guid[6], entry.guid[7],
+      entry.guid[8], entry.guid[9],
+      entry.guid[10], entry.guid[11], entry.guid[12], entry.guid[13], 
entry.guid[14], entry.guid[15]);
+#endif
+    }
+    else
+      val = grub_strdup(""); /* set guid to the empty string */
+      if (state[0].set)
+    grub_env_set (state[0].arg, val);
+      else
+    grub_printf ("%s", val);
+      grub_free (val);
+      grub_device_close (dev);
+      return GRUB_ERR_NONE;
+    }
    grub_device_close (dev);
    return grub_error (GRUB_ERR_BAD_ARGUMENT, "unrecognised target");
  }

Re: Adding partition guid/uuid to the probe command for use with Linux kernel command line root=PARTUUID=$guid

[Andrei Borzenkov]

14.08.2016 21:31, Steve Kenton пишет:
> I have not look at NTFS yet, but is this more what you were wanting? I'm

Yes. Did you test it?

> not sure about the printing, should grub_gpt_partentry.guid[16] change
> to a UUID struct?
> 

It may make sense if we started to actually use it. Actually we may
probably just as well get rid of special case grub_gpt_part_type_t.

> Steve Kenton
> 
> diff --git a/grub-core/commands/probe.c b/grub-core/commands/probe.c
> index cf2793e..8ff4ff9 100644
> --- a/grub-core/commands/probe.c
> +++ b/grub-core/commands/probe.c
> @@ -24,6 +24,7 @@
>  #include <grub/device.h>
>  #include <grub/disk.h>
>  #include <grub/partition.h>
> +#include <grub/gpt_partition.h>
>  #include <grub/net.h>
>  #include <grub/fs.h>
>  #include <grub/file.h>
> @@ -45,6 +46,7 @@ static const struct grub_arg_option options[] =
>      {"fs",        'f', 0, N_("Determine filesystem type."), 0, 0},
>      {"fs-uuid",        'u', 0, N_("Determine filesystem UUID."), 0, 0},
>      {"label",        'l', 0, N_("Determine filesystem label."), 0, 0},
> +    {"partguid",    'g', 0, N_("Determine partition guid."), 0, 0},

Linux is using PARTUUID and patches from Nicholas use --target=partuuid,
so let's stick to it.

>      {0, 0, 0, 0, 0, 0}
>    };
> 
> @@ -154,6 +156,43 @@ grub_cmd_probe (grub_extcmd_context_t ctxt, int
> argc, char **args)
>        grub_device_close (dev);
>        return GRUB_ERR_NONE;
>      }
> +  if (state[6].set)
> +    {
> +      char *val;
> +      struct grub_gpt_partentry entry;
> +      if (dev->disk && dev->disk->partition)
> +    {
> +      if (grub_strcmp (dev->disk->partition->partmap->name, "gpt"))
> +        return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET,
> +               N_("partition map %s does not support partition GUIDs"),
> dev->disk->partition->partmap->name);
> +      if (grub_disk_read (dev->disk, dev->disk->partition->offset,
> dev->disk->partition->index, sizeof(entry), &entry))

You need to read from partition parent, not from partition itself. Usual
hack is to reset disk->partition = disk->partition->parent. See e.g. in
gpt.c itself or in mentioned grub-probe patches.

May be we need to provide something like grub_read_partition_container()
to encapsulate it.

> +        return grub_errno;
> +#if 0
> +      val = grub_xasprintf
> ("%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x", /* should
> grub_gpt_partentry.guid[16] change to a UUID struct? */
> +      grub_be_to_cpu32 (*(grub_uint32_t *) &entry.guid[0]),
> +      grub_be_to_cpu16 (*(grub_uint16_t *) &entry.guid[4]),
> +      grub_be_to_cpu16 (*(grub_uint16_t *) &entry.guid[6]),
> +      entry.guid[8], entry.guid[9],
> +      entry.guid[10], entry.guid[11], entry.guid[12], entry.guid[13],
> entry.guid[14], entry.guid[15]);
> +#else
> +      val = grub_xasprintf
> ("%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x",
> /* guid is big-endian */

No, EFI GUIDs are little-endian as was discussed in another subthread.
See also grub-probe patches.

> +      entry.guid[0], entry.guid[1], entry.guid[2], entry.guid[3],
> +      entry.guid[4], entry.guid[5],
> +      entry.guid[6], entry.guid[7],
> +      entry.guid[8], entry.guid[9],
> +      entry.guid[10], entry.guid[11], entry.guid[12], entry.guid[13],
> entry.guid[14], entry.guid[15]);
> +#endif
> +    }
> +    else
> +      val = grub_strdup(""); /* set guid to the empty string */
> +      if (state[0].set)
> +    grub_env_set (state[0].arg, val);
> +      else
> +    grub_printf ("%s", val);
> +      grub_free (val);
> +      grub_device_close (dev);
> +      return GRUB_ERR_NONE;
> +    }
>    grub_device_close (dev);
>    return grub_error (GRUB_ERR_BAD_ARGUMENT, "unrecognised target");
>  }

Re: Adding partition guid/uuid to the probe command for use with Linux kernel command line root=PARTUUID=$guid

[Steve Kenton]

I have not started testing yet, I'll do that after I have the NTFS Disk 
Identifier suff added. I just wanted to make sure I was headed in the 
right direction. I see I still need to make some adjustments and I'm 
talking to Nick now about how our proposals overlap.

Thanks again,

Steve Kenton



On 08/15/2016 04:04 AM, Andrei Borzenkov wrote:
> 14.08.2016 21:31, Steve Kenton пишет:
>> I have not look at NTFS yet, but is this more what you were wanting? I'm
> Yes. Did you test it?
>
>> not sure about the printing, should grub_gpt_partentry.guid[16] change
>> to a UUID struct?
>>
> It may make sense if we started to actually use it. Actually we may
> probably just as well get rid of special case grub_gpt_part_type_t.
>
>> Steve Kenton
>>
>> diff --git a/grub-core/commands/probe.c b/grub-core/commands/probe.c
>> index cf2793e..8ff4ff9 100644
>> --- a/grub-core/commands/probe.c
>> +++ b/grub-core/commands/probe.c
>> @@ -24,6 +24,7 @@
>>   #include <grub/device.h>
>>   #include <grub/disk.h>
>>   #include <grub/partition.h>
>> +#include <grub/gpt_partition.h>
>>   #include <grub/net.h>
>>   #include <grub/fs.h>
>>   #include <grub/file.h>
>> @@ -45,6 +46,7 @@ static const struct grub_arg_option options[] =
>>       {"fs",        'f', 0, N_("Determine filesystem type."), 0, 0},
>>       {"fs-uuid",        'u', 0, N_("Determine filesystem UUID."), 0, 0},
>>       {"label",        'l', 0, N_("Determine filesystem label."), 0, 0},
>> +    {"partguid",    'g', 0, N_("Determine partition guid."), 0, 0},
> Linux is using PARTUUID and patches from Nicholas use --target=partuuid,
> so let's stick to it.
>
>>       {0, 0, 0, 0, 0, 0}
>>     };
>>
>> @@ -154,6 +156,43 @@ grub_cmd_probe (grub_extcmd_context_t ctxt, int
>> argc, char **args)
>>         grub_device_close (dev);
>>         return GRUB_ERR_NONE;
>>       }
>> +  if (state[6].set)
>> +    {
>> +      char *val;
>> +      struct grub_gpt_partentry entry;
>> +      if (dev->disk && dev->disk->partition)
>> +    {
>> +      if (grub_strcmp (dev->disk->partition->partmap->name, "gpt"))
>> +        return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET,
>> +               N_("partition map %s does not support partition GUIDs"),
>> dev->disk->partition->partmap->name);
>> +      if (grub_disk_read (dev->disk, dev->disk->partition->offset,
>> dev->disk->partition->index, sizeof(entry), &entry))
> You need to read from partition parent, not from partition itself. Usual
> hack is to reset disk->partition = disk->partition->parent. See e.g. in
> gpt.c itself or in mentioned grub-probe patches.
>
> May be we need to provide something like grub_read_partition_container()
> to encapsulate it.
>
>> +        return grub_errno;
>> +#if 0
>> +      val = grub_xasprintf
>> ("%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x", /* should
>> grub_gpt_partentry.guid[16] change to a UUID struct? */
>> +      grub_be_to_cpu32 (*(grub_uint32_t *) &entry.guid[0]),
>> +      grub_be_to_cpu16 (*(grub_uint16_t *) &entry.guid[4]),
>> +      grub_be_to_cpu16 (*(grub_uint16_t *) &entry.guid[6]),
>> +      entry.guid[8], entry.guid[9],
>> +      entry.guid[10], entry.guid[11], entry.guid[12], entry.guid[13],
>> entry.guid[14], entry.guid[15]);
>> +#else
>> +      val = grub_xasprintf
>> ("%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x",
>> /* guid is big-endian */
> No, EFI GUIDs are little-endian as was discussed in another subthread.
> See also grub-probe patches.
>
>> +      entry.guid[0], entry.guid[1], entry.guid[2], entry.guid[3],
>> +      entry.guid[4], entry.guid[5],
>> +      entry.guid[6], entry.guid[7],
>> +      entry.guid[8], entry.guid[9],
>> +      entry.guid[10], entry.guid[11], entry.guid[12], entry.guid[13],
>> entry.guid[14], entry.guid[15]);
>> +#endif
>> +    }
>> +    else
>> +      val = grub_strdup(""); /* set guid to the empty string */
>> +      if (state[0].set)
>> +    grub_env_set (state[0].arg, val);
>> +      else
>> +    grub_printf ("%s", val);
>> +      grub_free (val);
>> +      grub_device_close (dev);
>> +      return GRUB_ERR_NONE;
>> +    }
>>     grub_device_close (dev);
>>     return grub_error (GRUB_ERR_BAD_ARGUMENT, "unrecognised target");
>>   }

Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[Michael Zimmermann]

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

> Not sure why, but whatever reply I chose Thunderbird and Gmail only
reply to list.
no idea about thunderbird but in GMail you have the small arrow beneath the
reply buttons, click it and select "Reply to all".

On Sat, Aug 13, 2016 at 8:40 PM, Andrei Borzenkov <arvidjaar@gmail.com>
wrote:

> 13.08.2016 20:30, adrian15 пишет:
> > What's your use case?
> >
>
> Well, this has been requested before and this is supported by Linux
> kernel. So as long as this does not increase core modules size (i.e. is
> done outside of partition probing core) I think it will be OK.
>
> > adrian15
> >
> > El 12/08/16 a las 16:11, Steve Kenton escribió:
> >> As far as I can tell there is no search module that can be used to get
> >> the partuuid at boot time given a grub root device such as (hd0,gtp1). I
> >> think is would be a useful addition since the resulting partuuid could
> >> be passed directly to the kernel as root=PARTUUID=xxx and it does not
> >> seem like it should be hard to do. Am I missing something obvious? And,
> >> before I jump end the deep end of the pool and try to write it, is
> >> anyone else working on something similar?
> >>
>
> There was recent patch series that adds support for user-space
> grub-probe. Would be good if implementation can be shared. I do not want
> to add any special code to handle partitions UUID to core as this is
> very special case of really one partition type only, used infrequently
> and can be entirely handled by usual device iteration.
>
> >> Not subscribed, please cc me on reply.
> >>
>
> Not sure why, but whatever reply I chose Thunderbird and Gmail only
> reply to list.
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

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

Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[Andrei Borzenkov]

14.08.2016 07:12, Michael Zimmermann пишет:
>> Not sure why, but whatever reply I chose Thunderbird and Gmail only
> reply to list.
> no idea about thunderbird but in GMail you have the small arrow beneath the
> reply buttons, click it and select "Reply to all".
> 

Should I repeat - "Whatever reply [option] I chose"?

Actually list apparently sets

Reply-To: The development of GNU GRUB <grub-devel@gnu.org>

(TB helpfully does not show it in full headers ...).

Assuming that "Reply to all" is defined as "sender and all other
recipients" this behavior is also correct, as sender in Reply-To should
have precedence over sender in From.

Oh, and Gmail does not even offer "Reply to all" if message does not
have other recipients. Did you actually try it on any mail to this list?
This is different for other lists (e.g. help-grub), where Reply-To is
not set. BTW I have "Reply to all" as default in Gmail as I just found :)

This changed relatively recently. I wonder who did it and for what
reasons (I can of course imagine reasons).

Re: Grub module to return partuuid of a device such as (hd0, gpt1) at boot time

[Steve Kenton]

Embedded Linux on flash with no initramfs. I'm in the USA and recently 
had lots of "fun" trying to help a dealer in Australia with a unit that 
apparently had something plugged into the wrong slot. My goal is to 
always have our system at least boot and complain if physically possible 
no matter what creative re-configuration the dealers or end-users might 
have done to it.

Steve Kenton


On 08/13/2016 05:30 PM, adrian15 wrote:
> What's your use case?
>
> adrian15
>
> El 12/08/16 a las 16:11, Steve Kenton escribió:
>> As far as I can tell there is no search module that can be used to get
>> the partuuid at boot time given a grub root device such as (hd0,gtp1). I
>> think is would be a useful addition since the resulting partuuid could
>> be passed directly to the kernel as root=PARTUUID=xxx and it does not
>> seem like it should be hard to do. Am I missing something obvious? And,
>> before I jump end the deep end of the pool and try to write it, is
>> anyone else working on something similar?
>>
>> Not subscribed, please cc me on reply.
>>
>> Steve Kenton
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>