Re: Purposing an Alternative Feature Request: Make Use of Whole-Disk UUIDs

Re: Purposing an Alternative Feature Request: Make Use of Whole-Disk UUIDs

[Vladimir 'φ-coder/phcoder' Serbinenko]

Keep the list CC'ed.
On 04.02.2012 15:08, Jake Thomas wrote:
> If one only imaged/cloned partitions rather than whole disks, the 
> disks' UUIDs wouldn't change, however, individual partitions would 
> wind up with identical UUIDs. The partition UUIDs can easily be made 
> unique afterwards with tune2fs, but I think using the whole-disk-UUID 
> as your truly unique identifier would be even easier. So if in the 
> bootloader that whole-disk-level UUID could be used to specify the 
> hard drive, and then after that specify the number of the partition 
> you want to go to within that drive, you'd be golden.
>
You confuse FS and partition ID. Consult GPT format for an example
> I'm thinking that the flaw in using the hardware name as a unique 
> identifier is that someone might buy a bunch of hard drives of the 
> same exact model in bulk to start a server or something. Wouldn't they 
> all have the same hardware disk-id? Or does the hardware disk-id 
> include a unique identifer even amongst identical hardware? 
> Whole-disk-level UUIDs can be easily changed if necessary. One can 
> also easily avoid changing the whole-disk-level UUID by 
> imaging/cloning only partitions and not the whole disk.
>
Serial is unique. But then, of course, there is a land called China and 
it was known to sometimes produce a bulk of network cards with same mac.
> When I was saying "--hd-uuid" I meant for the "hd" to stand for "hard 
> drive" just like it does in " set root='(hd0,2)' ". I didn't intend to 
> convey that it could stand for "hardware." In fact, arguably, if Grub 
> ever did use "hd" to stand for "hardware", that would be an 
> inconsistency in it's naming conventions, because back in " set 
> root='(hd0,2)' ", "hd" stands for something different.
>
Yes and HD would refer to something inherent to hard disk even if you 
zero its contents out.
> I don't think "partmap-uuid" would be a better name for what I'm 
> trying to describe because "partmap-uuid" is making a reference to 
> partitions and/or possibly partition tables and/or memory mappings.
partmap is the term we use to refer to partition tables and the UUID is 
stored exactly there.
> I'm not referring to any of those. I'm referring to something 
> completely partition-independent that does not even exist in a 
> partition table. Whole-disk UUIDs come before the partition table in 
> both MBR and GPT structuring.
You said it yourself. It comes from partmap
>
> I don't fully understand what you mean by "is independent of actual 
> partmap (e.g. search --partition-uuid is fine but search --gptuuid 
> isn't)". Does the syntax with a hyphen in the middle not use partmap 
> while the one without a hyphen in the middle use partmap?
I mean that the name shouldn't refer to any specific partmap.
>
> If you want it separate from partmap, wouldn't that be another reason 
> to not name it "partmap-uuid"?
>
No. I don't want it separate, I want it abstracted.
> Once you specify the hard drive by whole-disk-level UUID, syntax needs 
> to provide a way to specify the partition within the choosen hard drive.
>
> I'm just trying to stay consistent with the syntax " search  
> --no-floppy --fs-uuid --set=root'(hd0,2)' ". I thought " search 
> --no-floppy --hd-uuid --set=root '([UUID],[partition #])' " was a good 
> parallel.
>
No need to brackets.
> What exactly does partmap do anyways? Does it write/ edit 
> drivemappings in memory, or does Grub only use partmap to internally 
> keep track of partitions and disks?
>
partmap only discovers partitions. To modify them if needed (which is 
rarely the case) we have parttool
> Cheers,
> Jake


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