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

[Keshav P R]

On Sat, Feb 4, 2012 at 16:41, Jake Thomas <address@hidden> wrote:
> I figured I better give this its own thread, but it stems from "[bug #35354]
> Cloning GRUB2 1.99 makes clone not bootable".
>
> Is the following a valid suggestion? It'd be pretty powerful and useful if
> it could be done:
>
> Suppose Grub could utilize MBR and GPT header whole-disk UUIDs. In the MBR,
> from the four-hundred forty-first byte to the four-houndred forty-fourth
> byte is a 4-byte disk id, see "master boot record" in Wikipedia. This is not
> the kind of disk-id you folks have been talking about. You folks have been
> talking about some hardware name of the hard drive as reported by the
> drive's firmware. That hardware name is not stored on the hard drive part of
> the hard drive (main storage area). It's located on a ROM chip with the
> firmware (or sneakily put on a negative sector of the actual hard drive part
> of the hard drive that gets hidden by the firmware). I'm talking about
> something that is easily mutable and visible by a hex editor looking at,
> say, /dev/sda.
>
> Likewise, in the GPT header of GPT-structured hard drives is a 16-byte UUID
> for the whole hard drive. GPT-structured hard drives will still have an MBR
> disk-id in their protective MBR, but it is preferable to use the GPT
> header's UUID if the disk is GPT-structured.
>
> The whole-disk UUID is very much parallel to an individual partition's UUID,
> except it is for the whole disk. Both are easily mutable without data loss:
> you can change a partition's UUID without loosing data on that partition,
> and you can change an MBR's whole-disk UUID without destroying any data in
> the partition table or boot code. Both are right in main storage and can be
> edited with normal read/write commands, as opposed to requiring a
> firmware-flash to be edited (to rename a hard drive's hardware name, you
> would need to flash its firmware).
>
> So if Grub already uses partition UUIDs, by symmetry, Grub should also
> support whole-disk UUIDs.
>
> Suppose this was done:
>
> Add an "--hd-uuid" parameter to the search command that paralells the
> "--fs-uuid" parameter so that one could do something like the following:
>
> "search --no-floppy --fs-uuid --set=root 0x94f81ddc,3"
>
> This would search all hard drives for a UUID of "0x94f81ddc" and set the
> root to the 3rd partition on that hard drive.
>
> And maybe even do this:
>
> Perhaps let someone, in a Grub stanza, replace "set root='(hd0,3)'" with
> "set root='(0x94f81ddc,3)'", if  partition 3 of the disk with the ID of
> "0x94f81ddc" was the goal partition.
>
>
>
> This would solve cloning-related issues as far as Grub is concerned (not
> going into software raid and other such sticky topics), provided only
> partitions are cloned and restored rather than whole hard disks.
>
>
> Cheers,
> Jake
>
> _______________________________________________
> Bug-grub mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-grub
>

Something similar to this came up in 2010 for GPT GUID support. I had
saved the patch the original author posted is at
https://gist.github.com/584187 (don't have the original link right
now). The patch no longer applies to current 1.99 release or bzr since
many files have been renamed and lots of code has been modified. Also
I do not understand C programming (still learning), I just copied the
path to compile and test it. I think this might help. What phcoder
means is to have

search.part_uuid or "search --part-uuid" option instead of --gpt-uuid
(option name should be specific to any partmap).

Regards.

Keshav