Re: Search GPT partition in GRUB

[Colin Watson]

On Thu, Feb 04, 2010 at 06:26:10AM -0500, address@hidden 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                                       address@hidden