Search GPT partition in GRUB

Search GPT partition in GRUB

[gburanov]

Hello everybody.

I am currently trying to realize the following functionality: I want grub to load the kernel from GPT partition. I am using grub build for UEFI. So, I got following questions for now:

I don't want to use standart naming conversion, here are some reasons:

* It is not clear what is (hd1, 0). I understand that is means first partition on the first disk, but what is first disk on EFI? I know, for example, that you can easy change the order in BIOS (SCSI first or IDE first), but what about UEFI? What disk exactly is hd1, and what is hd2? Or that's platform specific?

* If it's platform specific, is there a way in live OS to obtain UEFI disk number, used by GRUB?

I am currently looking into "search" grub command, it seems it can search by filesystem UUID, but I want to load from NTFS. Do we have UUID on NTFS? Is UUID really unique? I guess no.

It would be ideal if we can search the GPT partition/disk by GUID - that's what we got NTFS GUID for =)

Do anybody know is it really possible?

Thanks in advance,
Georgy

--
This message was sent on behalf of gburanov@gmail.com at openSubscriber.com
http://www.opensubscriber.com/messages/grub-devel@gnu.org/topic.html

Re: Search GPT partition in GRUB

[Colin Watson]

On Thu, Feb 04, 2010 at 06:26:10AM -0500, gburanov@gmail.com wrote:
> I am currently trying to realize the following functionality: I want
> grub to load the kernel from GPT partition. I am using grub build for
> UEFI. So, I got following questions for now:
> 
> I don't want to use standart naming conversion, here are some reasons:
> 
> * It is not clear what is (hd1, 0). I understand that is means first
> partition on the first disk, but what is first disk on EFI? I know,
> for example, that you can easy change the order in BIOS (SCSI first or
> IDE first), but what about UEFI? What disk exactly is hd1, and what is
> hd2? Or that's platform specific?

Platform-specific, and you should avoid relying on it.  Getting hold of
partitions this way is very close to being legacy functionality in GRUB.

> I am currently looking into "search" grub command, it seems it can
> search by filesystem UUID,

This is almost always the right approach.

> but I want to load from NTFS. Do we have UUID on NTFS?

Yes.

> Is UUID really unique? I guess no.

The NTFS "UUID" (actually the volume serial number rather than a proper
UUID) is 64 bits long, so we have a space of 2^64 possible UUIDs. That's
very close to the number of stars in the observable universe.  I believe
that the volume serial number is typically generated based on the date
and some amount of randomness, although of course I can't verify that
for certain from Microsoft's implementation (linux-ntfs simply generates
a 64-bit random number).

Even with fairly conservative assumptions, though, the probability of an
NTFS volume serial number collision is extremely small.  The probability
of an NTFS volume serial number collision *on the same machine* - well,
I rather expect that it's on the same general order as the probability
of an asteroid dropping on your head.  I wouldn't worry about it if I
were you!

> It would be ideal if we can search the GPT partition/disk by GUID -
> that's what we got NTFS GUID for =)

That would be nice, and it might not be all that difficult to implement,
but of course it would take up extra precious space in the core image.
I don't think it's really necessary in this case.

Cheers,

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Re: Search GPT partition in GRUB

[gburanov]

> The NTFS "UUID" (actually the volume serial number rather than a proper
> UUID) is 64 bits long, so we have a space of 2^64 possible UUIDs. That's
> very close to the number of stars in the observable universe.  I believe
> that the volume serial number is typically generated based on the date
> and some amount of randomness, although of course I can't verify that
> for certain from Microsoft's implementation (linux-ntfs simply generates
> a 64-bit random number).
> 
> Even with fairly conservative assumptions, though, the probability of an
> NTFS volume serial number collision is extremely small.  The probability
> of an NTFS volume serial number collision *on the same machine* - well,
> I rather expect that it's on the same general order as the probability
> of an asteroid dropping on your head.  I wouldn't worry about it if I
> were you!

