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

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 04.02.2012 12:11, Jake Thomas 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.
A similar but somewhat different approach was already proposed: use 
partition UUIDs. GPT has per-partition UUIDs and msdos uses the format 
<msdos id><start sector>. The conclusion is the same for both ideas: 
it's realisable and patches can be included as long as:
1) interface and code is independent of actual partmap (e.g. search 
--partition-uuid is fine but search --gptuuid isn't)
2) it doesn't increase the size of kernel or patmap modules
3) isn't default
So it's mostly "patches are welcome"
> 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:
hd-uuid would refer to the hardware uuid. partmap-uuid is better name
> "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.
We've been down this road before. Terribly inefficient.

--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko