[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: Purposing an Alternative Feature Request: Make Use of Whole-Disk UUIDs
Date: Sat, 04 Feb 2012 17:02:21 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0

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

Vladimir 'φ-coder/phcoder' Serbinenko

reply via email to

[Prev in Thread] Current Thread [Next in Thread]