Hello Colin
Thank you very much for the answer!  However, last night I was investigating NTFS volume serial number and GPT GUIDs.
  1) Volume serial number in NTFS is only 32 bits long (not 64), althought the reserved space is really 64 bit (this is done for the compatibility with FAT), where they got only 32 bits for volume serial number.
  2) The worse thing is that this number is not really designed to be unique (there is no single document where it's written to be unique). In the old times, MS used volume label to create serial number, which is not unique for sure. Now they use timestamp.
  3) Now, the worsiest sting is that 3rd part software sometimes does not change it (cause it's not documented that is must be unique). For example, you backup the volume and restore it to the free space on the same drive - and, gotcha, the serial is the same.


> > It would be ideal if we can search the GPT partition/disk by GUID -
> > that's what we got NTFS GUID for =)
> 
> That would be nice, and it might not be all that difficult to implement,
> but of course it would take up extra precious space in the core image.
> I don't think it's really necessary in this case.

The GPT GUID, on the other side, is DOCUMENTED to be unique. So, it's much better way to use it. I am not so familiar to grub, but I guess we can add GPT GUID support as additional module, so it will not take extra space for that.

I guess I need to write GPT GUID support for the GRUB (in sore image or as separate module), because we still need this in our own product.

There is one problem - I never wrote smth for grub before =) It seems you are familiar with grub - and know the place in the code where do I need to make changes. Maybe we can contact by mail, and I will write the implementation?

Regards,
Georgy

--
This message was sent on behalf of gburanov@gmail.com at openSubscriber.com
http://www.opensubscriber.com/message/grub-devel@gnu.org/13378639.html

Re: Search GPT partition in GRUB

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Colin Watson wrote:
>> It would be ideal if we can search the GPT partition/disk by GUID -
>> that's what we got NTFS GUID for =)
>>     
>
> That would be nice, and it might not be all that difficult to implement,
> but of course it would take up extra precious space in the core image.
> I don't think it's really necessary in this case.
>
>   
Implementing it isn't difficult but it's confusing to have two types of
UUIDs. I'm not sure we need GPT UUIDs. grub-mkconfig will continue to
use  filesystem UUIDs, so GPT UUIDs will only be used in maual
configuration. But in the latter case it's much easier to use filesystem
labels when writing configuration manually. Probability of collision
with n-partitions and k bits is lower than
n^2*2^(-k-1)
Even with 1024 partitions and 32-bit IDs it's under 1 over 8192.
Fell free to detail usage cases when my logic is wrong (e.g. disk
configuration, who writes config, external factors and so on)

> Cheers,
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: Re: Search GPT partition in GRUB

[gburanov]

-- Vladimir 'φ-coder/phcoder' Serbinenko wrote : 
Colin Watson wrote:
>> It would be ideal if we can search the GPT partition/disk by GUID -
>> that's what we got NTFS GUID for =)
>>     
>
> That would be nice, and it might not be all that difficult to implement,
> but of course it would take up extra precious space in the core image.
> I don't think it's really necessary in this case.
>
>   
> Implementing it isn't difficult but it's confusing to have two types of
> UUIDs. I'm not sure we need GPT UUIDs. grub-mkconfig will continue to
> use  filesystem UUIDs, so GPT UUIDs will only be used in maual
> configuration. But in the latter case it's much easier to use filesystem
> labels when writing configuration manually. Probability of collision
> with n-partitions and k bits is lower than
> n^2*2^(-k-1)
> Even with 1024 partitions and 32-bit IDs it's under 1 over 8192.
> Fell free to detail usage cases when my logic is wrong (e.g. disk
> configuration, who writes config, external factors and so on)

As I said already (see upper), NTFS volume serial number (that's really UUID in NTFS) is not really unique, so that's not a good way of identification.

> Cheers,
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko




--
This message was sent on behalf of gburanov@gmail.com at openSubscriber.com
http://www.opensubscriber.com/message/grub-devel@gnu.org/13383952.html