All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: Jake Thomas <jthomas97411@yahoo.com>,
	 The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Purposing an Alternative Feature Request: Make Use of Whole-Disk UUIDs
Date: Sat, 04 Feb 2012 17:02:21 +0100	[thread overview]
Message-ID: <4F2D568D.6000109@gmail.com> (raw)
In-Reply-To: <1328364512.83970.YahooMailNeo@web46415.mail.sp1.yahoo.com>

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



           reply	other threads:[~2012-02-04 16:02 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <1328364512.83970.YahooMailNeo@web46415.mail.sp1.yahoo.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F2D568D.6000109@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    --cc=jthomas97411@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.