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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
