From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Rti4O-0001RL-U6 for mharc-grub-devel@gnu.org; Sat, 04 Feb 2012 11:02:32 -0500 Received: from eggs.gnu.org ([140.186.70.92]:60433) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rti4L-0001OS-Ug for grub-devel@gnu.org; Sat, 04 Feb 2012 11:02:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rti4K-0004XR-My for grub-devel@gnu.org; Sat, 04 Feb 2012 11:02:29 -0500 Received: from mail-ey0-f169.google.com ([209.85.215.169]:58376) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rti4K-0004XK-Gk for grub-devel@gnu.org; Sat, 04 Feb 2012 11:02:28 -0500 Received: by eaag11 with SMTP id g11so1832695eaa.0 for ; Sat, 04 Feb 2012 08:02:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=8bQIRCdDVdJAbCWir9g8FsxPoxYOYx9ooSoWXZu89fw=; b=QWOEzKF8AX/Qr7un8inpykMZxPTxz32QJo3Rpcc9sYsaAQO/KtU8WCZDrj1gST1PGJ 0jk0Dx0PFCIaG762bpukb4L9zuOTMqw9gB4usDP4GlRNnNwtK2ZTG/y4XI1VNYyv1+/V WBevq5enjARpA1FlgNgpag8wa9H/1jfKkWHNU= Received: by 10.213.22.74 with SMTP id m10mr1888851ebb.32.1328371347269; Sat, 04 Feb 2012 08:02:27 -0800 (PST) Received: from debian.x201.phnet (97-233.197-178.cust.bluewin.ch. [178.197.233.97]) by mx.google.com with ESMTPS id x4sm36479085eeb.4.2012.02.04.08.02.24 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Feb 2012 08:02:25 -0800 (PST) Message-ID: <4F2D568D.6000109@gmail.com> Date: Sat, 04 Feb 2012 17:02:21 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: Jake Thomas , The development of GRUB 2 Subject: Re: Purposing an Alternative Feature Request: Make Use of Whole-Disk UUIDs References: <1328353897.57954.YahooMailNeo@web46413.mail.sp1.yahoo.com> <4F2D175A.3080709@gmail.com> <1328364512.83970.YahooMailNeo@web46415.mail.sp1.yahoo.com> In-Reply-To: <1328364512.83970.YahooMailNeo@web46415.mail.sp1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.215.169 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 16:02:31 -0000 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