On Thu, Feb 04, 2010 at 06:26:10AM -0500, gbura...@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 [cjwat...@ubuntu.com] _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
